redux-toolkit

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

published then the authors' might have noticed how complicated they are at the outset and perhaps decided to solve the simpler problems first and build the complexity slowly. "It is a poor workperson that blames her tools"

ne a different TS type for _every_ TS major+minor version combo, and then used that to decide what the RTK type should look like conditionally [1]. Another pain point is debugging type transformations. I reworked the Reselect types in 4.1.x to do a much better job of inferring the argument types for the final selector, based on the intersection of all the input selector arguments. This ended up as a monstrous type that does a types-level map + transpose + intersection [2]. It took me weeks to get this working right, and I frequently had to break it down into multiple small intermediate types to see how TS was processing each step. I know that someone on Twitter was recently working on an alternate TS type-checker based on bytecode, and they said they had some kind of a working types-level debugger [3]. Having something like that officially, where I could see each step of how TS was transforming the types, would be _hugely_ valuable. There's a couple folks like AndaristRake who are able to dig into the internals of the TS compiler itself to trace how it's interpreting the types. I definitely don't have that ability :) [0] https://blog.isquaredsoftware.com/2022/05/presentations-ts-l... [1] https://github.com/reduxjs/redux-toolkit/pull/2547 [2] https://github.com/reduxjs/reselect/blob/v4.1.5/src/types.ts... [3] https://twitter.com/MarcJSchmidt/status/1539787500788613120

g used as cached data, it might actually be a good candidate for our RTK Query data fetching and caching API [1] [2]. If on the other hand you need those for a lot of other calculations in the slices, then RTKQ probably isn't the right choice. `createAsyncThunk` specifically implements the standard "dispatch actions based on an async request lifecycle" pattern that's always been taught for Redux usage [3]. That way, you only have to provide a "payload creator" function that makes the async request and returns the data, and it dispatches the actions for you. Typically you then dispatch the thunk itself from a component, like `dispatch(fetchMyData())`. FWIW I and the other Redux maintainers generally hang out in the `#redux` channel in the Reactiflux Discord ( https://www.reactiflux.com ), and we're always happy to chat and answer questions. Please drop by when you get a chance - I'd love to discuss some of these topics in more detail! [0] https://github.com/reduxjs/redux-toolkit/pull/948 [1] https://redux-toolkit.js.org/rtk-query/overview [2] https://redux.js.org/tutorials/essentials/part-7-rtk-query-b... [3] https://redux.js.org/tutorials/fundamentals/part-7-standard-... [4] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

`take`, `condition`, and `delay` I think we've been able to to come up with something that can handle maybe 75% of what sagas can do with a much smaller API surface and bundle size. I'd love to have you or anyone else using Redux take a look and give us some feedback on the current API design and let us know if there's other use cases it ought to cover: https://github.com/reduxjs/redux-toolkit/discussions/1648

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