Factor out shared code in search-based modules
Description
Environment
Potential Workaround
blocks
is blocked by
relates to
Checklist
hideTestRail: Results
Activity
Matt Connolly January 12, 2018 at 4:13 PM
The issue title makes it ambiguous: it could mean either refactoring the common code into something new – i.e., <SearchAndSort> – or else refactoring all the modules to use it. I'd agree with keeping this one closed and creating a new umbrella issue if needed.
Mike Taylor January 12, 2018 at 4:01 PM
Well, it was a sort of an informal umbrella for the work that I was doing. But if we want a higher-level umbrella for all code-deduplication, I'd support that. (It just wouldn't be assigned to me.)
Cate Boerema January 12, 2018 at 3:59 PM
Oh, I was thinking of this an an umbrella issue. Guess that's not what it is.
Mike Taylor January 12, 2018 at 3:50 PM
That is presumably its own issue. We don't need to keep this old one open until that's done, as there is nothing more to actually be done here that's not covered by the new issue.
Cate Boerema January 12, 2018 at 3:47 PM
I think we should leave this open until Matt completes the refactoring of Requests to use SearchandSort.
As previously discussed in several places (e.g. , STRIPES-452), we have a lot of near-duplicate code in ui-users and ui-items, the first two modules that are based on searching, listing, viewing and editing records of different types. Now with , , , and maybe others, we are in danger of creating a third nearly-the-same-but-not-quite module by copy-pasting and editing the result.
This is probably the right time to take the concrete lessons of ui-users and ui-items, and use them to create a general framework for such modules – and then to make ui-requests another instance of that general framework. (We did much the same for the modules' settings pages in STRIPES-343, which gave us the
<Settings>component which now also underlies ui-organization and other modules.)This is potentially a wide-ranging task. It will need some careful design, some refactoring in ui-users and ui-items, possibly some improvements in test-suite coverage, and new documentation. The good news is that, once done, it should make many of the ui-requests issues trivial to implement.