Interesting thing, thanks! I like how it reduces boilerplate.
But what i do not like at all is the way how you propose to use it with declarative data loaders. I think a better solution would be to use react context for the data from a loader. The other way would be to create your own declarative data loading solution which will use the flex reducer to store the data instead of a built in useReducer.
Thank you for your feedback.
Yes, you are right, and that's what I'm talking about. The imperative Redux-like style to keep all data in state doesn't work well with declarative style like react-query does.
I like your suggestion to use context for propagate loaded data, it could be a good way.
About create own declarative data loader - not sure how to merge this 2 approaches that it looks good. It can be confusing when loader returns data and also put it somewhere in state automatically and calls re-render.
Interesting thing, thanks! I like how it reduces boilerplate.
But what i do not like at all is the way how you propose to use it with declarative data loaders. I think a better solution would be to use react context for the data from a loader. The other way would be to create your own declarative data loading solution which will use the flex reducer to store the data instead of a built in useReducer.
Thank you for your feedback.
Yes, you are right, and that's what I'm talking about. The imperative Redux-like style to keep all data in state doesn't work well with declarative style like react-query does.
I like your suggestion to use context for propagate loaded data, it could be a good way.
About create own declarative data loader - not sure how to merge this 2 approaches that it looks good. It can be confusing when loader returns data and also put it somewhere in state automatically and calls re-render.
i am not sure if i understood why you think redux is bad for reactjs