Details
-
Task
-
Status: Closed (View Workflow)
-
P4
-
Resolution: Done
-
None
-
None
-
None
Description
This comes out of discussion on Slack with Jakub, related to OKAPI-300.
We are interested in the idea of establishing a convention for Stripes components that do what we call "trivial join", so we reduce the burden on Business Logic modules without going so far as to impose the burden of a GraphQL implementation on the back end.
As an example, I might make a component that lists a set of users, together with the permissions for each of them. That is analogous the output of an SQL statement like SELECT * FROM Users, Perms where Perms.userId = Users.id.
I think we can find nice ways to do this, and derive conventions which module authors can use when they need to do something similar; it may even be possible, once we've figured out what the pattern is, to extract it into a Higher-Order Component or similar.
This is fundamentally an exploratory task: the output is not a component that can list multiple users with their permissions, but an increased understanding of how to make components of that kind.
TestRail: Results
Attachments
Issue Links
- blocks
-
-
- Closed
-
-
-
- Closed
-
- is blocked by
-
STCON-1 Peer components with different dataKey should store separate data
-
- Closed
-
-
STCON-8 Data should be stored per-component, not per-module
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
