Let’s talk about States, in context of building user interfaces be it a web application, desktop or mobile applications.
What is a state? Why do we use it, need it? How should we use it? And why/ where should we not use it?
Act 1: What
A state can be representative of your UI at any given point of time, whatever is on the screen can be considered as a state of your application. It’s like talking a snapshot of your app and keeping the information about colours, fonts, data, interactions everything.
It tells us how and what is an app right now and what could happen next depending on the choices user makes.
It holds your data coming from backend, user generated actions and interactions.
Act 2: Why
Why do need a state? Why do we use states in our app? Do we even need a state? How many types of state can be there?
All these questions are very subjective and opinionated, and here are my 2cents on it.
Need: To hold information which might change depending on certain situations like user interaction or loading new set of data. To “do something, when something happens”.
Use: To change only those parts of UI which needs to be changed when something changes or happens. That can be a click, a hover, a long press, refreshing the loading bar every 3 seconds. It could be anything. imagine reloading the whole application when a button is pressed.
Do we need: Yes and No
If your application contains some part which will be updated in future depending on the change of a variable, you might want to use a state for that.
Do not keep constants which might as well be hardcoded and will never be changed through any user interaction/ to provide an user interaction or doesn’t affect the interface into a “state” in your app.
Examples can be loading something from local storage of your device, or keeping a set of constants to map out your username’s initials with colours.
Anything that is just loaded once and never re-loaded can just be a variable.
Technically it is a state but not in the context of “state” when we use “setState” or “getState”.
Notice, how it’s a two way function, depicting your UI depends on state and your state depends on UI.
A change in state, loading a data, can change your UI and change in UI, selection of a filter, can change your state.
I only keep a piece of info in “state” if the change in it should immediately reflect in UI and I only map a piece of UI to “state” if I need to carry that piece of information to next interaction.
Act 3: How
Depending on the tech you use, you will have different options to use states in your application.
But there are two major types which needs to be differentiated
-
App wide state - This piece of info is going to be used at multiple places and, emphasis on and, can be changed from multiple places. If it’s only going to be read, you might as well be okay with reading it directly from source rather than going through the pain of setting up an app level state.
App level info like theme of your UI, user authentication info, cart info if it’s an e-commerce thing, omnibox etc
- Component/ widget level state - This piece of info is going to be used in this and maximum of two level deep component/ widget from this. You will be fine with just using a component/ widget level solution.
Component level info, like selected filters in a product section, preferred font for typing in a input box etc.
Tip: Never use your state for holding and calculating business logic or app logic, it should only contain UI logic.
And in the end, would like to quote, Dan Abramov
"Do what is less awkward"
Chatting in a github issue
Top comments (0)