RFC: Think through re-usable card components for specific kinds of data
Description
Environment
Potential Workaround
Checklist
hideTestRail: Results
Activity

Mike Taylor April 8, 2020 at 2:42 PM
Thanks, Mark! I declare this issue to have passed on. This issue is no more! It has ceased to be! It's expired and gone to meet its maker! It's a stiff! Bereft of life, it rests in peace! If I hadn't nailed it to the perch it'd be pushing up the daisies! Its metabolic processes are now history! It's off the twig! It's kicked the bucket, it's shuffled off its mortal coil, run down the curtain and joined the bleedin' choir invisible!! THIS IS AN EX-ISSUE!!

md331 April 8, 2020 at 2:02 PM

Mike Taylor April 8, 2020 at 10:30 AM
I want to close this issue (as a part of my general push to clean up some long-lived issues that are assigned to me).
My thinking is that, with the best part of a year having passed since we last discussed this, we seem to have converged on the practical outcome that we don't really want repositories or modules of shared cards at all — because in reality each app that wants to display (say) a user card or an item card has its own ideas about exactly what information should be included and how it should be presented. Rather than providing, maintaining and using a shared user-card component It's easier just to have my app throw together its own user card.
At least, so far as I know, we do not yet have a single example of a card that is used by multiple apps. Does anyone else know of one?
Unless anyone has any examples of this happening, or any new insights, I propose to close this as essentially talked out.

md331 July 9, 2019 at 2:43 PMEdited
I think exporting directly from ui-excitement is a non-starter, as that would mean the component coming from the same NPM package as the app, and therefore sharing all its dependencies.
I get why this creates mental anguish, but I argue that any app that is consuming ui-fun-times-components
is almost certainly running on a platform that contains ui-fun-times
already, so I don't see the practical downside to this approach.

Mike Taylor July 9, 2019 at 2:40 PMEdited
Thanks, Mark. This is helpful, and corresponds fairly closely to my own feelings. I mentioned the symlink option for completeness, but share your horror at the idea of returning to that swamp.
I think exporting directly from ui-excitement
is a non-starter, as that would mean the component coming from the same NPM package as the app, and therefore sharing all its dependencies.
So I am increasingly thinking that a separate ui-whatever-components
package, in its own repo, is the way to go.
I wish I could remember exactly what it was that went wrong with ui-example
, that made us decide to separate it out of stripes-core
into its own repo.
Once we have the re-usable card component (STCOM-534), we're going to want to start using cards in lots of different displays, and many of them will be the same: for example, many different apps will need an Item card. How can we make a re-usable card for items, another for users, etc.?
This is not really an issue for implementing, but for discussing the architectural implications. For example: where should such components live?
Each in its own package?
All in one new stripes-cards package?
In stripes-smart-components?
Each in the app that naturally "owns" that kind of data?
The last of these is appealing, but then raises the question of how apps could best export such card components. And then we get into the notion of apps depending on other apps.
(This is a sort-of-duplicate of an issue that I've been assigned in ReShare — https://openlibraryenvironment.atlassian.net/browse/PR-180 — but all the people I need to discuss this with are on the FOLIO tracker but not that one, hence this issue.)