react-redux

ping imports) ## Redux core 5.0: - The TS conversion we did in 2019! - Action types _must_ be strings - `UnknownAction` as the default action type - Better preloaded state types - Internal subscription improvements - Still marks `createStore` as deprecated! - https://github.com/reduxjs/redux/releases/tag/v5.0.0 ## React-Redux 9.0: - *Now requires React 18 and RTK 2.0 / Redux 5.0* - Updates dev-mode checks - Throws better errors in an RSC environment - https://github.com/reduxjs/react-redux/releases/tag/v9.0.0 ## Reselect 5.0: - Switches to a new `weakMapMemoize` memoizer as default - Renames `defaultMemoize` to `lruMemoize` - Allows passing memoizer options direct to `createSelector` - Many TS improvements - https://github.com/reduxjs/reselect/releases/tag/v5.0.1 ## Redux Thunk 3.0: - Drops the default export and switches to named exports ( `{thunk, withExtraArgument}` ) - https://github.com/reduxjs/redux-thunk/releases/tag/v3.1.0 This has been a _huge_ year-long development effort! We're thrilled to get these improvements out. The tooling and bundle improvements will help all users, and we think the features and TS changes will improve the Redux dev experience significantly. Thank you SO MUCH to everyone who has contributed or helped test out the work! Please file bug reports for the inevitable issues that pop up post-release! but now I'm going off on a conf trip and going to take a very well-earned break from Redux work for December :)

lease v8 as final in the next week or two.

m the store, and create pre-typed React-Redux hooks (which are _much_ easier to type than the legacy `connect` API) to save from repeating those types in components. For each slice reducer, you'd add a TS type for the slice's state, and declare the type of each action's contents as `action: PayloadAction<string>`, etc. For React components, add a type declaration for the props of each component, and add types to function arguments as necessary (change handlers, etc). The React TypeScript CheatSheet [1] is a fantastic resource for learning how to use TS + React together. Also be sure to type any data coming into the system, such as API responses, and any other "business logic" you might have. Those should get you 80%-ish types coverage without too much effort, and all you really need to know is how to declare types for objects+primitives, and a few bits from the React and Redux lib types. I also strongly disagree with many of the "recommended" TS-related linting rules, like "always declare a return type for every function". It's not _wrong_ to have those, but in my experience TS works best when you can let the compiler infer as much as possible. I still firmly believe that for _app_ development, it's not worth spending hours and hours arguing with the compiler to come up with a "perfect 100% correct" type definition for more complicated scenarios. If you know that a function takes `TypeA` as an input and returns a `TypeB`, but there's really complex transformations inside and it's really hard to convince the compiler what you're doing is correct, feel free to do whatever `as` casting or `// @ts-ignore` you need to in the middle. Library types, on the other hand, are the opposite case. Library APIs are often highly generic in both the "use case" and "TS types" senses. There, it _is_ worth spending the time to come up with very complex typedefs with tons of generics and conditional types, because those are often needed to make the _end user experience_ a lot easier. Try looking at the types for Redux Toolkit, React-Redux, or Reselect [2] [3] [4] - our types are complex, so _your_ code doesn't have to be. I spent a ton of time just yesterday trying to make improvements to the Reselect types, because as a maintainer I want our users to have a good experience. But for you as an app dev, it should be a lot simpler. The payoff is that you get all the nice benefits of TS: static detection of common errors like typos and mismatched fields, documentation of your data structures, intellisense, confidence in refactoring, less need to write repetitive "is this argument the right type?" logic, and much more. [0] https://redux.js.org/tutorials/typescript-quick-start [1] https://react-typescript-cheatsheet.netlify.app/ [2] https://github.com/reduxjs/redux-toolkit/blob/v1.6.2/package... [3] https://github.com/reduxjs/react-redux/blob/v8.0.0-alpha.1/s... [4] https://github.com/reduxjs/reselect/blob/v4.1.2/src/index.ts...

ct` [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

e able to work better with CM and Suspense: https://github.com/reduxjs/react-redux/issues/1351