can't "reload" a component using a variable if its in use as a state

[yazaddaruvala]

Check out this fiddle, http://jsfiddle.net/JUbe3/1/
Line 70 is the real puzzler
It suggests that when you "select" a message, that the Content's color should go red.

• I can change the color just fine when I hit "change color" (which is state controlled)
• I can't do it when I "select a message" (which is porp controlled and in my assumption should reload the entire component with new properties)

I've tried removing any mention of this.state.color and only using this.props.color and things work as expected. I can change color when I select a message, however, obviously I cannot toggle the color using the link.

I did also try setting the Content's state from the select function but that just resulted in errors.

Maybe someone with a bit more experience knows a work around (which I would like to hear about) but I feel like this is intuitive and so should just work and thats why I've filed it as an issue.

[zpao]

React will re-use the component that was there since it's the same type and at the same position in the tree. This is intentional for many reasons (speed, memory, etc) but since you assumed the opposite, I understand where the confusion is coming from. Since the component is being reused, getInitialState won't be called again, so you won't be re-setting this.state.color like you do during component initialization. React does provide a hook here for you though - componentWillReceiveProps(docs).

Now that said, I think you'll want to carefully consider the implications - you're controlling your component from multiple places now which can get messy and make things a bit harder to reuse. I don't know the full scope of what your application is doing so maybe it'll work out great for you. I noticed though that you take an alternative approach for selection, passing a callback and leaving it entirely up the to prop (you set an initial state in Message but don't use it).

[yazaddaruvala]

Interesting. I agree the issue should remain closed, componentWillRecieveProps works. Thanks. However, I do have a few thoughts and questions.

Its interesting that React's notion of a component's identity is based entirely off name and position. I would have imaged and would like to argue that a components assigned properties are as much a part of its identity as its name or position. Are there current technical limitations or fundamental ideologies of React that make this so?

[zpao]

A lot of the quirks of React come from our desire for speed. In this case, if we threw the child away just because a property changed, we would also need to remove the DOM node, then create a new one that was virtually identical except for one attribute. All of that is expensive and slow. Part of React's philosophy is that data should be able to flow through your application so if you have top level data changing frequently (maybe a backbone model or something) then you really want to minimize the set of things that change down the line from there.

Hopefully that helps a bit. If you have more questions about it, this is a great question for the newsgroups and could probably be made into an interesting blog post.

[petehunt]

I'd like to add that I used to have the same concern as you, however if the props themselves constituted the "identity" of a component then we'd always throw a component away whenever data changes. Not only is this slow, it also will destroy e.g. form inputs / selection position.

In many cases reading from this.props in getInitialState() is an antipattern. If you're computing a value from this.props in getInitialState() when this.props changes the state value will be out of date. Additionally this means that the state you're storing on this.state is not actually the minimal representation of the component's state.

Instead you should try to avoid reading from this.props in getInitialState() and instead compute the value inside of render() based on this.props and this.state. That will usually do what you want.

In your particular use case notice that the minimal set of state needed is selected in MessageList. Your Content component should instead take a callback that "asks" the MessageList to change its selected state. Does that make sense?

@chenglou is going to document this.

[petehunt]

One other thing: you can override the identity by setting a "key" prop on the component.

[yazaddaruvala]

Thanks for the additional info, all of that is very good to know. I do get exactly what you mean about using a callback to "tell" Content it needs to expand. Being new to React its hard to know what the best practices are. I thought given the idea of immutability that "telling" a component to change would be wrong. But given "refs" I guess its not. I prefer the idea of setting a "key" prop. It seems more declarative than using the componentWillRecieveProps hook.

Another thing that I assumed, which I guess I assumed wrong was that the "diff process" between the currentMockDOM and the nextMockDOM. I thought it was more intelligent (but now I get why its not). That since I was just changing a style in my Content React wouldn't throw away the whole node and would just change its style after calculating the minimal changes required. From what you both said above, about "throwing away" components if a prop changes it seems that assumption is wrong. However, I seem to remember a video about React saying something similar to "we only apply the minimal set of DOM changes required". However, it now occurs to me that perhaps that process is only used when React interacts with the real DOM not when transitioning from the currentMockDOM to the nextMockDOM. Unless I missed a lot of the docs this may also need some clarification.

It would be cool to read a blog post about how the DOM, MockDOM and nextMockDOM (I don't even know if this is a real concept) interact. What is stored in each, and when.

• Basic example: Updating through internal state. I think I understand this well but a more indepth understanding would be beneficial.
• Complicated example: A rendered and re-rendered list of components. When a list/app's state changes say perhaps to select one component and mark it as highlighted: Are all the components re-rendered? If not, what is the criteria for re-rendering? And regardless, if those components render to a identical MockDOM as before but one class has been added, how does that affect the real DOM, ie what are the minimal set of DOM changes that will be applied?

Actually having written all of that, I realize that I'd be able to answer a lot of my questions if React would console.log the minimal set of DOM commands that are being applied. Do you guys have a flag I can use, that you use during development/debugging?

[petehunt]

If you just tweak a style attribute, we'll only mutate the style attribute. We use keys and component class as a heuristic to indicate that we want to blow away a whole subtree and replace it with innerHTML which is faster than dirty checking the rendered markup and doing many individual DOM mutations. This heuristic is actually quite effective in our experience.

@vjeux is working on a blog post about this.

Telling a component to change is indeed not great practice, especially with refs. However, in React data only flows down the tree automatically. In order to flow data back up, you pass a callback to inform the top of the tree that there was a data change (we now have some sugar called ReactLink to make this a bit more streamlined). The reason that we do this explicitly is because data fundamentally flows one way in von neumann machines and if you don't make the data flow explicit we've found it becomes very hard to maintain.

[korywka]

@petehunt , @zpao

So what is the right way to update already rendered component?

I also use getInitialState with this.props.

Using different key? componentWillReceiveProps? If you already have noted somewhere about this - drop here link pls.

My current init function is here: https://github.com/bravedick/react-datepicker/blob/master/datepicker.js and i feel it is wrong cause i can't SET date to datepicker after it is rendered.

[korywka]

Instead you should try to avoid reading from this.props in getInitialState() and instead compute the value inside of render() based on this.props and this.state. That will usually do what you want.

This is not always impossible. What if you need to set some default init state, but some params may be passed to component? For example, date_from and date_to in datepicker.

[zpao]

componentWillReceiveProps allows you to hook into an update with new props. You can use those to setState.