The React component lifecycle will allow you to update your components at runtime. This lesson will explore how to do that. componentWillReceiveProps
gives us an opportunity to update state by reacting to a prop transition before the render()
call is made. shouldComponentUpdate
allows us to set conditions on when we should update a component so that we are not rendering constantly. componentDidUpdate
lets us react to a component updating.
After 0.13 version, setProps() is deprecated.
How to use it by the other way?
I'm curious, either.
Wish author had explained what componentWillRecieveProps
means. I mean, I can guess & I am 90% certain I understand when it fires, but it would be nice to not have to guess :)
componentWillRecieveProps
is covered in the lesson beginning at 0:42.
{"error":"Transcript not found or finished."}
I'm a little confused at this point as to how the componentWillReceiveProps lifecycle method works in this instance.
I understand that it fires when new properties are passed to a component, but what doesn't currently make sense to me is that we only seem to have a single component in this example - App.
When App.defaultProps = { val: 0 } is expressed, it seems as though the App is giving itself properties -is that correct? Why isn't this State?
Is there an advantage to using Props instead of State? Is it because down the line most components can be expected to use Props?
TL:DR; how come the App is giving itself properties rather than manipulating internal State?
The advantage of using Props instead of State is increased composability. Meaning that a component that only responds to props is almost always a simpler and more reusable component with little or no side effects presented.
I chose to use Props as the mechanism for triggering these lifecycle methods in the lesson specifically to teach the use of componentWillReceiveProps which only responds to Props.
None of this is meant to imply that using State is wrong, just that Props made more sense in this particular example.
defaultProps is a useful property for instantiating a component that may or may not have received any props.
When update
is called, it looks like a whole new <App>
is put in the DOM to replace the old <App>
. If this is the case, does componentWillReceiveProps
compare the props
between the old and the new <App>
? Or does React keep track of of all <App>
s render()
put in the DOM and give them each a sequential number to track them between each render()
when there are more than one <App>
s?
"on 5, we get our update" should really be "on 5, we get our render()" since shouldComponentUpdate does not prevent update(), but it does prevent render()