gaperton
commented
7 years ago Alternative proposals.
1) Use store declaration instead of state. It should define the model extending Store, which is integrated into dynamic store lookup chain across the UI components tree. In this case:
- root component have to pass store elements down explicitly
- children state might rely on the references to the store elements
- children actually can access parent store using the
getStore()locator. The thingy works as an alternative to thecontext. Allows potentially dangerous programming style.
Since we're finally moving to hierarchical stores architecture, we need to implement support for it in React components (one main global shared store + may be some other stores shared across the pages +local store for each app page extending the main one). We need several things.
1) There's the root component for an application page. The lifecycle of the page local store is really bound to its presence in DOM. Therefore, we either need to declare the store at the component itself or provide it with a reference to existing one. In the first case, it would be beneficial if the component would completely manage the store lifecycle, including I/O (not rendered until I/O is completed).
It's probably the good idea to wrap store management to the separate component. When it's mounted, it fetches itself.
Consider making this component generally I/O aware (capable of simple REST stuff and accepting an I/O promises). That will reduce latency in case of the root page.
2) Nested Store components must process chained store lookups.
3) Think what to do whenever store items are updated. Should the component tree be updated too? Should be not worse than dealing with root state. There might be an issue with pureRender, though (it will ignore store updates). Also, there might be an issue with tracking of updates across store hierarchy (should we really track changes for all the store chain items?).
Alternative is to provide the list of the store elements to access and track the changes in.