Redux and state types

[fregayeg]

Hello !

I'm new here and this is my first post. The subject I'm going to go through here, I've been thinking about for a long time ago. But first, before I get intro it, I introduce myself: I am a full stack software developer, I have been working in this field since my graduation in 2017.

I know redux since 2018, and I use it for various purposes (web and mobile apps), I appreciate redux-toolkit too and that's one of the reasons why I'm here. 😅

My goal today is to contribute with you in order to make our Redux more better, with new ideas and a strong breath. To fix problems and serve the community 😌.

The problem:

With the simplifications brought by Redux Toolkit in the integration of Redux with React projects (or others), they are still some points making developers feel confused, the most important one is the state type: How to identify state, how to describe it, how to store it..?

In redux docs we read:

Redux helps you manage "global" state - state that is needed across many parts of your application.

In another page we find also:

By now you might be wondering, "Do I always have to put all my app's state into the Redux store?"
The answer is NO. Global state that is needed across the app should go in the Redux store. State that's only needed in one place should be kept in component state.

I can understand these expressions, 😎 and can imagine - based on my experience -:

• what must be local and can only be local.
• what must be global and cannot be local.
• what can be local and can be better if its global.
• what can be global and can be better if its local.
• and many other predictions.

But some people, including those who work with me, cannot, they pass long time to think about such thing and sometime they loose control, get locked up then ask for help! 😰

I think the time has come to fix some principles in redux architecture ✊! I mean, maybe one day we can ask redux:

Hey! I need to build somthing that uses loading, async call and a dynamic rendering, what should I do?

Here, it may be useful if redux can guide the developer by saying:

What are you building exactly a navigation ? a form or a list or somthing else?

👉 This means: redux guides the developer to a safe way, and gives hem the appropriate tools. (Like we see now with createAsyncThunk(), createSlice() and rtkq's createApi(). This can even help developer to avoid long ways or doing mistakes. We can consider this as State typechecking! (Like TS type checking to variables). 🤩

In an application we can see different types of state.
Based on some Google searches, I've faced many persons see different sort of states:

• Article n°1:
  • Data
  • Communication.
  • Control.
  • Session.
  • Location.
• Article n°2.:
  • Logical.
  • Server.
  • Form.
  • Navigation.
  • Browser.
• Article n°3:
  • local
  • shared
  • remote
  • meta
  • routing

As you can see: Each one of these gives a different perspective, which can be confusing 😵. Personnaly, I feel that sometimes when doing some big tasks, and I ask a question:

Why React or Redux doesn't care about this topic so far?! The world of apps grows so fast, and we're confident that business terms are getting involved into technical stuffs and software design. There is even a close relationship between UX/UI and logic development.

Note: I've discussed recently with some redux maintainers, about this topic and they suggest me to use some specific keywords to describe state instead of just using global/local 👍.

What to do now?

I'd suggest to make an important evolution in redux-toolkit, and I'm ready to be one of the squad team. I don't want to give further details as this message seems sufficient. But I'm ready to provide more details.

Please share your feedback and impressions with me and let us improve.✌️

Thanks

[markerikson]

Hiya. Thanks for posting. I have to say I'm actually a bit confused - what are you suggesting, specifically? Some kind of code change? A documentation change?

[markerikson]

No, that's really not describing anything that I can point to specifically.

While you may think "it's clear", I'm afraid it's not clear to me.

Like I said above: it would really help if you could give specific concrete examples of what this problem is, and what you're proposing we could do to help fix that problem.

You said:

the time has come to fix some principles in redux architecture

Tbh I have no idea what this means at all :(

[fregayeg]

Yeah np; First of all, the word principle is an architecture term in software development (Follow this link if you want to learn about it), I used it but want to avoid it for now.

As for the example, consider RTKQ which provides createApi(), the function guides a developer to specific type of state, api state and let hem focus on doing business logic without caring about thunk or reducers. 🤩

My idea: Following createApi(), make some other functions to keep developer in safe frames.

For example: A developer wants to create a state for a form, the form might be login, subscription, sending specific request it can even be in steps. redux-toolkit might give hem somthing such createForm()! If he wants to create a theme configuration, redux can give hem createTheme and so on.

The objectif is to make redux implementaiton more easy, suitable, attractive and abstract. By giving some like these, a developer can feel more confident and comfortable. I hope you get it now 😅

[markerikson]

I'm afraid that's not a thing we're ever going to do:

• We're definitely not ever going to provide helpers for forms, because form state should not go into Redux
• RTK is designed to help with state management as a whole. That means we have to design APIs that are general enough that they can solve a variety of use cases, including ones that we haven't even thought of ourselves. I'd suggest reading through my post Designing the RTK Listener Middleware to get a sense of just how complicated that can be. Something like "here's an API to create logic for one very specific kind of state" is just not something we should be doing.

[fregayeg]

Thanks again for your reactivity 😀

Well, for me, the answer to your thoughts are simple:

• I agree with what you say about managing form state in redux, but maybe there is some other kind of forms! Like I said:

it can even be in steps.

Here we can imagine a dynamic UI. A user passes step n°1, fills the form then passes to another one which will be formed (UI + Data) based on form n° 1! (here we need to be predictable).

• We can avoid what is useless and focus on what is common 😉
• We can learn from RTKQ and build somthing more better, we can even learn new things and that might lead to improve RTKQ!

I know its a challenging affair, but in the other hand, I think redux community loves challenges, and FYI I'm not asking you to do what I'm talking about. I'm on it too.

[markerikson]

I appreciate that you're being enthusiastic and are interested in helping here :) But seriously, I don't see a problem here that we ought to address in RTK, and as maintainers it's also our job to say "no, these are things the library will not add". Based on the description so far, I feel like this falls into the "will not add" category, and I'd like to help you avoid spending time on something that we're not going to accept for inclusion in the library.