Joanna Otmianowska

Posted on Apr 26, 2021 • Updated on Apr 28, 2021

Status instead of isLoading boolean?

#react #javascript #webdev

When I saw the article 'Stop using isLoading boolean' written by Kent C. Dodds my first thought was - what's wrong with isLoading boolean? Why shouldn't I use it? Then I read it. And saw his point.

It is a common practice to use isLoading boolean to show some placeholder or spinner when data in our app is loading. This is fine - you set isLoading to false, change it to true when data is loading and when data is here - put it back to false. But what happens when error occurs? Data is not loading but there is no data to show either. We start to add more conditions - first not loading and no error, then for not loading but with error, another one for loading. Do you see the point?

What Kent suggests in his approach is having status with different enum values for every case e.g. 'idle', 'resolved', 'rejected'. In the code then we can go like (examples based on the article that I mentioned earlier):

if (status === 'idle') {
    return <div>Data is loading...</div>
}

if (status === 'resolved') {
    return <div>{Fetched data}</div>
}

if (status === 'rejected') {
    return <div>Something went wrong!</div>
}

Thanks to that we can set status for particular case after every activity and there is no need for double conditions (like is not loading and there is no errors etc).

To get rid of equal signs we can put status info in variables.

const isLoading = status === 'idle';

if (isLoading) {
    return <div>Data is loading...</div>
}

And that's it! I recommend reading Kent's article for deeper explanation and more examples.

Oldest comments (43)

Mathieu Huot • Apr 26 '21

Very interesting, I'll definitely use that pattern! Thanks for sharing! 👍

myleftshoe • Apr 26 '21

Nice tip. And if needed you could implement a state machine.

Joanna Otmianowska • Apr 27 '21 • Edited

Thanks! Yes, that's true. But state machine would be work for better more complex status management

Pragmatic Maciej • Apr 27 '21

Everything is a state machine, even isLoading state with setState represents such with two possible states. The problem starts when the model needs more than two states, then bool starts to be a problem. I have few articles about this subject, take this - dev.to/macsikora/boolean-the-good-.... 😉

Joanna Otmianowska • Apr 27 '21

thanks! I will check out your articles

myleftshoe • Apr 27 '21

Agreed, a state machine in this case would be overkill. Compare time and mental load to

write out some if statements (virtually no mental load) vs
think about representing the logic as a state machine, draw a state diagram, etc

Not only that but the code would be harder for others to grok than if statements and would make them wonder why it was implemented as a state machine - "I must be missing something"

And if you were a contractor, paid by the hour, using a state machine in this case would look like that you were milking your hours and using your time to experiment or hone your skills

Fateh Mohamed 🐢 • Apr 26 '21

You can create an Enum type for those status

Joanna Otmianowska • Apr 27 '21

Good tip! Thanks :)

Aleksandr Hovhannisyan • Apr 26 '21

I actually ran into this situation at work recently and a colleague suggested using an enum instead of separate loader/status booleans. It definitely made things cleaner and the logic easier to follow!

Joanna Otmianowska • Apr 27 '21 • Edited

Yes, when you first hear about it is sounds strange but then you realise it really makes sense.

Deepanjan Ghosh • Apr 27 '21

Enum also helps in expanding the feature more in the future if the need arise. Make things more cleaner and easier to read!!

Aadarsha Acharya 🚀 • Jul 4 '21

Hi, how would you implement enum over here?
I'm definining my state types as :

export interface AuthState {
  status: 'idle' | 'pending' | 'resolved' | 'rejected';
  isAuthenticated: boolean;
  error: string;
  user: User;
}

and giving me type safety. Are you talking about making StatusEnum?

amiceli • Apr 27 '21

I use same pattern, but I use "busy" instead of "idle" and "idle" is use when promise/fetch or another isn't launched yet.

Shubham_Baghel • Apr 27 '21

The best way of clean code and well structured

Rohith V • Apr 27 '21

Thats great, thanks for sharing

Kasper Mróz • Apr 27 '21

Good idea! TypeScript’s Enums could also do the job here 🔥

Matheus Murden • Apr 27 '21 • Edited

You could also wrap fetch logic in a hook that returns { data, loading, error }.
And then:

loading && <Loading />
error && <Error />
data && <Data />

Joanna Otmianowska • Apr 27 '21

Nice one!

Lars Ejaas • Apr 28 '21

Yeah! That is also my approach!

I have this habit of writing

!!loading &&<Loading />

It is probably over-cautious, but checking for null and undefined is nice - these errors can be really hard to debug otherwise.

Patrick Charles-Lundaahl • Apr 29 '21

What's the purpose of the !! here? The && will cast the left-hand operation to a boolean already. Won't null and undefined already be converted to false for the purpose of the guard clause?

Lars Ejaas • Apr 29 '21

I think you are actually right!! 😮 I always thought this was only a check for null.

Patrick Charles-Lundaahl • Apr 29 '21

Ah okay! I wasn't sure if I'd missed something or not. I use guard clauses pretty extensively in my React code, but I also use quite a few languages across a bunch of projects. Wasn't sure if I'd gotten mixed up 😅

Derk-Jan Karrenbeld • Apr 30 '21

You did miss something.

The && will cast the left-hand operation to a boolean already.

This is not true when it short-circuits. That is, when the left hand side is falsy.

Won't null and undefined already be converted to false for the purpose of the guard clause?

No, they won't

loading = undefined

loading && true
//=> undefined

loading = null

loading && true
//=> null

In the end, undefined will cause errors, null won't. false depends on the renderer.

Side note! If you want to be explicit, using Boolean(loading) is probably more readable than double negation (!!loading).

The best way is to not rely on && (or ||) to return the right result, but use a ternary:

loading ? ... : null

Why? Now you don't need to think about all falsy values and the rendering never breaks :D

Lars Ejaas • May 8 '21

Nice writeup! I actually use the ternary a lot, but I do not find it useful for all purposes. I am a bit unsure!? So you are actually saying that the "!!" prefix would be needed here to "catch" all falsey values?

Derk-Jan Karrenbeld • May 9 '21

!!value is effectively the same as Boolean(value) and will therefore always return false in the case of all falsy values.

!!value && <MyComponent />

Will always resolve to false if the left hand side is falsy. False values are not rendered, so yes, that would catch all falsey values.

I still recommend Boolean(value) && <MyComponent /> over !!value && <MyComponent /> because it is both explicit and easier to read, albeit it a bit longer. It's easy to skip over !!, but more importantly, it's easy to forget to add !!. If you're used to seeing Boolean(...), that's less likely.

Lars Ejaas • May 9 '21

That's actually a great point! I haven't used Boolean(..) in my code I think 🤔 But I like how it's more descriptive! Thanks for taking the time to responde 😊👍

Derk-Jan Karrenbeld • May 9 '21

The _callable Global Objects are a gem ✨.

I also recommend Number(value) over the obscure +value, which both are usually better to "type-cast" than parseInt or parseFloat, as it will properly fail when the value isn't representing a number, instead of doing something unexpected.

Lars Ejaas • May 10 '21

Ahh, cool. I haven't digged super deeply into the differences, I just really like "Number" because "it does what it says on the tin" 😆 I really like easy readable code 😊

Frozen_byte • Apr 29 '21

this is my everyday use. No status required.

Dan Greene • Apr 29 '21

I like that React-query allows for that approach and it works excellently in JS and in TS.

Lucas Perez • Apr 27 '21

This seems very nice!
Particularly, I like switch case. I think it works nicely when we have many ifs in a row comparing to a single value.
Of course there are many other great suggestions in the comments!

Aryan Gomes • Apr 27 '21

Thanks for the tip and for sharing!

Jacob Samuel G. • Apr 27 '21 • Edited

In Typescript I always use enums for that :)

Lars Ejaas • Apr 28 '21

It might be great for some situations but more verbose for others...

Let me explain.

Normally (in React, but I guess it would be almost the same elsewhere) I would import the fetch logic like this:

const [isLoading, Data, isError, Error] = GetData(URL)

Then in the JSX:

{!!isLoading ?
(<div>Data is Loading</div>)
:
(!!isError?
(<div>Something went wrong</div>)
:
(<div>Data</div>)
)}

My point is that the booleans make it possible to use really short syntax.

I definitely see your point when status could have a lot of different states, but if you have a lot of different skeleton loaders and stuff I think booleans are hard to beat.

why not return the different states like booleans?

something along the lines:

const [iddle, resolved, rejected] = GetData(URL)

Sunny Golovine • Apr 28 '21

This article makes me feel very (type) unsafe. But seriously, I would not recommend this route unless

You use Typescript
Store each status as an enum.

The big issue I have is the inevatable instance where you spell 'loadng' instead of 'loading' and your logic breaks. This can be avoided using union types in typescript of creating an enum with regular JS.