Details
-
Task
-
Status: Closed (View Workflow)
-
P4
-
Resolution: Done
-
None
-
None
-
-
stripes-force Sprint 64, stripes-force Sprint 65
-
3
-
Stripes Force
-
Medium < 5 days
Description
From discussions in Madrid that came out of STRIPES-492, we concluded (I think?) that we'll retain NPM as the base unit of what gets enabled/disabled but allow modules to represent more than one "type".
I imagine this boils down to a rework of the way the stripes section of package.json such that there is some top level metadata and an array of objects with metadata for each "type" that the package acts as.
Something we didn't consider is how the package will provide the entry point for each of these types. Here's one approach: Right now we take the default export of the NPM's "main" file and stripes-core treats it according to its type. I think we can extended that such that if there is an array of types we, instead of the default, take the appropriately named export of main. eg. we'd import "app" from modules we're treating as apps and "provider" from modules we're treating as context providers.
This will clean up the situation where settings is currently populated by both app modules and settings modules; now app modules can simply also be settings modules. It will also give a mechanism we can use for stripes-core to provide some lower level access to modules wanting to make use of redux or the react context.
TestRail: Results
Attachments
Issue Links
- relates to
-
STRIPES-492 Consider generalising Stripes' notions of plugin
-
- Closed
-
-
UIAPPTEMP-5 Update app template to use "actsAs"
-
- Closed
-
-
UIP-1 Figure out UX for settings vs. preferences
-
- Closed
-