This community-built FAQ covers the “render” exercise from the lesson “Mounting Lifecycle Methods”.
Paths and Courses
This exercise can be found in the following Codecademy content:
Web Development
Learn ReactJS: Part II
FAQs on the exercise render
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply (
) below!
Agree with a comment or answer? Like (
) to up-vote the contribution!
Need broader help or resources? Head here.
Looking for motivation to keep learning? Join our wider discussions.
Learn more about how to use this guide.
Found a bug? Report it!
Have a question about your account or billing? Reach out to our customer support team!
None of the above? Find out where to ask other questions here!
I’m surprised to see this.intervalID declared in componentDidMount() instead of the constructor. Is this accepted practice?
2 Likes
I was wondering the same thing! How do you decide when you just create something as this.varname and when should put it in this.state?
I think, maybe it’s because it doesn’t matter what the value of the id is, as it’s internally and automatically set by the setInterval method. State is something in which value we want to control or monitor, so it would be just redundant if we want to put an interval id in the state.
Im guessing this refers to the setInterval scope?
why we use this.intervalID ? can we use only intervalID? if not , why?
I think this is because:
If you would assign the setInterval() to a regular local variable in componentDidMount() (or, as shown in the final code of this lesson, in startInterval()), you would not be able to refer to it later when you clear the interval in componentWillUnmount(), since the local variable would have a scope limited to the method within which it was declared. With this you can refer to it anywhere within the class.
PS: In this page of the React docs where a similar clock example is used, this is also being used:
Note how we save the timer ID right on this ( this.timerID ).
While this.props is set up by React itself and this.state has a special meaning, you are free to add additional fields to the class manually if you need to store something that doesn’t participate in the data flow (like a timer ID).
1 Like
I think this. inside a function refers to the root object the function belongs to, in this case the function is a method of a class so this. should be referencing the class itself. In such regards, you are essentially creating a variable at class scope level that can be used inside different methods, so that the unmount lifecycle method knows and is able to access the id variable to return the id of the interval we want to kill, that was attributed in another method the unmount method does not have access to.
I image an alternative would be to use the state object, or useRef (I read useRef is a hook used to store data that is not rendered on screen but that you want to pass around or whatever)
For instance, since reactjs runs in a browser, if we where outside a class and wanted to declare a global variable from inside the class, this. would essentially be window., it would be the same creating a var named this.variable or window.variable,
Dunno, I’m just a noob but this is what I understood, see my reply to my reply for more.
1 Like
I just tested this using the global keyword to create a global variable from inside a function.
if you declare the variable as global.intervalID, you now have access to it outside of the mount method. You don’t even have to reference the global keyword anymore to access the var.
I would imagine this would be a problem because you’re makign the variable accessible to the whole app or perhaps global is file bound?
this. seems to “hoist” the variable from inside the method scope one scope level up, which in this case would be the class level.
I guess I could test this out by creating another class (component) on the same file and see if I could use that component just to kill the interval of another component, probably global. would work for that and this. wouldn’t
1 Like
For people (like me) that are thrown off by the sudden appearance of this.intervalID, the use of this is a way to give intervalID global context.MDN docs on this
Can someone help me understand how this.intervalID actually works?:
componentDidMount() {
const oneSecond = 1000;
this.intervalID = setInterval(() => {
this.setState({ date: new Date() });
}, oneSecond);
}
intervalID doesn’t seem to be a variable, since it hasn’t been declared anywhere. Its name is irrelevant (it can be called whatever you want and it will still work. I don’t remember having seen this syntax before.
Ok, I think I understood:
this.intervalID = setInterval(() => {
this.setState({ date: new Date() });
-
this.intervalID is a property that is assigned the returned object by setInterval(), isn’t it?
- This ID object is updating itself (and
this.state) after each defined interval (1000 ms in our example).
I may be completely wrong, so I would wait for someone more experienced to validate my assumptions.
Hi,
First of all thank for creating this course, I am hooked onto it. With respect to Component life Cycle phases (componentWillUnmount) , i am very curious about how the code which triggers the component to be displayed on and off. Would you be able to share it to us?
It looks to me like “Child component updating their sibling component” programming pattern. I would love to look at the whole code that works behind the scenes
Wow, I’m happy to see everyone had question about the random this.intervalID.
I think I got the gist of it by everyone answers. Thx a lot.
