Factor common code out of Users and Items UI modules
Description
Environment
Potential Workaround
blocks
is blocked by
Checklist
hideTestRail: Results
Activity
Mike TaylorFebruary 27, 2017 at 2:02 PM
OK, I see – I'd been interpreting for-next-sprint as (among other things) "We'll discuss this on Monday and decide when to schedule it for."
Jakub SkoczenFebruary 27, 2017 at 1:57 PM
It makes little sense to tag for-next-sprint stuff that is in the current sprint because at the end of the sprint we roll over (or drop) any unfinished business.
Mike TaylorFebruary 27, 2017 at 1:54 PM
This needs to be for-next-sprint as well as sprint8 and sprint9: it's ongoing work that covers the process of factoring out re-usable utilities (which is why I redesignated it an umbrella). We can rename it if that helps.
Mike TaylorFebruary 9, 2017 at 3:05 PM
I don't see anything to disagree with there.
Jakub SkoczenFebruary 9, 2017 at 3:01 PM
Guys, this can wait and we can revisit in sprint 9 so feel free to ignore my questions for now.
I slightly worry about the premise of this issue, it might be my OOP background and so I'm open to hearing the reasons why what I propose is not applicable here.
When it comes to UI components both presentation and behavior should be shared through the re-use/re-purpose of components. That is:
composition (nesting re-usable components like DatePicker within other components like MultiColumnList),
specialization (which in traditional OOP UI frameworks like Swing or Android would mean "subclassing" aka "inheritance", to modify behavior also called "presentation logic")
Because of the nature of React component model (do correct my blasphemy Jason) there's no specialization per-se, rather composition is always used, but with two types of components: presentation (dumb) and containers (smart/logic). Which is fine because eventually this model leads to the same thing.
So finally, after this lengthy preamble: why can't we use React's component model to share (and allow consumers to re-use/override) both presentation and behavior (here: searching, sorting, filtering). There is obviously a need for "utility" methods but imho they should be much "lower-level" things.
Once the Users UI module has similar filtering to that of the Items UI module (STRIPES-171), we will have quite a lot of shared code between the two modules – all the stuff that handles searching, sorting and filtering will be near-duplicated.
We will need to figure out the best way to factor the common code out into a shared set of utilities – possibly the beginnings of the
stripes-utilsor similar repository. This may turn out to be quite a significant hunk of work, involving taste and judgement as well as engineering, and perhaps requiring some subtasks.