Issues with componentWillUpdate deprecations (state machines implementation)

[rosenfeld]

Hi, I'd like to discuss an use case for which I think the new lifecycle methods won't help demonstrating how it seems to me like a bad move to deprecate componentWillUpdate (or prefix it with UNSAFE_).

I have some sort of client-side router that uses the history API to change the query search to implement some sort of state-machine for a given component. Think of some UsersManagement component that could render actions such as list, edit and display actions. It has an "action" state and render() will dispatch to the proper method depending on what is the current action.

When there's an action change, some initialization is required and I'd like to reset some other relevant states. Currently, the only way I can think of implementing that is to store the previous "action" state in some instance property and compare the current action with the previous one in render(). When they are different I'd perform the changes to the other state attributes in-place since it's already too late to call setState() from render().

Even componentWillUpdate() is not ideal for that since I can't call setState from it either, but at least I wouldn't have to store the previous "action" state myself. With componentWillUpdate() I'd be able to compare the previous action state with the next one and modify the relevant state changes in-place before render is called, which seems like a bit cleaner approach.

I feel that something is missing in React and that it should be possible to react to state changes and perform further state changes before rendering without much hack. State machines should be possible even without something like Redux. Am I missing something obvious while trying to implement a state machine?

[gaearon]

Can you provide the minimal code demonstrating what you’re doing please?

[bvaughn]

Just in case it's unclear, mutating state- either this.state or prevState/nextState- was never supported. state should be treated as if it were immutable. (This is even more important with async rendering, because of how React rebases lower-pri state updates.)

[gaearon]

To me it sounds like you want to have a single entry point for state changes. There, use the setState functional form to get access to previous state.

performAction(action) {
  this.setState(prevState => {
    let nextState = { action };
    if (prevState.action !== action) {
      nextState.someField = null;
    }
    return nextState;
  });
}

It’s hard to say more without seeing your code. But if you need to adjust state based on state then you should do it when you set that state, not later.

[rosenfeld]

@gaearon I'm not currently at home and will only be back late in the night most probably, but I'll try to show some code example tomorrow.

Your example above makes sense. I guess I should be able to replace this.setState({ action: 'list' }) with something like performAction('list'). Once I'm back to home I'll try that approach in the actual code and if it's not that simple I'll let you know. I'll close that issue for now and if I think it's not that simple I'll add more details to the issue and reopen it.

@bvaughn I'm aware of that, but most of the render call rely on some state variables in order to render. Modifying the states in-place during render is way more simple than extracting some variables to something like "const someValue = isNewAction ? 'something' : this.state.somethingElse". It's much simpler to write something like:

if (hasActionChangedToList) {
  this.state.clients = [];
  this.state.somethingElse = ...
}

[bvaughn]

Right, right. I see how it could be more convenient to write that way, but I wanted to point out that there were subtle problems with mutation like that in the past (even without regard to async) which is one of the reasons why the will lifecycles have been deprecated and tagged as "unsafe". 😄

[gaearon]

You can also use something like https://github.com/mweststrate/immer if you want to write code in mutable style inside a pure updater function.

[gaearon]

That said you can already write code in a “mutating style” for top-level state keys in the updater function, like I show in #781 (comment). You’d need to be careful to not mutate the previous state with deeper updates though.

[rosenfeld]

Thanks for pointing out to immer. Seems like an interesting library even though I don't intend to use it right now. I actually liked the suggested approach in comment 781 and will try that once I'm back to home. Thanks. With that approach I wouldn't have to modify the previous state if I only care about mutating top-level state keys. For modifying inner states then I can always consider immer if I feel that modifying in-place could lead to unexpected behavior in my code. If I can easily save those 2k then I prefer to modify in-place, but if I suspect that could introduce subtle bugs, then I'd replace those in-line state changes with something like immer. Thanks for all your help and considerations :)

[thysultan]

@rosenfeld Was there any reason you used componentWillUpdate instead of componentWillReceiveProps since unlike the former, setState in the later updates/mergers the state update in-place* within the same render cycle(before render is called).

[gaearon]

cWRP wouldn’t fire on state-only changes.

[thysultan]

Was there any reason why setState in componentWillUpdate did not follow the same semantics as setState in componentWillReceiveProps.

[gaearon]

Probably that it was unnecessary to support setState in it? If you need to change state in response to changing state, it means that either one of those states is unnecessary (and can be eliminated), or that those states should have been computed together.

[rosenfeld]

@rosenfeld Was there any reason you used componentWillUpdate instead of componentWillReceiveProps since unlike the former, setState in the later updates/mergers the state update in-place* within the same render cycle(before render is called).

Just to be clear, I never actually implemented it using componentWillUpdate. I've thought about using that but since I never remember the actual names of the hook methods I always look at the documentation and this time I noticed the changes in the API, so I used the method I described in this issue, by storing the previous action and comparing against the current one in render(). But I thought that maybe it would be clearer if I used componentWillUpdate instead, without realizing setState is not supposed to be used in that hook either. As you can see, I'm still kinda new to React application development and I'm really giving it a try in the development of a new app I started to build since a few months ago.

But after thinking better about this I think Dan is right in pointing that the state reset should really happen once the action state is changed, which seems a bit obvious after this issue's discussion. It wasn't obvious to me while developing the application because I don't actually run this.setState({action: 'list'}) directly. I'd run something like this.navigateTo({action: 'list'}) instead, but it calls setState behind the scenes, so I should be able to abstract performAction anyway and use navigateTo in the implementation.

That should be enough, but if there's a catch I can't easily fix without those lifecycle hooks I'll get back to you.