Discussion: group multiple properties into one `state`

Context

Several of our components have multiple properties that contribute together to the “state” of the component and some combination don’t make sense.

Let’s take an example with <cc-env-var-form>:

• variables: null | Object
  • if nullish, we’re trying to get data from the API, the state is loading or skeleton
  • if not nullish, the state is loaded
  • if not nullish but empty array, the state is loaded-empty
• error: false | "loading" | "saving"
  • if false, the state will depend on variables
  • if "loading", an error occurred while getting data from the API, state is error-loading
  • if "saving", an error occurred while putting data to the API, state is error-saving
• saving: Boolean
  • if false, the state will depend on variables
  • if true, we’re trying to put data to the API, the state is saving

NOTES:

• readonly is not really linked and can be used independently
• restartApp is a very special state that we trigger after an update (sometimes)

This means this component as multiple implicit states that depends on the values of variables, error and saving:

• loading or skeleton
• loaded
  • This state required some data on variables
• loaded-empty
  • Do we really need this state?
  • This state required some data on variables
• error-loading
• saving
• error-saving

Discussion

After thinking about it, I propose to have just one state property that would accept the values listed above.

• This would help the smart definition code: one state + one event = new state
• This would help the UI component code as we could decide to display/hide some parts of the UI only by checking the value of state
• I don’t have examples right now but sometimes nullish is a valid result of getting data from an API.

Question A: Is this a good idea? Does it improve the situation?

Question B: We obviously still need the variables property. Does this mean we would should still rely on it being nullish or should we have explicit loading/skeleton and loaded states?

[florian-sanders-cc]

Agree with both of you on Question A and Question B 👍

I agree with @roberttran-cc, there is something disturbing about loaded-empty.

I have been trying to write about it for the past 30 minutes and it is still not clear enough for me to explain. I think Robert’s point is clear but I am still trying to figure out whether it actually matters that we are mixing two kind of states or not.

What I mean is that it bugs me to set the loaded-empty from outside the component because it feels like it is the component’s business, however I do not see any consequences ? Would it be confusing to use ? I don’t think so. Does it create a very blurry line ? Maybe, I really don’t know ?

We have other cases where data drive the component state, for instance in cc-orga-member-list, we do not display filters if there are less than 2 members. The difference with loaded-empty is very thin because we only change a criterion (members > 2 instead of 0) but these cases are so specific that nobody would think about handling them from the smart definition ?

I think it bugs me because it feels like we are mixing different subjects but it might not matter anyway and it might be more convenient this way (or maybe it matters and I still haven’t figured out why).

Small unrelated detail: Let’s not use “skeleton” as a state value because it might trigger a loader or a skeleton. We’d better avoid the confusion even if it seems dumb. To be honest, I would not be confused by it but it would bug me a little bit to have a component set in skeleton and not using a skeleton 😅 .

[roberttran-cc]

Question A: Is this a good idea? Does it improve the situation?

👌 I think so too!

I think that Finite States Machine standard benefits (clearer implementation, less error-prone) are worth the try.

But i’m not sure if i would add states expressing the data content (thinking of loaded-empty). This to distinguish:

• flow of the application (data fetch, user input) driving the states (skeleton, loaded, error, etc.);
• data driving the rest (specific cases - i can only think of empty list).

But not really sure as I’ve never use Finite State Machines… 🤷

---

Question B: We obviously still need the variables property. Does this mean we would should still rely on it being nullish or should we have explicit loading/skeleton and loaded states?

Naturally, my take would be relying on states primarily too, therefore having explicit skeleton/loading and loaded states.

Nullish data can be a fail-safe to ensure integrity (data not loaded yet) but not sure if I like it. As we have states to determine if data has been fetched or not (and therefore rendering skeleton or the list), this.variables can default to [] and should never be null.

---

🎥 A little introduction on Finite State Machines with some live-coding (no need to know Vue beforehand) with some XState in it : https://www.youtube.com/watch?v=fT9p9CCSrn8