legend-state VS crux

There is not much to refactor in this simple example, but if we look closer to the the legend app state lib, we can see that set can take a callback with the previous state as parameter

For signals, Signia or Legend State.

I'd love to know what you think, and I'm also happy to answer any general JavaScript performance questions if you want since I've gone very deep into optimizing . See the GitHub: https://github.com/LegendApp/legend-state

After almost a year of development and iterating, we just released Legend-State 1.0. It's the fastest React state library and is very easy to use, based on Observables (Signals) with fine-grained reactivity and built-in persistence.

I'd love to know what you think, and I'm also happy to answer any general JavaScript performance questions if you want since I've gone very deep into optimizing .

https://github.com/LegendApp/legend-state

We do plan on adding a table view, and we've designed out a general idea of how it would work. And I'm very excited about it! But I'm not sure exactly when we'll start on it. Right now we're finalizing a new state/sync system (in open source at https://github.com/LegendApp/legend-state), then we'll add support for Markdown files, then a very cool new feature we're still exploring. I think you could expect sometime early next year we'll start working on expanding the view modes (but it's all still fluid so no promises!).

Legend-state - https://legendapp.com/open-source/state/

Legend-State is good.

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