React-devtools: Editing props should trigger componentWillReceiveProps

[terinjokes]

Hey react-devtools team:

I've noticed recently that modifying props in the DevTool's sidebar does not seems to respect the component lifecycle events: it instead sets the props directly and calls "render".

In particular, the lifecycle event "componentWillReceiveProps" is not called. This is officially documented:

Use this as an opportunity to react to a prop transition before render() is called by updating the state using this.setState().

This is easy to work around: I can wrap my component in another component that passes in all props, and interact with this wrapper from DevTools. Then my component will get notified of prop changes. However this breaks my concentration, and forces me to leave and go do another thing before I can continue debugging.

I'm curious why things are done the current way and if it will be possible to change DevTools to reflect the more expected outcome.

[jaredly]

The current implementation was merely the simplest way possible :) You can see here what's happening -- it's just doing "forceUpdate" after modifying the props. I don't imagine it would be difficult to add in a "componentWillReceiveProps" call there, and perhaps that would be enough.
Do you want to try that out and see how it works?

[terinjokes]

@jaredly yea, i'll give it a shot and let you know.

[deanc]

Just got caught out by this. It would be a _great_ addition to make it respect all parts of the lifecycle!

[terinjokes]

For the record, I didn't get a chance to work on this.

[sighrobot]

I will second the request for this to be fixed - I just spent over an hour trying to figure out why componentWillReceiveProps wasn't being called when I changed props in the React Dev Tool sidebar, and ended up having to use the wrapper approach described by @terinjokes. Unfortunately that approach is unwieldy for testing more complex components. You'd have to duplicate all child props as parent props or state in order to fully experiment with the child component.

Very confused why this isn't documented anywhere more obvious than within this issue, especially since the behavior of the plugin in this case deviates so substantially from one of the fundamental aspects of the library with which it interacts. Many people are going to needlessly scratch their heads on this one.

[rolandfung]

Just ran into this myself, too. Fixing this would be great and make testing some of my more complex components easier.

[gaearon]

There is no easy solution here IMO because “setting props” completely circumvents React lifecycle. I don’t think calling componentWillReceiveProps() from DevTools is appropriate here.

They will get overridden next time the parent component re-renders anyway.

Ideally we need a way to tell React to treat these edited props as source of truth and ignore props from the parent. I think this would be a cleaner solution. Kinda like you can override CSS rules in Chome inspector.

I don’t know how to approach this, really. It needs some design work both here and in React proper, and we’re right in the middle of swapping the React engine so now is probably not a good time. Solving this would require some effort and optimism. 😄

Leaving as needing contributions—even if that’s just ideas on how we could make it work.

[bvaughn]

React DevTools has been rewritten and recently launched a new version 4 UI. The source code for this rewrite was done in a separate repository and now lives in the main React repo (github.com/facebook/react).

Because version 4 was a total rewrite, and all issues in this repository are related to the old version 3 of the extension, I am closing all issues in this repository. If you can still reproduce this issue, or believe this feature request is still relevant, please open a new issue in the React repo: https://github.com/facebook/react/issues/new?labels=Component:%20Developer%20Tools