Lifecycle with updates at multiple hierarchy levels

[william-vw]

This seems to be a particular lifecycle that wasn't considered when making the componentWillReceiveProps function deprecated. Or, perhaps I just cannot find a built-in way in React on how to do this properly. In either case, some guidance would be highly appreciated.

In my project, a top-level component fetches data from a service and then passes it, when received, to lower-level components as props (i.e., the higher-level component is fully controlled). These lower-level components are fields that display the retrieved data, and allow adding and removing data items afterwards. Clearly, these operations need to be reflected in the state (and also sent to the restful service, but this is inconsequential here). Hence, it would make sense to make the state the "single source of truth" since the data could be updated by the lower-level component ("field" from now on) at any point, requiring a re-render each time (?)

When first creating the field (i.e., in the constructor), this data is not yet available, since it's fetched from the service. This means that a method such as componentWillReceiveProps or getDerivedStateFromProps should be used to derive the initial state from the props (?) Since componentWillReceiveProps is deprecated I recently tried replacing it with getDerivedStateFromProps. However, this function is called "on every render, regardless of the cause" (e.g., because of a state change), instead of componentWillReceiveProps "which only fires when the parent causes a re-render" (see here). Hence, any local state change (e.g., removing a data item) will also cause the getDerivedStateFromProps function to be called (including ones caused by getDerivedStateFromProps ...).

Currently, to differentiate between state & props updates, I introduced the following function, which only derives the state from the props once, and, after any local state change, will ignore changes in props. The function is called from the field's getDerivedStateFromProps function (ignoreFunction depends on the particular field, and returns whether state and props include the same data). Note that a local state change involves setting an update field to true in the state.

static getGroundStateFromProps(props, state, ignoreFn) {
    // nothing in state or props was updated
    if (ignoreFn(state, props))
      return null

`    // some relevant update occurred; either state or props
    else {
      // in case state has been updated once, consider it "ground truth"
      if (state.updated)
        return null
      else
        return { values: props.values }
    }
  }

Would this be a suitable pattern to deal with this issue?

[gaearon]

Have you read this post? I think most of it addresses this exact issue (and explains why this approach is fragile even with componentWillReceiveProps and usually leads to bugs).

https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html

[william-vw]

Yes, I did. The post does not address this particular scenario, focusing instead on some trivial example (not to criticize - I understand why simple examples are needed). If it does, please explain how it applies to this scenario.

[gaearon]

Hmm. Your current solution with componentWillReceiveProps sounds like this simplified scenario, and the proposed alternative solution is to use fully uncontrolled component with a key. Would that not work for you? Here's a refactor where I did this: react/react#12898 (comment). Maybe if you come up with a similar simplified example I can help.

[william-vw]

Thanks for your comment. Essentially I simply try to catch the first time a non-empty prop is passed (i.e., something was retrieved from the service).

I suppose that a higher-level component could pass an artificial "null" key (some dummy value) when no data was received, and then finally props.object.id, but this would require the higher-level component to be uncontrolled (?) A second solution would be a variant of "alternative 1", which I already have..

To be honest, I don't understand how "fully uncontrolled component with a key" could be considered anything but an anti-pattern - as noted on the page it requires completely re-building the component. I also find it quite unintuitive but perhaps others see it differently. (This is a general reflection, not targeted towards you personally)

[gaearon]

It'll be hard to continue without a runnable code example e.g. a CodeSandbox demo. Even simplified. There are many subtle details depending on what behavior you want exactly, and discussing them in abstract often misses the point. Again, I'd be more than happy to look into this, but I need something tangible to work on.

[william-vw]

Please have a look here: https://codesandbox.io/s/2x7m252vrj

As mentioned I can see how a higher-level component could pass an artificial "null" key (some dummy value) when no data was received, and then finally an actual object ID when the object is available - but I don't see how that solution would be better than my current one (even worse, since it creates an entirely new component).

[william-vw]

I would appreciate your feedback, seeing how this kind of solution is actively being discouraged in the documents and on issue pages - but is nevertheless working for me, and, as far as I can tell, a better solution than the pattern being proposed.