3 ms·

> Why wasn't enough thought put in in the original Redux? Because times change, ecosystems change, patterns change, and user bases change. Why isn't React sti

> Why wasn't enough thought put in in the original Redux? Because times change, ecosystems change, patterns change, and user bases change. Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Why did C++ add an `auto` keyword? Why is there ever a new version of a language or library? Wasn't enough thought put into them in the first place? > Just make it easier to use And that's exactly what we did :) "Modern Redux" code is different because: - We've seen how people have used Redux in practice, what they wanted to do, and what problems they've run into - We've seen what solutions and other Redux-related libraries the community has invented to solve their problems - And there's new tools and APIs that have come out since Redux was created, like Immer for immutable updates and React Hooks for writing reusable logic in React components Like I said, this isn't about "new Redux concepts". It's still state, actions, reducers, dispatching, and subscribing in the UI. It's just much less code to do it, and prevention of common mistakes while using Redux. That means smaller bundles, faster development, and fewer bugs. This tutorial page shows how Redux Toolkit simplifies all the older Redux logic patterns: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... I can't force you or anyone else to use RTK, or to use Redux. If you've got other options that are working for you, please use them. I'm just pointing out that we _have_ specifically addressed the very concerns you're raising, and if you are genuinely concerned about those issues, you _might_ want to take a look at what we've put together... and I've got a whole lot of enthusiastic RTK users who can vouch for how it's made their development lives and Redux usage experience a lot better.

yakshaving_jgt 6y ago
> Because times change, ecosystems change, patterns change, and user bases change. Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Why did C++ add an `auto` keyword? Why is there ever a new version of a language or library? Wasn't enough thought put into them in the first place? I think the comment you are responding to is a little harsh, but I find this part of your argument disingenuous. JavaScript's syntactic expansion is not definitely a good thing — it isn't all progress. The rhetorical questions you have presented seem to imply that JavaScript gaining classes is obviously a good thing, whereas I strongly doubt everyone agrees. Did prototypical inheritance work? Yes. Does JavaScript still have prototypical inheritance? Also yes. Is it better to have more choice? Not necessarily. The result of this has been more fragmentation, more documentation, more for beginners to learn, more framework churn, etc. JavaScript the language was originally invented in just 10 days, and the author himself has explained that aside from the deadline pressure, there are regrettable reasons for the language's inconsistent API.
- acemarke 6y ago
  I'm afraid that if you're focusing on the technical merits of prototypal inheritance vs classes, you've missed my point completely. The parent comment seems to be arguing that a library or tool should be perfect in its very first release - that the designers should have anticipated every possible use case, target audience, and piece of API design. My point was that _everything_ in technology evolves over time, and Redux is no exception. The Redux core _is_ exceptionally well designed, especially given that Dan and Andrew really only worked on it for a two-month stretch. During that time, they iterated on multiple ideas, particularly the transition from "stores" to "stateless stores" to "reducers", and coming up with the middleware API as a way to allow pluggable side effects logic. Similarly, the design discussion for what became `connect` [0] shows from the very first comment exactly what design constraints were relevant, and while it took some time to nail down the specifics, Dan clearly had the key criteria in mind. At the same time, many of their early ideas about how Redux would be used turned out to be wrong. Dan assumed that people would likely only connect top-level components, and it turns out that connecting many components across the tree is better for performance. Andrew came up with the "Flux Standard Actions" standard, but his idea of having `{error: true, payload: new Error()}` and reusing the same action type for errors and successes has been completely ignored by the ecosystem - it's a lot easier to have separate action types for success and failure. They both thought that thunks were a stopgap that would quickly be replaced by something else, and neither of them could have anticipated the creation of Immer. So, in the real world, no tool is ever designed perfectly from day 1. Requirements change and usage patterns patterns change. That's why libraries and tools publish new versions - to respond to those changing situations. That's why we created and designed Redux Toolkit - to respond to the changes in how people want to use Redux, and the pain points they've experienced using it. [0] https://github.com/reduxjs/react-redux/issues/1 https://github.com/reduxjs/react-redux/issues/1
  - yakshaving_jgt 6y ago
    > I'm afraid that if you're focusing on the technical merits of prototypal inheritance vs classes, you've missed my point completely. That's not what I'm focusing on, and I don't know how you've managed to interpret my comment that way. In your comment, you said this: > Why were ES6 classes and hooks invented? That's why I used classes as a concrete example of the larger point that I was trying to make. My point is that change is fine, but just continually adding stuff to appease people is not necessarily a good thing. All that's happened to JavaScript — as I already pointed out — is the foot-gun now has a wider blast radius and less travel on the trigger.
valenterry 6y ago
A perspective from a backend developer who is spoiled from working with very good programming languages: > Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Sorry, but all of these are mistakes. I predict that hooks will not survive the battle of time as well as react as a whole will. Arrow functions are mere syntatic sugar, but async/await was a mistake.
- robertlagrant 6y ago
  Exactly! What's the point of a widescreen monitor if I can't have promises 10 levels deep?
  - valenterry 6y ago
    Any half modern language has a syntax construct for it. Unfortunately Javascript is on it's way but not there yet. I could explain it, but it's already described here better than I could: https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb1376c80 https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb... (scroll to "do-notation")
    - robertlagrant 6y ago
      > Now everything is good and JavaScript is great again, yet I wonder why it took so long Have you read it? It's saying Javascript has something like that.
      - valenterry 6y ago
        No it's not. It is saying Javascript has asnyc/await which is just a specialization of the more general monad-o-syntax (or however you want to call it). And that is precisely what I meant.
        robertlagrant 6y ago
        The article likes them; you said they're a mistake.

yakshaving_jgt 6y ago

> Because times change, ecosystems change, patterns change, and user bases change. Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Why did C++ add an `auto` keyword? Why is there ever a new version of a language or library? Wasn't enough thought put into them in the first place? I think the comment you are responding to is a little harsh, but I find this part of your argument disingenuous. JavaScript's syntactic expansion is not definitely a good thing — it isn't all progress. The rhetorical questions you have presented seem to imply that JavaScript gaining classes is obviously a good thing, whereas I strongly doubt everyone agrees. Did prototypical inheritance work? Yes. Does JavaScript still have prototypical inheritance? Also yes. Is it better to have more choice? Not necessarily. The result of this has been more fragmentation, more documentation, more for beginners to learn, more framework churn, etc. JavaScript the language was originally invented in just 10 days, and the author himself has explained that aside from the deadline pressure, there are regrettable reasons for the language's inconsistent API.

acemarke 6y ago
I'm afraid that if you're focusing on the technical merits of prototypal inheritance vs classes, you've missed my point completely. The parent comment seems to be arguing that a library or tool should be perfect in its very first release - that the designers should have anticipated every possible use case, target audience, and piece of API design. My point was that _everything_ in technology evolves over time, and Redux is no exception. The Redux core _is_ exceptionally well designed, especially given that Dan and Andrew really only worked on it for a two-month stretch. During that time, they iterated on multiple ideas, particularly the transition from "stores" to "stateless stores" to "reducers", and coming up with the middleware API as a way to allow pluggable side effects logic. Similarly, the design discussion for what became `connect` [0] shows from the very first comment exactly what design constraints were relevant, and while it took some time to nail down the specifics, Dan clearly had the key criteria in mind. At the same time, many of their early ideas about how Redux would be used turned out to be wrong. Dan assumed that people would likely only connect top-level components, and it turns out that connecting many components across the tree is better for performance. Andrew came up with the "Flux Standard Actions" standard, but his idea of having `{error: true, payload: new Error()}` and reusing the same action type for errors and successes has been completely ignored by the ecosystem - it's a lot easier to have separate action types for success and failure. They both thought that thunks were a stopgap that would quickly be replaced by something else, and neither of them could have anticipated the creation of Immer. So, in the real world, no tool is ever designed perfectly from day 1. Requirements change and usage patterns patterns change. That's why libraries and tools publish new versions - to respond to those changing situations. That's why we created and designed Redux Toolkit - to respond to the changes in how people want to use Redux, and the pain points they've experienced using it. [0] https://github.com/reduxjs/react-redux/issues/1 https://github.com/reduxjs/react-redux/issues/1
- yakshaving_jgt 6y ago
  > I'm afraid that if you're focusing on the technical merits of prototypal inheritance vs classes, you've missed my point completely. That's not what I'm focusing on, and I don't know how you've managed to interpret my comment that way. In your comment, you said this: > Why were ES6 classes and hooks invented? That's why I used classes as a concrete example of the larger point that I was trying to make. My point is that change is fine, but just continually adding stuff to appease people is not necessarily a good thing. All that's happened to JavaScript — as I already pointed out — is the foot-gun now has a wider blast radius and less travel on the trigger.

valenterry 6y ago

A perspective from a backend developer who is spoiled from working with very good programming languages: > Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Sorry, but all of these are mistakes. I predict that hooks will not survive the battle of time as well as react as a whole will. Arrow functions are mere syntatic sugar, but async/await was a mistake.

robertlagrant 6y ago
Exactly! What's the point of a widescreen monitor if I can't have promises 10 levels deep?
- valenterry 6y ago
  Any half modern language has a syntax construct for it. Unfortunately Javascript is on it's way but not there yet. I could explain it, but it's already described here better than I could: https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb1376c80 https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb... (scroll to "do-notation")
  - robertlagrant 6y ago
    > Now everything is good and JavaScript is great again, yet I wonder why it took so long Have you read it? It's saying Javascript has something like that.
    - valenterry 6y ago
      No it's not. It is saying Javascript has asnyc/await which is just a specialization of the more general monad-o-syntax (or however you want to call it). And that is precisely what I meant.
      - robertlagrant 6y ago
        The article likes them; you said they're a mistake.