5 ms·
Hi, I'm a Redux maintainer. A few thoughts: First note is that while both of Redux's original creators (Dan Abramov and Andrew Clark) later got hired to work o
by acemarke 4y ago
Hi, I'm a Redux maintainer. A few thoughts:
First note is that while both of Redux's original creators (Dan Abramov and Andrew Clark) later got hired to work on the React team, Redux has always been an independent project, and is not "a React team" project.
Second, per "why Redux": the primary goals of Redux are 1) helping developers be able to understand where/why/when/how state has changed over time in the app, 2) predictable data flow, 3) writing more app code as predictable pure functions [0] [1]. It's true that earlier Redux usage often did involve a lot of unnecessary boilerplate. The good news is that "modern Redux" with our official Redux Toolkit package is much easier to learn and use [2] [3] [4].
Next, while I agree that modern front-end development _is_ overly complex and the tools and configuration _are_ often hard to understand, the post is unnecessarily dismissive. I'm a big believer in the idea that it helps to understand historical context, why tools were invented, and what problems they were designed to solve. The JS ecosystem has evolved dramatically in the last 15 years, including the types of apps we build and the scale of those codebases, the APIs available in browsers and Node, module formats and ES syntax versions, and many other constraints.
I'd specifically suggest reading some posts on why tools like bundlers exist and how module formats have changed over time as background that explains why modern front-end dev normally involves these tools [5] [6].
(It's also somewhat ironic that the author complains "why isn't developer experience a priority?", given that these tools and patterns were _created_ to help with DX.)
To be clear, I'm _not_ saying that everything about front-end dev is wonderful, or that there aren't any pain points. There's _lots_ of pain points! :) But it's important to understand what problems the ecosystem has been trying to solve and why these tools exist.
[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/#the-intent-and-design-of-redux https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[1] https://redux.js.org/tutorials/essentials/part-1-overview-concepts#why-should-i-use-redux https://redux.js.org/tutorials/essentials/part-1-overview-co...
[2] https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today
[3] https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu...
[4] https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode...
[5] https://www.swyx.io/jobs-of-js-build-tools https://www.swyx.io/jobs-of-js-build-tools
[6] https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-client-dev-deployment/ https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-...
- shubhamjain 4y agoHey, thanks for the feedback. Sorry for being dismissive, I can rant when I am angry. :) I checked the new Redux and honestly, it's still a bit confusing. For eg, > export const { todoAdded, todoToggled } = todosSlice.actions Where is ".actions" coming from? Because in the object we have "reducers". Is it implicitly generated? Although boilerplate has been greatly reduced, it seems the project is still sticking to the same set of terms, just hidden from the plain sight. Ultimately, I want to understand why we need anything more than actions and state. You call actions, that update the state, that updates any component which is subscribe to that store. What am I missing? That's how Vuex works. On Bundlers, my problem isn't the fact that they exist, but that you there isn't one that works easily out of the box. What compounds the problem is that practical examples are often missing from docs. This issue is a great example[1]. Crucial plugins are missing from the bundler. Even if you add plugins, you run into problem like sourcemap isn't being generated. [1]: https://github.com/rollup/rollup/issues/385 https://github.com/rollup/rollup/issues/385
- acemarke 4y agoYes, Redux Toolkit is still Redux. There's still a single store, dispatching "action" objects that describe "what happened in the app", and pure "reducer" functions that calculate new state immutably in response to those actions. None of those concepts have changed. There's just way less code to write to make that happen. `createSlice` specifically lets you write just the reducers, and automatically generates the action creators that you used to write by hand. I'm not quite sure I follow the question about Vuex. There _are_ similarities conceptually between the two libraries, and Vuex and Redux both have the same overall data flow and ultimately end up accomplishing the same goals, but the actual syntax and implementations are definitely different. It's also worth noting that "call actions, that update state, that updates components" is sort of a hand-waving over-simplification that doesn't talk about how Vuex actually _works_ which is more about "using an implicit observable-based approach to tracking mutating state updates, and then automatically forcing dependencies of those fields to redraw themselves", in contrast to Redux+React's "explicitly run reducer functions and let them decide whether to update state in response to a given action/event, then explicitly comparing derived state at the UI level to decide if UI components need to re-render". Sounds like you may not be fully familiar with how Redux works - I'd suggest going through the "Redux Fundamentals" tutorial in our docs [0] to better understand the underlying mechanics and principles without any abstractions, and it also shows how Redux Toolkit then implements those concepts with less code. [0] https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview