Props, hooks, and re-rendering

[elliotcm]

Do you want to request a feature or report a bug?
Feature.

What is the current behavior?
As discussed in #14830, once a prop is passed through the useState hook, it no longer acts on updates to that prop from the parent. The user must always pair the useState call with a useEffect call to restore the normal prop behaviour.

What is the desired behavior?
This is a common enough pattern that it might be worth adding a specific hook for this situation. Is that something your team would be up for?

This is the custom hook I've been using for this purpose:

import React, { useState, useEffect } from "react";

function useDynamicProp(propFromParent) {
  const [propFromState, setProp] = useState(propFromParent);

  useEffect(() => {
    setProp(propFromParent);
  }, [propFromParent]);

  return [propFromState, setProp];
}

export { useDynamicProp };

Which versions of React?
16.12.0

[vkurchatkin]

Such a hook seems like a very bad idea. Essentially, it creates a loop in your data flow which tends to lead to all kinds of bugs. From what I've seen, there is always a better solution for cases where one might use something like this.

[bvaughn]

As discussed in #14830, once a prop is passed through the useState hook, it no longer acts on updates to that prop from the parent. The user must always pair the useState call with a useEffect call to restore the normal prop behaviour.

I suggest reading this blog post:
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html

It makes mention of getDerivedStateFromProps but the same general concerns about syncing props and state would also apply with useState. In short, I think of this as an anti-pattern, because there are a few common bugs that it causes. In our opinion, there are usually better approaches that don't require syncing.

Because of this, I don't think we would want to add such an API to core.

[elliotcm]

Alright, I'll take a look, thanks.

…

On Wed, 25 Dec 2019, 14:39 Brian Vaughn, ***@***.***> wrote: As discussed in #14830 <#14830>, once a prop is passed through the useState hook, it no longer acts on updates to that prop from the parent. The user must always pair the useState call with a useEffect call to restore the normal prop behaviour. I suggest reading this blog post: https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html It makes mention of getDerivedStateFromProps but the same general concerns about syncing props and state would also apply with useState. In short, I think of this as an anti-pattern, because there are a few common bugs <https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#common-bugs-when-using-derived-state> that it causes. In our opinion, there are usually better approaches <https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#preferred-solutions> that don't require syncing. Because of this, I don't think we would want to add such an API to core. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17712?email_source=notifications&email_token=AAA2VKJA4CKKQ66MGUTC3NTQ2NWCHA5CNFSM4J7EZT42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHUNASQ#issuecomment-568905802>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2VKKV2ZR6N6LVZQSYUVTQ2NWCHANCNFSM4J7EZT4Q> .

[elliotcm]

@vkurchatkin @bvaughn OK I've had a read of that blog post, and while I think my specific use is passable (the local state is only locally updated until a round-trip data push resets the whole component tree's state) I can sort of see where it could cause problems (the blog post talks in terms of the older API I'm less familiar with).

I've added a timestamp to my server->client data push and added it as a key at the top level, so when the data push arrives the whole tree is rebuilt rather than modified in place. That'll do me fine for now. Thanks.