DEV Community

loading...

Discussion on: Advanced TypeScript: A Generic Function to Update and Manipulate Object Arrays

Collapse
markerikson profile image
Mark Erikson • Edited

Hi, I'm a Redux maintainer. Unfortunately, I have concerns with several of the things you've shown here in this post, and with the Redux Plate app you linked - the code patterns shown are the opposite of how we recommend people use Redux today.

The first thing I note is that the generated code from ReduxPlate is using very old patterns for action types and file structure It has "handwritten/manual" logic for action creators and reducers, and each of the different code types is being output in a separate file.

Instead, we recommend using our official Redux Toolkit package, which is the standard approach for writing Redux logic. RTK simplifies existing Redux code patterns, and is specifically designed for a good TS usage experience. You can see our recommended RTK+TS usage patterns here. We also recommend using a "feature folder" structure, with single-file "slices" for logic.

Using RTK and its createSlice utility eliminates the need to have hand-written action creators, or split that logic across multiple files, and the action types become a background implementation detail that you don't even have to think about.

Next, the generated code is defining actions as a bunch of "setter functions", like SET_FIRST_NAME. We specifically recommend that you should model actions as "events", not "setters". Modeling actions as events leads to fewer actions being dispatched, and a more readable and semantic action history. It also means there's a lot less code to write.

RTK also uses Immer inside to let you write "mutating" state update logic in reducers. That drastically simplifies the update logic.

So, while I'm always happy to see people building things with Redux, I'd really encourage to you rework the code generation and the patterns you're working with to use Redux Toolkit instead, and follow our recommended best practices. That will make things much easier for you and the people using what you've built.

Collapse
Sloan, the sloth mascot
Comment deleted
Collapse
markerikson profile image
Mark Erikson

To be honest, almost all the work on our TS types over the last couple years has been done by RTK maintainer Lenz Weber ( twitter.com/phry ). I've picked up enough TS to be able to follow some of what goes on, but there's still a lot of stuff in the codebase that's over my head :)

If you're interested in a discussion on the typings, I'd suggest talking to Lenz first.

Thread Thread
pwnball profile image
Daan van der Burgt

Oops, I deleted my post, but it can not be undone it seems, bit quick on the trigger there.

Still much appreciate the quick reply! RTK seems a fine piece of work, looking forward to diving into it. Angular is my home turf, so also looking forward to seeing the toolkit implemented in NgRx!

Keep up the good work and stay frosty :)

Collapse
fullstackchris profile image
Chris Frewin Author • Edited

Of course. I agree with all of this! At the same time, I can garuantee there are a huge number of companies that still use these deprecated patterns in their legacy code bases. This type of generation would be for them. My plan is to ultimately make ReduxPlate a new abstraction layer on top of Redux Toolkit. Additionally, I don't want to give too much of the secret sauce away, so that's why I've leaned on this deprecated generation pattern for the public facing example.

To be fair, it's probably worthwhile to note all these things in a disclaimer on the homepage.

Also, the action generation will be a main challenge and feature of ReduxPlate - can we merge actions? Add more than just the setting of a single property in state with them? This will depend a lot on customer's use cases and their own applications and code bases. All of these will eventually be possible with ReduxPlate.