 Are you a SharePoint framework developer that builds your components using React? Have you ever tried to use the React DevTools profiler in the Google Chrome browser? You ever run into a problem? I bet you did. Didn't work, did it? In this episode, I'm going to explain why and how you can fix it. Welcome back to the Voitanos podcast. I'm Andrew Connell. This episode is also available as a blog post on Voitanos.io and as a video on the Voitanos YouTube channel at Voitanos.tv. Check the show notes for links to these other options. A few years ago, React introduced the React profiler to React version 16.5 and it's part of or in the React DevTools plugin that's available for Chromium browsers that's both Google Chrome and Microsoft's Credge browser as well as Firefox. Now, developers can use the profiler API to collect timing information about each component that's rendered in order to identify performance bottlenecks in your React applications. I'm going to include a link in the notes on how you can learn more about the React DevTools profiler as well as a deep dive video from the React team. Now, for those of us that are creating React apps with SharePoint Framework Solutions, this is a great resource for building highly performing apps for your customers. Pretty cool, right? But if you're a SharePoint framework developer, it doesn't work. Why? Because when you try to use it, you get this error that tells you that profiling is not supported. Profiling support requires either a development or a production profiling build of React 16.5. What's going on? So this error indicates that we need React 16.5 or higher. SharePoint framework projects haven't used an older version of React since 1.7.1, right? Now, if we're using a relatively modern version of the SharePoint framework like version 1.8 or higher, it should work, but it isn't. Why? Well, actually, let me just do a quick sidebar here. Unfortunately, what this does mean is that the profiler is only available in SharePoint Framework projects built for SharePoint Online because the latest version of the SharePoint framework that's supported on-prem uses 1.4.1. So if you're one of those people, I'm sorry, but it's not going to work for you if you're working with SharePoint on-prem. This is only for SharePoint Online. So let me explain what's going on with the issue of SharePoint Framework projects. As the error indicates, for the profiler to work, it needs either a development or a production profiling build. Now, the reason you're getting this is because the profiler needs React to be present in your bundle of your project. And by default, all SharePoint Framework projects exclude React from your generated bundle because they assume, for performance reasons, it's already on the page as an external resource. Furthermore, the profiler, for the profiler is going to need a special profiling build or development build to be able to work. So what do we do? Well, let me take a second, let me explain how SPFX bundles are generated and then you're going to understand how we can fix it. So remember, SharePoint Framework uses Webpack to generate bundles used to load our SharePoint Framework components and the build tool chain dynamically creates the Webpack config when you run Guilt Bundle. The generated Webpack configuration instructs Webpack to always include or exclude the NPM packages React and React DOM from your generated bundle. Why? Well, again, the SharePoint Framework assumes it reacts already on the page. It's a safe assumption because SharePoint Online already uses React in their components. But regardless, every SharePoint Framework project that uses React is going to automatically exclude these two NPM packages. So we'll have to go through the process of excluding in ourselves and every project's externals element that we have in the config.json file. Now this means we've got two things we gotta do to enable the React DevTools profile or in the browser for our components. First thing we have to do is we have to make sure that React is in the bundle, right? We gotta make sure that React is in our JavaScript bundle in order for this to work. But I really only want this to happen when I'm testing stuff. I don't want this to happen inside of production. I'm gonna show you how to conditionally add it when you're doing your development. Now I also wanna make sure that the version of React that's included in the bundle is a profiler friendly version of the React package because that's the other thing that we need. So ideally, again, like I said, I only want this to happen in development, not production because it's got a significant impact on the size of the bundles that we ship. For example, in my little test projects without these changes, right? You're a standard out-of-the-box project is about 62K, really about 19K when it's minified into production build. But once I make this change, it's gonna balloon my bundle to over a meg. So clearly this isn't something you wanna do in production. You only wanna do this in development. But thankfully I can very easily solve both of these issues with just a couple extra lines in my project's gulpfile.js file. So the first fix is to include React in the generated bundle. So the way I'm gonna do that is I'm gonna put the two NPM packages right back into the bundle. And to do this, I gotta tell React to not exclude them from the bundle. So the way I'm gonna do it is in the gulpfile.js, I'm gonna add a couple, a little bit of extra code here. And what this code is gonna do is it's gonna take the configuration that's generated by the SharePoint framework build tool chain, the configuration for Webpack. And it's gonna check to see, am I currently in a development build? And this is true when I run gulp serve or gulp bundle without any arguments. And then we look at the collection of externals that are defined in the config and removes references to React and the React DOM. Now, when React or when Webpack runs and comes across a reference to either of these packages, it's gonna include them in the generated bundle, not exclude them by making those changes. So what changes do I make? What I do in the gulp build file, at the very end of it, I call build.configureWebpack.mergeConfig. And what that does is it passes in, I pass in an object, and that object I'm passing in, I'm gonna override a method called the additional configuration. That method gets passed in a configuration object. And I'm just gonna call that like my WP config, my Webpack config. I can make changes to that configuration and then return it back to the caller, which is Webpack. So it's like, hey, here's the config that we created. Would you like to do anything to it before we actually go use it? And so what I'm doing is I'm checking to see is the current mode of Webpack development. And if it is, I'm gonna walk through his configuration externals list and I'm going to look at everything that's in there and I'm gonna find anything that does not equal React or does not equal the React DOM and I'm gonna return it back. But I also wanna include React and the React DOM. So I'm gonna exclude React and React DOM from the list of externals and that when Webpack comes across it, Webpack's gonna say, oh, that's, we wanna make sure that we include that in the bundle where normally it's gonna exclude it. So when you look at it, it's gonna automatically include those in the bundle. Now that's the first fix that gets React into our bundle. The second thing that I have to do is I've gotta swap out the version of React that's going in the bundle with a profiler version. So the second fix is to configure Webpack to use the profiler friendly package of React when it imports into the bundle. And this is done using the Webpack's resolve configuration. This lets us configure how modules are gonna be resolved. To implement this, I'm gonna add a little bit more code to my projects.gultfile.js file. Specifically, I'm gonna modify one of the code that I just added a second ago right before the if statement that says, are we in a, or right inside the if statement that says, are we in a development build or not? And if I am in a development build, then what I wanna check, what I wanna do is I'm gonna set the Webpack configuration, resolve property, I'm gonna change, I'm gonna, he has a property called alias and I'm gonna say anywhere you find React DOM, specifically just React DOM. So don't go, if there's anything else after that don't include it. So I'm using a regular expression. So React-dom with a dollar sign, I'm gonna tell it use the package React-dom slash profiling. So instead of using React DOM, we're gonna use React DOM slash profiling. Now when I run gulp serve to load my SPFX component in the SharePoint workbench, you can now see the profiler and the dev tools and you can see that on a screenshot that I have here. If you're listening to this and you're not watching it, you can go check out the associated blog post or the YouTube video to see this. So you can see the errors now gone away. I've got the profiler installed and so now that I've loaded my web part on the page, I can see the profiler showing up at the bottom of the page for my React projects. So I showed you explain kind of what the problem was and showed you two simple fixes of how you could resolve this issue to get the React DevTools profiler working in the browser for your SharePoint framework projects that use React. Thanks for tuning into this episode and I hope you learned something. You got a question or a comment? Let me know what you think by dropping a comment or tweeting me at Andrew Connell or at Voitanos. And if you liked this episode, I really appreciate it if you would share this episode with your friends. This episode is also available as a blog post on Voitanos.io and as a video on the Voitanos YouTube channel at Voitanos.tv. I've included links in the show notes to these other resources and don't forget to subscribe in your favorite podcast app to be notified of future episodes.