 In this episode, I want to focus on a question I commonly see pop up in forums as well as with new and experienced students of my SharePoint Framework course. This is going to apply to every type of a SharePoint Framework component that developers can create. That includes web parts, all types of SharePoint Framework extensions, libraries, and adaptive cards extensions. What's the question? The question is always something variation of how do you properly initialize your component? Should you use the Objects constructor or the On a Knit method? My answer? You should always use the On a Knit method for your initialization process if you need anything in the SharePoint Framework API or the current pages context, otherwise you can safely use the constructor in your component. Why? Well, in this episode, I'm going to explain why. What's happening under the covers and I'm going to consider a real-world example. Hey, I'm Andrew Coll. This episode is also available as a blog post on boytanos.io and as a podcast on boytanos.show. Check out the description below the video for links to these other resources. All right, so let's take a look at this. Oftentimes I see developers that need to set up a component for the first-run experience. Right? So maybe your component needs to show some default view data, some default data in their view that it's going to fetch for some external data source. Maybe it's going to need to load some data based on some context like who the current user is or the time of day, but whatever it is, this is a common ask that is easily addressed that we usually are going to do this using a constructor outside of like the SharePoint Framework in traditional client-side apps. So for example, take some code that I like to use on my site, on my personal site and on the boytanos site when someone executes a search query. So it's a class, JavaScript class that in the constructor, I do a quick check to see are we currently in a test mode. So if I do, I just bail out. Otherwise I go fetch the current search term, which is sitting on the query string. I then I'm going to execute the search query by taking the search term, passing that into a method that I have that's going to then resolve its asynchronous method that's going to resolve back from running the query by submitting it as a anonymous request to a REST API. I'm going to then get the search results back. I'm going to render them out and then I'm going to display the search results. And then I'm also going to go through and in my case here, I like to go through and attach a little handler to all the different items to see which items someone clicked on. That just gives me the ability to be able to say like, Hey, what was your search term and which one of the ones that were returned was actually the one that you wanted? Like, where is it in the search results? It's a common thing you see that like Google does with their search results. Well, in this example, the constructor, it worked out perfectly, right? Is it just I don't I don't have any kind of dependency on anything other than something that's in the URL. I didn't need to authenticate to my endpoint or anything like that. So constructor works out great because I don't have any context on the page I need to deal with. But in the case of SharePoint framework, that might not necessarily be true. So let's take a step back here and let's look at what makes the SharePoint framework a little bit different. Now, when a SharePoint framework page loads that's going to use the SharePoint framework, the SharePoint framework uses a module loader to start downloading all the things that it needs for the page. Now, if you're listening to this and not watching the version of this, you're going to miss an image that I'm actually talking about that I'm referencing here is a UML sequence diagram that I'm going to show in the video. And it's also in the associated blog post. You just you may want to go back. You may want to take a look at this with this image. So that process when all when the SharePoint framework is downloading all these components, I have that listed here in this in my UML sequence diagram as number one. So you can see that the load process has started. It hasn't fully finished yet. But what that load process is doing is going through is loading all those components. So it's downloading stuff that like core SharePoint framework stuff. And then it's also going to and downloading like my web parts bundle, but then all the stuff that my web parts bundle said that it needs to download. Like if I was using jQuery, if I was using moment for my date time formatting or something like that and pulling it from a CDN, it's going to download all of that stuff is downloading downloading it all at that all the time. I tell it to go through and start pulling things down. So as it's downloading all of my stuff as it's loading the components, once it downloads a component and it's actually got everything it needs for it, the SharePoint framework as indicated in my image here, my sequence diagram and on number two, it's going to create an instance of that object and add it to the page. Well, if you think about it, if you're doing this, when you when you when you build your project or you build your component, if you're using the constructor, that's when the constructor is going to run. It's going to run in step two of the entire creation or when it's being added to the page. Was that a problem? It is if you're depending on something from the SharePoint framework. And here's why. In the loading phase of the SharePoint framework that I've got indicated here, it doesn't stop until number three on my sequence diagram. What that's doing is that's going through and it's making sure it's getting everything that it needs. But it's not initializing and hydrating all the objects that it's going to need, like it's not setting up a page context. It's not setting up like to go through and to figure out like how to call the SharePoint REST API or how to call Microsoft Graph. There's a lot of initialization. It doesn't know other context things. It doesn't know if it's running local host or something like that. So there's all of that stuff happens during the SharePoint framework run times initialization phase. And you can see that by number four on the diagram that I have listed here. So in that phase, what that initialization is going to do is it's going to start an initialization phase. And once it's downloaded everything, so the loading phase is done, the initialization phase is what's going to then going to start initializing the SharePoint framework, but only the SharePoint framework. Once the SharePoint framework has completely finished his initialization phase is then going to go to each of the components and going to go initialize all of those different components. Now, it does that by calling the on a knit method that's on the base component. Now, if you don't have an on a knit method in your project or in your component, that's fine. You still are inheriting one. And that's why and you're so you're still you still have that method. So the SharePoint framework is going to be able to call it. That's why when you do an on a knit, you should call super dot on a knit to make sure that you still get all the core initialization stuff that happens with a component. That's step five when it's going through this whole initialization of your component. That's step five. That's when you want to go through and do stuff in your components initialization that may have a dependency or that does have a dependency on something in the SharePoint framework. So, for instance, maybe you want to check and use the SharePoint framework API to figure out using the page context to get the current theme that's being used or get information about the currently logged in user. That's stuff that you won't have access to once the once your component gets added to the page or you may make it lucky and it may be done by the time you do it, but you just don't know, right? Your stuff, your code that's going to depend on the SharePoint framework shouldn't start until as I show you here on the on the this image. It shouldn't start until number five. That's really when you should wait for that stuff to happen. So that's a good time when you go get data from like a SharePoint list, get some information about the current user, etc. Then once that on a knit method completes, once it resolves, you're going to it's an asynchronous method that has a prompt that returns a promise and that promise has no return type. It's got a void return type. So all you have to do is just call promise.resolve and that effectively tells the SharePoint framework this components ready. It's ready to go. It's ready to be to show something on the page. And it's not until that happens that SharePoint framework then calls the render method. So if you didn't implement the on a knit method, it's going to cut your constructor is going to run when it gets added to the page in step two. And then when if you access the SharePoint API in step two, it may or may not have already been in the SharePoint framework, may or may not have already initialized itself. So you may or may not have access to certain things and always you may get some undefined error. Once that but let's just say it worked. Well, like you everything, you had a race condition, you but you actually got through it. Your stuff finished after the SharePoint framework initialized. Then the SharePoint framework is going to call on a knit. You say, I don't use one. It's like, that's OK. The base class does so it's you still have one. And then it's going to call the render method. So let's look at an example of this, right? Let's say, for example, that I want to get some data from the SharePoint API. Now, I'm use, you know, in the in the example I had the beginning about using the search on my site, I didn't have to worry about calling some REST API because I was calling, I was using the browser's fetch API. And that's always available to me. Well, unless I'm using Internet Explorer 11 and then I have a whole bunch of other problems I haven't had to deal with anyway. But there's a polyfill to deal with a fetch API that's missing. Just don't use IE 11. So in this case here, let's say I need to get some data from a SharePoint list. Well, I'm going to do that by calling this.context.sphtpclient.get and then pass in the URL of the REST endpoint that I want to query along with the configuration. So let's look at a bad case, right? So the first code sample that I've got here is my search results web part. So that let's say I'm going to use the SharePoint the search engine that's available to us in SharePoint. So Microsoft search, SharePoint search, whatever you're using. So in this case here, I'm going to create the endpoint. I'm going to use the constructor way of doing this. This may or may not work. This is the part where I may fall into a race condition. I have no idea if this is going to work. And even worse, it may work on my machine in development, but it won't work in production because on your local machine, everything's always faster, right? So, and even worse, what if you're in production and you get these inconsistent error reports from your users? Some people it's fine, some people it isn't. I don't drive you nuts. So the safest way to do this is not with the constructor because if I go get my search results, there's a chance that the context object has not been initialized yet. And so it doesn't even know how to call SharePoint just yet. It's part of the API, but remember, the SP HTTP client object does all that extra stuff about adding in all the authentication stuff that we need out of the box to be able to call the SharePoint REST API. That's coming from the configuration. So it's going, looking on the current page, it's getting cookie, it's getting the request digest, all that stuff. The right way of doing this though, the safe way is not to shove this stuff in your constructor, you instead should be shoving this stuff in your on init method. And then once you've actually gotten your search results, you then call promise.resolve, what that will do is that will tell the SharePoint framework, I'm done, now you can go about rendering out the web part, all right? So just to summarize, you've got two ways of initializing your component in the SharePoint framework. You've got the non-SharePoint framework way of doing it, which is using a classic class constructor, or you can do it using the on init method that we get in the SharePoint API. For the most part, I would say to be safe, I would do everything in the on init. But if you wanna try and separate things out, the only time you can use the class constructor method is when you are doing something that has nothing to do with the SharePoint framework. Like maybe you're gonna do a calculation based on the time of day, or you're gonna do something that's based on the URL that you're currently on. Those things are gonna be accessible to have nothing to do with the SharePoint framework, those things are available to you all the time. But if you're doing anything that you are gonna use the SharePoint Rest API, you should do that stuff in the on init method. That's it, I hope you learned something here and make sure you don't use your initial, put your initialization stuff in the wrong place and run into those race conditions. Thanks for tuning in, I hope you learned something. You got a question or a comment? Let me know what you think by dropping a comment in the video below, or tweeting me at Andrew Connell or at Voitanos. And if you liked this episode, man, I'd really appreciate it if you'd share it with the rest of your friends. This episode, as I said earlier, is also available as a blog post on Voitanos.io and on the Voitanos podcast at Voitanos.show. I've included links in the description below to these other resources. And hey, don't forget to subscribe to this channel and click that little bell in the corner to be notified of future episodes.