crux VS react-18

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

If you aren't sure why state tearing was a hot topic a few years ago, when React's concurrent mode was first discussed, this github discussion should help: https://github.com/reactwg/react-18/discussions/69.

Tanner Linsley had a great post on twitter that suggested that concurrent rendering was fundamentally at odds with fine-grained reactivity, so to better understand what he was talking about I decided to write this demo.

Image Source: https://github.com/reactwg/react-18/discussions/37

But it does since React 18.

See this post for more details and an example of an actual memory leak.

From the React WG:

The React working group is officially advising against using runtime CSS-in-JS.