I disagree with this article. I dont think you should be using a loading state at all. If the data is null, you are loading. If an error is present, the loading failed. Using a state with an enum adds complexity because now the same information is relayed through 3 different sources; the error state containing the error message/response, the value or resource state that contains the actual data on success, and your handcrafted enum/boolean. You could make a case for computing the enum on the fly for the sake of easy switches but imho having an if return the errormessage component whenever the error state is not null and returning a loading component when the data state is null (in that order) presents far cleaner and maintainable components. This also discurrages people nesting things too heavily since a lot of developers would probably use a switch with this enum ...
I look forward to hearing peoples responses!
I'm a software engineer with a lot of React and startup experience. I write about my opinions on React, using Firebase with React, and lessons from building my 1st startup, Retro.
Hey !! I am a Enthusiast Web developer on my way to explore all inches of web and connect with people. Dont hesitate to reach out to me.
Linkedin: https://in.linkedin.com/in/rautrohit
I'm a software engineer with a lot of React and startup experience. I write about my opinions on React, using Firebase with React, and lessons from building my 1st startup, Retro.
This is also an interesting take! So you're saying instead of storing a separate enum string value, just derive the status based on whether or not data or error are not null?
The one case I could argue against this for is re-fetching. Say you have a list of data, and you'd like to re-fetch or fetch more...your original data wouldn't be null...therefore how could you indicate to the user that you were re-fetching / fetching more?
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.
I disagree with this article. I dont think you should be using a loading state at all. If the data is null, you are loading. If an error is present, the loading failed. Using a state with an enum adds complexity because now the same information is relayed through 3 different sources; the error state containing the error message/response, the value or resource state that contains the actual data on success, and your handcrafted enum/boolean. You could make a case for computing the enum on the fly for the sake of easy switches but imho having an if return the errormessage component whenever the error state is not null and returning a loading component when the data state is null (in that order) presents far cleaner and maintainable components. This also discurrages people nesting things too heavily since a lot of developers would probably use a switch with this enum ...
I look forward to hearing peoples responses!
I think the basic idea is good, but the implementation is lacking.
An tagged union that holds the error/value would be remove quite some moving parts.
Nice, you're the second person to mention tagged unions to me. Looks like I need to do some learning! Thanks for the feedback! 👍
Useful thing which i have learnt for the day !! Great post
This is also an interesting take! So you're saying instead of storing a separate enum string value, just derive the status based on whether or not
dataorerrorare notnull?The one case I could argue against this for is re-fetching. Say you have a list of data, and you'd like to re-fetch or fetch more...your original
datawouldn't be null...therefore how could you indicate to the user that you were re-fetching / fetching more?