react-easy-state VS crux

I've really enjoyed react-easy-state

For state, I love to use React Easy State.

react-easy-state was very easy.

If you want to try something a bit different with regards to state management, you can try: https://github.com/RisingStack/react-easy-state

Nope, react-easy-state is much easier: https://github.com/RisingStack/react-easy-state

I personally prefer to work with react-easy-state instead of using Redux or even the built-in state management in React.

Just started using react-easy-state in a project, and I have to say I love it. In the past, I used Redux/RTK for global state management, along with Redux Thunk or Redux Saga for side effects. In contrast, react-easy-state is easy and requires so much less boilerplate to setup and worry about. I’m fully comfortable using Redux in apps and have done it plenty of times, but I love how react-easy-state just works. It’s amazing being able to mutate the state from anywhere, inside and outside of components, and have it immediately reflected by components, without installing any plugins and having complex config files.

I am a big fan of react-easy-state, which uses proxies to automatically trigger re-renders when you mutate any state that the component depends on. It's a bit of a different way of using state management compared to typical immutable state examples, but it allows for some very straightforward code without much boilerplate around it.

The app for people to submit orders (drinks-user) is just a form and to manage state, I'm using React-easy-state

I built a simple router in about 50 lines: https://github.com/andyjessop/crux/blob/main/apps/dev/src/shared/router/router.service.ts

For comparison, I'm writing a front-end framework where the entire size (including router, data fetching/caching, state management) is less than the size of axios.

It's like looking in a mirror. This is exactly why I'm working on crux. Seeing as you have similar thoughts, I'd love to hear your feedback.

Immer's a cool library if you don't mind doing this at the top of every reducer: /* eslint-disable no-param-reassign */. I normally prefer some kind of immutable merge function, like this:

Wow, you've done an amazing job there. I prefer your syntax over RTKQuery, and I really like the idea of the queue. I'm implementing a similar kind of thing myself, except just for redux and not as fully-featured as your solution.

Yeah I get this. I would say two things. Firstly, this is aimed primarily at people who are already using Redux. And secondly (and more importantly), Redux itself is not inherently complex - you can write it in 20 lines of code - it's just that the accepted best practices add lots of boilerplate. I've addressed this in my createSlice library, which removes all but the most essential code from the config: https://github.com/andyjessop/crux/tree/main/packages/redux-slice

100% agree (both with your opinion and that it's controversial), that's why I'm working on my own framework that attempts to solve this issue: https://github.com/andyjessop/crux

I don't think there's an issue with boilerplate in Redux any more, especially with RTK's prevalence. I made my own createSlice that simplifies the creation of reducers and actions still further - it has an extremely straightforward API and is only 30 or so lines of code.

It's not ready for production yet (far from it), but here it is if anyone is interested in finding out more and/or contributing: https://github.com/andyjessop/crux