Hacker News new | past | comments | ask | show | jobs | submit login

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...




> 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 :)


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.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: