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