Do we really need `isValid`? about sswr HOT 7 CLOSED

swrev dont have s state per se, we determine state based on data and error. We could improve this in the future.

As mentioned, please open issues for stuff that is related to this lib, internal discussions can be done in other private channels!

from sswr.

Isn't isValid related to this lib?

Those exists to make your life easier, you don't really need to use them, they are just computed properties that basically determine certain situation. As noted by ben, swrev don't have an explicit internal state so I can't expose it. Of course you can use both data and error to determine exactly the same, but some people prefer having some handy methods like those, and they are really one liners for me to write :D

from sswr.

Do we really need this issue?

It has no reasoning, no context, no nothing... Can't even tell what the issue is. Sorry, but I expect you to take your time to articulate your question, reasoning and/or problem if you publicly ask for help and even tag someone directly.

PS: this should simply be closed as invalid...

from sswr.

I tagged you because we were talking about state machine in PR. I'm sorry I bothered you.

I meant that maybe it doesn't make sense because to have isValid because we could evaluate the same situation in our app: using data and error.

from sswr.

My statement about state-machines is about internal handling of state inside the lib. This question is about the exposed api-surface to the outside-world. Two different topics.

As said before: Imho the lib should expose one deterministic(!) state.

if you have to write if (state === State.LOADING) { doSomething(); } or if (isLoading) { doSomething(); } every time is only syntactic sugar to make it easier for the enduser without any meaningful difference.

Btw, react-query simply exposes both (which is the right call in my opinion).

from sswr.

stuff that is related to this lib

Isn't isValid related to this lib?

from sswr.

@ConsoleTVs swrev has internal state for sure. Its state isn't just explicitly handled/named as such. That's what I was talking about in my initial comments about statemachines, deterministic state etc :)

from sswr.