cryostatio / cryostatio/cryostat-web
[Task] Optimize app state storage
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 13
- Forks
- 21
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 42
Description
> I think that middleware looks reasonable for achieving the goal you set out for (don't read/write the entire store when only one piece changed).
> But, this is evolving the way I anticipated it would - it's a big application-wide global storage that lives outside of the component hierarchy and lifecycle, and then to give it better encapsulation and better performance characteristics for those components it ends up getting cut down into separate pieces that map pretty closely to components and their lifecycle within the hierarchy. In that situation we should question why there's such a global store being established if in the end we divide it up again. Separate pieces of state storage attached to the components do effectively the same thing, except with less extra management pieces that try to glob everything up together into one big chunk. I think that model probably makes more sense for larger applications using server-side rendering where there is just a lot more state, but here it seems like Redux is a lot of overkill. On the other hand, the previous system I set up using just `React.useState()`, Contexts, and direct `localStorage` isn't great either because there's a lot of hand-rolled code that means each component using persistence is doing it in its own way with its own implementation quirks.
> I think that comment I linked earlier from the Jotai issues board sums up the situation very well. Zustand looks to me a lot like Redux in concept, but with a nicer and smoother API. Jotai looks a lot like `React.useState()`, and I really like that. I can imagine that our problems with duplicate AA cards on the dashboard would be solved quite easily by asking the user to give a unique title to the AA card when they're configuring it, and then doing `const cardConfigAtom = atomWithStorage(props.cardTitle, defaultConfigOptions); const [cardConfig, setCardConfig] = useAtom(cardConfigAtom)` . There needs to be a cleanup step to delete the config from storage when the card is removed from the dashboard, but that should be quite straightforward to do, too.
> Not saying we should switch to Jotai necessarily. But, it looks to me like the Redux optimizations are tending in a direction like that, so it's at least a design to keep in mind either with this extra middleware for Redux, or for removing Redux and adding some "middleware" that is inspired by Jotai and goes back to simply wrapping around useState/localStorage.
_Originally posted by @andrewazores in https://github.com/cryostatio/cryostat-web/issues/753#issuecomment-1350345106_
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no repository files or tests. Start by reading issue #753 and the discussion of Redux, Jotai, React state, Contexts, and localStorage; define the intended storage approach and scope before implementation. Done would require an agreed design and the corresponding app-wide storage optimization.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, redux, typescript
- Domain
- frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100