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.
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.
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.
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.
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!
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
createSliceutility 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.
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.
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 :)
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.