Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/goosewobbler/zutron
Streamlined Electron State Management
https://github.com/goosewobbler/zutron
electron electronjs state-management zustand
Last synced: 18 days ago
JSON representation
Streamlined Electron State Management
- Host: GitHub
- URL: https://github.com/goosewobbler/zutron
- Owner: goosewobbler
- Created: 2024-03-24T12:39:54.000Z (10 months ago)
- Default Branch: main
- Last Pushed: 2024-12-06T02:17:26.000Z (about 1 month ago)
- Last Synced: 2024-12-06T02:32:36.100Z (about 1 month ago)
- Topics: electron, electronjs, state-management, zustand
- Language: TypeScript
- Homepage:
- Size: 2.28 MB
- Stars: 26
- Watchers: 1
- Forks: 1
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
_streamlined electron state management_
### Why
> tldr: I want to use Zustand in my Electron app, seamlessly
[Zustand](https://github.com/pmndrs/zustand) is a great state management library. As with other state libraries [such as Redux](https://redux.js.org/tutorials/fundamentals/part-4-store#redux-store), it is [recommended](https://zustand.docs.pmnd.rs/guides/flux-inspired-practice#recommended-patterns) that a single store is used in your app.
For Electron apps this is an awkward problem as you need access to the store in both the main and renderer processes.
Zutron enables a single store workflow with Zustand in Electron apps, effectively simplifying the use of Zustand in this context by abstracting away the necessary IPC and dispatch management.
### Features
- Use Zustand everywhere in your Electron app
- Single store workflow across IPC boundary
- Works with the latest [Electron security recommendations](https://www.electronjs.org/docs/latest/tutorial/security#checklist-security-recommendations)
- Supports different Zustand usage patterns
- Handles thunks, inline actions or Redux-style action objects
### How It Works
Zutron uses an additional Zustand store in the renderer process, this store is synchronized in one direction with your application store in the main process.
Actions from the renderer process are dispatched across IPC to the main process store, which handles them and updates state accordingly. The renderer store then receives these state updates over IPC and updates itself accordingly.
#### Accessing The Store
- Renderer process
- Store state can be accessed via the `useStore` hook
- Actions & thunks can be dispatched via the `useDispatch` hook
- Main process
- Store state can be accessed directly in the same way you normally use Zustand
- Actions & thunks can be dispatched via the `dispatch` helper
### Getting Started
See the [docs](./docs/getting-started.md).
There are minimal example applications featuring three different Zustand usage patterns:
- [Redux-style reducers](./apps/example-reducers)
- [Separate handlers](./apps/example-separate-handlers)
- [Store-based handlers](./apps/example-store-handlers)
### Inspiration / Prior Art
This project would not exist without Reduxtron, shout out to vitordino for creating it!
- [vitordino/reduxtron](https://github.com/vitordino/reduxtron)
- Redux store in the main process, optionally synced to Zustand in the renderer
- Zutron is based on Reduxtron
- Great for Redux users, not an option if you want to use Zustand everywhere
- [klarna/electron-redux](https://github.com/klarna/electron-redux)
- Bi-directional sync between one Redux store in the main process, and another in the renderer
- No longer maintained
- I created [a fork](https://github.com/goosewobbler/electron-redux) to enable support for [electron >= 14](https://github.com/klarna/electron-redux/issues/317), however I won't be spending any more time on this approach