[acemarke]

I do get the arguments that you're making here about Svelte, and don't disagree. That said, "Modern Redux" code is very different than what you've probably seen even just a couple years ago. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that provide a light abstraction to simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the traditional connect API.

If you get a chance, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to show both how Redux works and show our recommended practices:

- "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit

- "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns

The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.

You should also read through the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps.

Finally, we've got an upcoming "RTK Query" API that we're finalizing and adding to Redux Toolkit (inspired by tools like React Query and Apollo) , which should drastically simplify the data fetching story for Redux apps.

[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[1] https://redux.js.org/tutorials/fundamentals/part-1-overview

[2] https://redux.js.org/style-guide/style-guide

[3] https://rtk-query-docs.netlify.app

[dmitriid]

I can agree on redux hooks being a better alternative to the whole mapToState cycle. But if you go into the new tutorials, they quickly devolve into the same old: https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

Oh, look, slices, and thunks, and asyncThunks, and extraReducers, and adapters, and fifteen files to tie all this together for every small piece of api or data that you want to send around.

Most of it just comes from the fact that Javascript doesn't have a good built-in way of doing these cycles fo data/store updates. And still, I don't know where the sweet spot of Redux it: it's an overkill for small apps, it's unmanageable in big apps.

However, I will concede that the new hooks like `useDispatch` are nice

[acemarke]

I'm not sure how you're looking at that docs page and saying that it "devolves into the same old". That page explicitly shows how RTK simplifies existing Redux patterns. Yes, concepts like "thunks" and "reducers" still exist. Yes, there are new APIs like `createSlice` and `createEntityAdapter`, which have their own options. That's because we've seen how people are using Redux, and have built those APIs to help solve the use cases people are dealing with. But no, the code you write today is drastically different, and we've gotten tons of positive feedback about how much people enjoy using RTK.

It's also definitely _not_ "15 files to tie this all together". In fact, we specifically recommend writing all the Redux logic for a given feature in a single "slice file":

- https://redux.js.org/style-guide/style-guide#structure-files...

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

[dmitriid]

> That page explicitly shows how RTK simplifies existing Redux patterns.

The page is a tutorial for a TODO list with only the simplest and the happiest paths. It's not a forum just because you called it a forum, by the way.

OT: I wish the JS world would stop doing TODO lists. A TODO list is a glorified `Array.push`. If it takes your library/framework 10 000 words to explain how to do Array.push, it doesn't mean that a TODO list is a good example on which to base a tutorial. It means your library sucks. If you want to show how great you library is, implement this: https://tonsky.me/blog/datascript-chat/ (demo: http://tonsky.me/datascript-chat/) and manage to describe it in as many words as on that page.

Back to the topic at hand.

The problem with Redux is: it's concept is very simple. The implementation is a poorly specified DSL with isolated parts that barely fit each other, if at all. And even with all the simplifications it can barely manage to make a TODO list with happy paths.

Here's where it all falls apart:

- It looks like I can't use async functions in `createSlice`. I must use a separate `createAsyncThunk`. Because reasons. Because in a world where every single app needs async data fetching "if you want to have async logic interact with the store by dispatching or checking the current store state? That's where Redux middleware come in.": https://redux.js.org/tutorials/essentials/part-5-async-logic

So, suddenly, it's not "we've simplified everything", it's the same old: we need thunks, and middlewares, and whatnot to do data fetching.

Note in that page how `createSlice` (which is an action creator with reducers and stuff) and `createAsyncThunk` (which is an action creator for which you have to provide a store separately, and reducers to that store separately) don't ever fit with each other except through additional boilerplate code. This is especially visible in `features/posts/postsSlice.js` towards the end of the page

And why does everything need a dispatch anyway? Can't everything already be wrapped in a dispatch so that you just call a function?

- There's almost nothing about errors that will inevitably pop up.

Almost no part of the tutorial ever shows how to deal with errors except the "ah, it will magically dispatch an error message to the store, we store the message on the store".

What happens if I run into an error in a "reducer" (which is reducer-slash-action-creator) in `createSlice` and want to dispatch some action? Oh, wait, you can't dispatch actions from a reducer.

What happens if I run into an error in an action created with `createAsyncThunk` and I need to not only return an error, but dispatch some other actions?

- All this is just so, so badly specified. Everything is hidden behind "detailed explanations" that actually try to explain what's going on

For example, the fact that createAsyncThunk magically creates `.pending`, `.fulfilled` and `.rejected` on an action is not explained except sort of in passing.

And there's suddenly a magical `unwrapResult` function that's not even mentioned anywhere. What is the result of an action? It's not in Part 1 or Redux Concepts and not in Part 1 of Redux Fundamentals. I very quickly scanned the rest of the War and Peace novel, and I can't say I found it.

And there's more. I just can't quickly read and grok the 20 volumes of dense prose just to figure out how to push data into an array.

"Async logic and data fetching are always a complex topic." Nope. It's not. Redux makes it a complex topic.

---

So yeah, it all very quickly devolves into the very same "15 different files for every small action". You may collocate some of them in a single file, but that doesn't make them even closely related to each other in any meaningful way.

That's why I said, "I don't know where the sweet spot of Redux it: it's an overkill for small apps, it's unmanageable in big apps."

And it's not all bad. The biggest step towards simplifying Redux have been hooks. `useDispatch` and `useSelector` are really good. Even though we have to admit that they are solving the issues that Redux introduced in the first place :)

[JoeyJoJoJr]

Your comment really cuts through to the truth about Redux, and gave me flashbacks to my “what the hell” moment the first time I needed to perform a fetch, and the subsequent painful mentoring of a junior dev who just couldn’t get it. Two other junior devs quit because they inherited a React codebase using RX. I couldn’t really blame them.