Closed VanishMax closed 1 month ago
Curious your thoughts on Dan Abramov's comment. Is this implementation of signals getting us into a place that will hurt future upgrades?
Mobx has a quite similar, signal-esc API. Should we consider that instead for less future risk?
Also, I wonder what state management libraries will be compatible with server components if/when we use this.
@grod220 You might be right about Signals – it might truly be broken in the future, my oversight. I still believe it's React's problem that it cannot support this API without hacks.
Anyway, after a couple more thoughts, I tend towards Zustand instead of Mobx. They both are great in terms of the component updates only when necessary but Mobx discourages me with its observer
HOC and the need to pass the state instance as props – usually this means having global state.
Before changing this PR, I propose we use Zustand but differently from Penumbra Minifront. We should not try to implement global state with Zustand but keep it localized by feature. Let's say we have a feature "sync status" that requests data and stores it in the state. It would be best to place UI, api and state in the same directory, and keep it as independent as possible. Having the global state makes it mostly uncontrollable and more difficult to test. Local by-feature state would help decouple the code and make it more scalable and future proof.
As for the server components, idk if they even need state management. So far I've only seen the minimal request-and-render server components.
Taken over by https://github.com/penumbra-zone/dex-explorer/pull/77
Closes #66
Closes #67
This PR sets up the Zustand as the state management library and showcases its usage with the sync feature