Latest TypeScript topics

I was recently asked by a conference attendee to help him understand when to use the @pnp/logging package that we ship with PnPjs. This is an excellent question, and I’ve addressed it somewhat before in a previous post called Resolve to Log. All of the guidance I included about the package in that post still applies, however the examples references V2 of the library. To recap there is the ability to create a ConsoleLogger, a FunctionalLogger, or a custom listener class and then register that listener to the PnPjs timeline via the PnPLogging behavior. [Continue Reading]

This content has also been posted on Microsoft 365 Platform Community Blog. Introduction As a co-maintainer of the PnPjs library I know it can be difficult for those just starting out with the library. I wanted to introduce a blog post that goes into more depth about how to start your journey. Let’s drive right in. What is PnPjs PnPjs is a collection of fluent libraries for consuming SharePoint, Graph, and Office 365 REST APIs. So what is a fluent library. Essentially it just means that instead of creating a URL as a string, and then using the fetch api to make a get/post/put/patch call to the API directly, the library allows you to chain method names together to let the underlying code build the fetch call for you. This significantly simplify and streamlines your code since all the boilerplate code for creating the call, modifying headers, deserializing responses, error handling, and throttling is done for you. [Continue Reading]

I suspect, like Elio Struyf and Velin Georgiev before him, we’re all suffering from PTSD trying to properly load an application customizer into modern pages. It all started with an issue posted in the sp-dev-docs repo that was about partial page load across site collections but devolved into and issue with the OnInit function firing multiple times. Velin’s post describing his solution to the issue starts with a masterful breakdown of the page loading cycle and his need to track page hits. Then, Elio’s variation highlights other things to check like what Hub Site do I belong to and what UI language does this page support and how those things might impact the transition with relation to the application customizer. This post is going to take that one step further and address page transition between sites where one site might include the application customizer and the other might not. This is all in reference to the Multilingual Pages solution that lives in the SP-Dev-Solutions repo. This is a 400 level blog post so I’m not going to reiterate what Velin and Elio already did in their posts. Instead, I encourage you to pause here and go read their posts and then come back to continue on the journey. [Continue Reading]

This quick post is going to fall into my Tips & Tricks category as it’s information readily available but if you didn’t know to look for it you probably wouldn’t have found it. In version 16.2 React JS introduced the notion of “Fragments”. A Fragment is basically an empty container that you can use in a react component to group a set of children together without adding additional nodes into the DOM. Prior to version 16.2 (and 16.0 – we’ll get to why in a moment), every component must return one and only one parent node. This makes a certain amount of sense, but there are situations where you want a component to return a set of siblings. So, to support this scenario you would artificially add a <div> element to your component to adhere to that requirement. [Continue Reading]

This post has been updated in a more recent post Console Log Better Practices with PnPjs V3. My Sympraxis partner Marc Anderson mentioned that we’ve been talking about PnPJS packages for SharePoint Framework a lot lately and called out that I would be blogging about utilizing the logging package in his post Using PnPJS and Async/Await to Really Simplify Your API Calls. If you haven’t checked it out and aren’t using PnPJS and the Async/Await method instead of Promises in your SharePoint Framework solutions, you should give it a read. [Continue Reading]

This post is meant to be a quick supplement to the documentation provided by Microsoft around the Nav component of the Fluent UI. This Nav component gives you a control that you either create URL links or maybe more commonly, support navigation via code. For general links, where the URL is either a route or some other page, the implementation of the INavLinkGroup[] and INavLink is quite straight forward, just provide a Key, Name, and URL with a couple other optional parameters. For programmatic support, the documentation provides a solution but as it turns out that implementation is misleading. I was finding that my nav items that needed to execute a bit of code would sometimes execute that code twice. As it turns out I wasn’t using it right, so let me help clarify by showing you what I found. [Continue Reading]

For this last post I want to take what we’ve learned and add the final pieces that have you creating web parts in the same way you would modern SPFx web parts and solutions. We’re going to start by discussing TypeScript and then briefly touch on Sass and how to include these languages into your new Webpack/Gulp environment. TypeScript is becoming almost ubiquitous in modern web development. The pros are numerous, my favorites are the ability to write code to target older browser with modern capabilities, and the ability to use a version of intellisense to validate your objects properties and methods. In my experience both of these features makes development go faster. The cons are that you’ll need to transpile your code as well as utilize typings for the libraries you want to include. By using Visual Studio Code, or another IDE as your development environment TypeScript is pretty much built in. If you are coming from C#, or some other compiled language, you’re going to find that you feel significantly more comfortable writing TypeScript than JavaScript, mainly because many of the conventions you’re used to have an equivalent in the TypeScript language and thus patterns like MVVM are easily implemented. [Continue Reading]

In our last post I went through the gulp process we were implementing to watch our files and upload them into an appropriate SharePoint library so that we can test our work inside SharePoint regardless of if SharePoint was version 2007 or SharePoint Online. Now we’re going to take things further and formalize our process. One of the tools the SharePoint Framework (SPFx) uses is Webpack. Webpack’s main goal is to take the many files that you create as a developer and bundle them all together into one JavaScript file. The benefit of bundling is that we make one call to one file instead of multiple calls for many files which is more efficient (in general). What it also does is simplify the maintenance of your JavaScript references because instead of having 10’s of files you end up with as little as 1 file. [Continue Reading]

In the first post in this series I discussed some of the benefits of formalizing your client-side development process and then a bit about starting the process of tooling up. A common scenario to develop our own client-side solutions in SharePoint is to point a Content Editor (CEWP) or Script Editor (SEWP) web part at our custom html, css, and js files that are sitting in a document library somewhere in our environment. In this post I want to dive into the most basic implementations of a development toolchain that will automatically deploy those files into a location in SharePoint. This does not mean, and in most cases, should not mean, “production”. What it means is that while you’re developing your code any changes you make will be automatically uploaded to a location that you already have your CEWP or SEWP pointed to, that way when you refresh the page your custom solution will refresh with the latest version of your code. To accomplish this, we’re going to use Gulp which is a JavaScript based task runner similar to the build process that exists in Visual Studio. [Continue Reading]

Last year, around this time, Marc and I agreed we should write a blog series on our development process. As often happens good intentions get buried in other commitments, but I’ve finally managed to circle back on this topic which I’m finding has become more important than ever. Over the last year the SharePoint Framework has taken off. Although it still doesn’t support the paradigm that I most often am developing for - the full-page app hosted in SharePoint - I still think it’s a great model for development. At this point Modern has come far enough in its parity with Classic that Marc and I are recommending to our clients on or going to Office 365 to go Modern first, and then fall back if you’re impeded. That said, we know from our client conversations that a significant number of organizations are still using legacy versions of SharePoint, some all the way back to the 2007 version. There is absolutely nothing wrong with that if it’s working for your organization, but I suspect some people are feeling a little left out in the cold with regard to how they fit into the conversation when SharePoint Framework is at this time only for SharePoint online or for SharePoint 2016 with Feature Pack 1. Further, I suspect many on these older versions envision a time in the not too distant future where they will be migrating to either a newer/newest version of the on premises product or to Office 365. The point that I’m going to make in this series is that even if you’re not using the SharePoint Framework you can create your own process that mimics the toolchain and propels your development from a bit of a hack into a more formalized process. Not only does this help your organization; it helps you become more marketable in today’s SharePoint development environment. [Continue Reading]