3 ms·

Hey, 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 e

Hey, 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 ago
Yes, 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

acemarke 4y ago

Yes, 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