Recently, I built a web part for a client, which led to a discussion about why the web part background was static white, which did not reflect the branding on the page. My quick fix was to just change the color manually, but now I wanted to know more about how I could build webparts that are aware of the area that they are in. It turns out, there are several options, depending on the capabilities needed and the web part framework.
Microsoft warned us! The Document Object Model (DOM) on web pages was a common target in my pre-SPFx solutions, especially the ones that used jQuery. When SPFx came along, Microsoft was very clear that the classes and element ids on the modern page were not an API. By that, they meant that there was no contract with developers that those values would not change in the future. The future is here!
I recently ran into a situation where building and debugging a SPFx web part seemed to go off the rails. Then I figured out that my normal pattern of skipping the ‘gulp clean’ command during project deployment had cause what I thought was bizarre behavior in Site Collection Features and toolbox.
I was working for a client that does not have a dedicated development or QA environment due primarily to political reasons. They also block access to all non-company tenants. Fortunately, I am able to do my development “off network” and once everything is ready, I move the code inside the firewall. Since this was an update to an existing web part, I knew deploying it to the same tenant as the existing web part was going to be tricky. The existing web part is on the company intranet home page, so getting into a site for testing without affecting the original web part meant deploying into a “QA” site app catalog. I thought this would work and there shouldn’t be any conflict. Famous last words …
Have you ever found yourself looking for an icon, but not able to quite track down the perfect one? Between SPFx projects and the new modern list formatting capabilities in Microsoft 365, I am often looking for the icon to perfectly represent my idea. Until now, this process involved browsing through the Fluent UI website in hopes that I will stumble across one that works. Now there is a better way: Flicon.io
As the development pendulum has swung back to the “front end,” I find a majority of my time in VS Code. Back in the early days of VS Code, I missed the rich toolset of Visual Studio, but as I became more comfortable with the combination of command line and graphical interfaces in VS Code, as well as the explosion of awesome extensions for VS Code, I found myself opening Visual Studio less and less. (Honestly, when I open Visual Studio these days, it’s because the icon is next to VS Code in my taskbar and I accidentally click the wrong one. As long as it’s open, I apply the latest updates and close it back down.)
DEPRECATED: This article has been updated. Please see the latest version at SharePoint Framework (SPFx) Quick Start (Gulp toolchain for SPFx v1.21.0 and earlier)
This article left in place for historical reference.
For the several years now, I have concentrated on helping developers to get started coding in the SharePoint Framework (SPFx). My primary message has always been that, “despite it being a complete departure from previous coding approaches in the SharePoint, it’s not as difficult as it seems and you should just give it a try.” I am updating that presentation to include recent changes to SPFx as I prepare for upcoming engagements at North American Collaboration Summit (NACS) and ShareCloud Summit and will post it on this site when available.
