On: A better way to represent loading state in ReactJS...

[mpodlasin]

This is actually pretty bad. In redux dev tools you will not see if data is being fetched or failure occured. Also, if you serialize and deserialize state object - say save it in local storage - empty array will be neither fetching nor failure one and strange bugs will occur.

[andreareina → mpodlasin]

I'm only passingly familiar with redux (read the tutorial + parts of the docs a few times, never actually used it), where is the problem? As I understand it the status of the request is encoded in the store's state. The (de)serialization can be handled as part of the fetch:

    const fetchPics = () => dispatch => {
      dispatch({ type: PICS_REQUEST });
      const cached = deserialize(localStorage.get('pics'));
      if (cached && cached.length > 0) return dispatch({ type: PICS_SUCCESS, ...});

      return api.get('/pics')
        ...
    }

[alangpierce → andreareina]

The problem is if you try to serialize and deserialize the entire state tree itself, including the loading/failed state. LOADING_STATE, FAILURE_STATE, and an empty array all convert to the same JSON, so if you take your entire state tree, save to JSON somewhere, then load it back, you won't get what you want.

The ability to take your whole application state, save it somewhere (e.g. localstorage), then load it back later is one of the cool things enabled by redux, and it also makes it easier to implement things like time-travel debugging.

[andreareina → alangpierce]

I can see that. Thanks!

[Zalastax → mpodlasin]

Good point! I'm confused by the articles suggestion as it already talks about Flow which has support for string literal types. I.e. undefined | "loading" | "failed" | ActualData

[coldtea → Zalastax]

Just because it has a union type, it doesn't mean it's optimal to use it.