In the last section we started talking about component lifecycle methods.
I told you a little bit about when each of these different methods get caught but that doesn't really
answer the question of why we might use these at all.
So in this video I want to talk about exactly why we would use the component did update and will unmount
life cycle methods.
Let's get to it.
OK.
So a couple of notes on each of these different lifecycle methods.
First off you've already seen the constructor and I think you already understand that the constructor
function is a good place to do our state initialization and that's exactly what we are doing right now
right here.
We can also do some initial data loading inside of a constructor.
So that might take the form of making a network request to some outside API or it might take the form
of doing something exactly what we're doing right here with the geolocation.
We want to attempt to get our users position the instant that we know that we are going to show this
component on the screen.
So placing the code for that inside the constructor would be one possible solution.
However there is a little caveat on that that will mention it just a second.
When we start talking about component in Mount Next up the render method.
Well I think you already understand what's going on with the render method inside the render method.
We're going to return some GSX in a general that's the only thing we do inside there.
We just tried to get some GSX returned.
We're not going to ever make a network request.
We're not going to ever startup's something like fetching the user's location or something like that
from the render method the render method alone is about returning GSX and not doing anything else.
So next up component in MT why would we use this thing.
Well the component to mount method is a perfect location to do some initial data loading for your component
or to kick off some outside process like getting the users current position if you only have to do this
thing one time in our case we only want to get our users current position one time the component did
mount method only gets invoked one time.
So these two purposes kind of line up with each other perfectly.
Now you might notice that I kind of just use the same description for the component to mount method
as I did for the constructor in both locations I said oh yeah we can use these things to do some data
loading or call our geolocation stuff right here.
So in truth we can use either a constructor or a component amount to do that data loading.
However if you read the official reac documentation and if you look at some of the community best conventions
or best practices the official docs and best practices are going to say do not do data loading inside
the constructor function.
You absolutely can.
There's no technical reason that you cannot do some initial data loading like an API request or this
geolocation stuff inside the constructor.
You absolutely 100 percent can but it is recommended that you do it inside the component did mount method
instead.
And there's a very simple reason for that if you always centralize all of your data loading stuff inside
the component.
Did mount method as opposed to spreading it out between component and mount in constructor.
It's going to lead to more clear code.
If a new engineer ever starts working on your project they can open up some new component file and understand
that all of the data loading code that is related to a single component is always going to be placed
inside of component and mount.
So although we can technically spread out data loading stuff between the constructor or the component
lifecycle method it is recommended that you put it all inside of component and mount.
So we're going to take that advice to heart.
We are going to define a component did method and we are going to move our get current position call
right here to that lifecycle method.
We'll take you to that reactor in just a moment or Right now let's finish talking about these last two.
Now the component did update method gets called every single time that a component is updated for any
reason.
Maybe our state changes or our component gets a new set of props from its parent.
So this would be a good location to also do some data loading that needs to be done every single time
that a component is updated.
A good example of that would be if we wanted to make some type of network request every single time
that a user clicks on a button or every single time that they enter some text into an input or every
single time that we get some new props from a parent component.
So if we want to make multiple data loading requests every time a component is updated start looking
at composite did update now finally component will unmount.
Now this one is a little bit more challenging to talk about because we don't have a good example of
why we would use it just yet.
But suffice it to say the component and or will unmount method is used anytime that we are about to
remove a component from the screen and we need to do some cleanup after it.
We used to use the component will on Mount method way more frequently Any time that we were using with
using react with non re-act libraries.
A good example would be if we were making use of say Google maps inside of a re-act application.
But thanks to some newer features and the re-act world it doesn't get used quite as often.
We'll we will look at some examples where we have to use component will unmount in the future.
So right now just understand that we use this lifecycle method for doing cleanup.
OK so one last thing I want to mention here.
This is technically not the entire list of life cycle methods.
There are three other lifecycle methods called should confer an update get drive state from props and
get snapshot before update.
The reason that I did not put them in the diagram right here is that these lifecycle methods are very
infrequently used.
There's only a tiny tiny subset of cases where you would ever consider implementing these lifecycle
methods.
And so as you were beginning your journey with react and you are learning it for the first time it is
far easier to just ignore these and not accidentally make use of them.
You do not want to use these lifecycle methods unless you are very sure that you have to.
And so in general best to just ignore them until you're in a scenario where you think to yourself Oh
well I cannot make this component work with just components and mount or did update or the constructor
and so on.
Once you get into that scenario that's when it is time to start researching these lifecycle methods.
We will look at these later on site of course.
But like I said right now it's best to just focus on this set right here and learn these very very well.
OK.
Now let's take a quick break here.
When we come back the next section we're going to start to refactor our app component to make use of
that component.
Did mt life lifecycle method.