We have to stay up to date when it comes to modern customization approaches. Practices that were not as relevant in the past are now at the forefront of most modern code-building practices. SharePoint Framework (SPFx) offers best practices in a modern approach to customizing Microsoft collaboration platforms. However, there are challenges to overcome with this modern approach. I hope you find part two of SPFx challenges useful.
Other blogs in this series:
It’s so easy and convenient to tap into NPM and have access to over 1 million packages. Type a command, pull something in, and it works.
Typically, we don’t pay enough attention to what we pull in, and that’s a problem. If we go back to the example I mentioned in part 1, the weather widget, it will often have dependencies within itself. Consequently, we do not pull a single dependency but a dependency tree. Therefore, we pull dependencies with other dependencies, and those other dependencies have dependencies too. The tree grows and grows.
A web part might only be a few megabytes, but if you don’t pay attention to the code you pull in, your web part might become bloated, slowing down the whole page. Every single time a user comes to your page, they pull in all of that code, and it needs to be parsed and run. Thus, slowing down the rendering because your page will be empty for a long time.
There are ways to help understand what things your packages pull in – their dependencies, but you must be aware of them. Observing the size of your application compared to its function is crucial. If your application is showing three megabytes to show the weather, you might find this excessive, but for a complete application that allows you to manage projects, customers, etc., three megabytes might be correct. Still, there is a question if you need to load all that upfront, or if there is a way to split your application in chunks and load the other pieces on demand when the user needs them. Keep in mind that you could be pulling in more code than you need.
Manipulating DOM was a big trend in the past to help customize the UI as one saw fit. For a long time, Microsoft even recommended it. However, this is no longer the case, especially when operating in the cloud.
In the past, Microsoft would release a new SharePoint version every three years. IT would control the complete roll-out from testing to implementation. With Office 365, we receive an update every week, and it might only be something small, but it could also be something big. If you don’t pay attention, the update could break your application.
One thing Microsoft recommends now is to stay away from DOM. You get your own element when building a web part, and within that element, you can do whatever you like. Whenever you adjust something outside your element, the adjustment could be gone within a week, and the application can break.
Page DOM is not an API. There is no SLA on it. The moment you start doing things, you will be on your own with no support. Whenever there is an issue, Microsoft might ask you to revert what you did to get to the supportable state and examine the issue, assuming it’s still there.
Don’t manipulate DOM, because you do not want to be in a position where you need to check every day, does your application still work. You need to break those habits from the past.
My final point is the location of where you host web parts, which will interest admins. If you build an SPFx package, you can embed the code inside the package, but you can also point to a URL which has your code located.
Developers who build the application decide whether the code is included inside the package or not. If not, then where are the URLS located – that’s the challenging part.
I have heard from customers on many occasions, who were about to put something into production, realizing the package was pointing to an unknown URL. The manifest pointed to a blob account owned by a developer because the developer wanted to check or test something but forgot to adjust the URL.
Those companies would have deployed a package into production with access to all the data from a location without an SLA, no support by IT, and the developer could also adjust code as they please.
The developer could remove the location without knowing that it’s being used in production. Therefore, it is imperative to know where packages deployed to production are located and whether you are happy with them. For example, do they have an SLA or, and if that SLA matches.
I highly recommend using Rencore to control your SharePoint applications, and that starts with code analysis. It is the only solution on the market that analyzes and assures your SharePoint code quality and visualizes the dependencies of code artifacts within applications between SharePoint, Office 365, and external components.
If you would like to see a short 1-minute walk-through video of how SPCAF can benefit you, please head to the SPCAF product page by clicking the button below.