Veni, Vidi, Vici

In my last post I announced the implementation of the native html dialog element in hTWOo-Core and the corresponding component in the hTWOo-React library.

hTWOo is a pure html and css implementation of Microsoft Fluent Design. hTWOo-React is a ReactJS wrapper for hTWOo-Core.

This post started with a question posted in sp-dev-docs that Stefan Bauer pointed out to me. It’s a really good question and I felt like others might benefit. Essentially the OP was stuck on how to use ReactJS in a SharePoint Framework Extension that by default doesn’t give you an option for using a framework. In general for basic scenarios you probably wouldn’t need a framework so I totally understand why that’s the case, however, sometimes you want to do more and so this demo will show you how.

We’ve just released the latest version of hTWOo-React, version 2.1. I’m going to be posting various updates highlighting some of the new updates over the next several weeks, so please check back or follow me on LinkedIn for more updates. For more information on hTWOo-React check out our documentation. For an overview of hTWOo please see this previous post or visit our hTWOo page.

hTWOo is a pure html and css implementation of Microsoft Fluent Design. hTWOo-React is a ReactJS wrapper for hTWOo-Core.

[Read More]

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.

Getting Stared with hTWOo-React presentation

This PnP Community demo is taken from the Viva Connections & SharePoint Framework Bi-weekly sync call recorded on January 12, 2023.

I recently had the opportunity to present a “Getting Started with hTWOo React” session on the bi-weekly Viva Connections & SharePoint Framework call. I always love being able to present the fun stuff I’m working on to the rest of the community. For those of you who are not familiar, hTWOo is an open source alternative for Microsoft’s Fluent UI Web Design system. Although we currently provide a component library for only the ReactJS framework (hTWOo React), this project also offers a style guide based on HTML and CSS (hTWOo Core) to allow users to create implementations for any other frameworks. What’s especially great for those of us who develop solution that extend Microsoft 365 is that Microsoft’s Fluent UI ReactJs components are particularly opinionated about how you use them and because the library is ever evolving and not backwards compatible with previous versions, like Office UI Fabric React, you end up having to do a lot of rework to stay up to date. We believe that our open source version of hTWOo React provides a better development experience with accessibility and extensibility as a top priority.

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. Further, to clarify the library does very little manipulation of the results (only parsing) and is essentially a pass through for those API endpoints. That said we do also offer some helper functions that make more than one call to make some complicated tasks simpler, but these are fairly rare, Taxonomy - getAllChildrenAsOrderedTree is a popular example.

After several years of building SharePoint Framework solutions on an almost daily basis you get to the point where you’ve managed to find some things that work pretty well. I recently started a new project and after sharing them with the team realized that maybe these tips would be useful to others and so thought to consolidate them into a list.

Change the default view for the tenant app catalog

Probably not the oddest, but certainly in a top 10 oddest OOB settings in SharePoint, is the list view settings for the default view in the tenant app catalog for SharePoint apps which groups by Product ID. Definitely, a head scratcher. Luckily, the catalog is just a plain old (and still classic) SharePoint library. Depending on which type of app catalog (tenant or site collection) and what I’m using it for I have a couple of different go-to views. For the tenant app catalog, I like to change the grouping from the “Product ID” field to the “Tenant Deployed” field and also sort by “Title” so that I can easily find a solution to check its version* or status.

When someone says to you, they are using their “dev tenant” what they’re probably referring to is their personal development “sandbox” they received as part of joining the Microsoft 365 developer program.

By visiting Developer Program - Microsoft 365 and selecting “Join Now” you’ll be walked through a wizard that will help you provision your very own Microsoft 365 tenant. You can see the details here, but the general idea is that you’ll have a tenant, where you get to be the omnipotent global admin, with 25 E5 Microsoft 365 licenses available to you that allow you to build out and test various scenarios within the ecosystem. 25 E5 licenses is a lot of horsepower to begin building out scenarios that mix the various tools of Microsoft 365 tenant (SharePoint, Teams, OneDrive, PowerApps, PowerAutomate, etc) into solutions for your “customers”. Although I know many people who advocate and joke about “build it in production”, the reality is that doing so is invasive and can have catastrophic consequences. As with many things you need to weigh the pros and the cons but the ability to fully realize and test your solutions in a “safe space” is powerful and can make you try things you might not if you’re worried about bringing down production. Better yet, if you continue to use the tenant, every 90 days it will auto renew so that you never have to worry about losing your work in progress. In addition, for those that work with Microsoft 365 every day the ability to keep up with what’s going on, what’s changing, and how to best implement your ideas is priceless. You can keep up with the status of your subscription by visiting the Dashboard - Microsoft 365 Dev Center Page - https://developer.microsoft.com/en-us/microsoft-365/profile.

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.

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.

I learned about CSS Variables from Stefan Bauer and his post CSS Variables support for SPFx projects through spfx-uifabric-themes. In a nutshell, this npm package, which I’ve started using regularly, transforms the current theme colors available to the SPFx web part into variables that can be used within your SCSS/CSS files. This intrigued me as it’s a native browser capability that’s been around since 2015 and because it means that you can affect the styling at run-time vs build-time… which translated means that lots of things you would normally think you’d need script for you can now do with a crafty use of CSS and some variables. Generally, CSS Variables are scoped at the “root”, as Stefan does with the theme colors. This makes sense when you have values that should be consistent across the page. However, it turns out that CSS variables can also be scoped to an element and its children. Hmmm… this led me to realize that I can create these variables in the scope of the web part (not the page) and thereby they can have different values for each instance of the web part on the page. This design pattern came in super handy in my demo for the talk I was doing with Mark Rackley at this years SharePoint Conference (Anything you can do, I can do better… Embracing the SharePoint Framework). In the session Mark and I were discussing the merits of “advancing” your development skills [javascript -> typescript, leveraging certain packages, the async/await pattern vs promises, etc.] The goal for my demo was to take a JavaScript project that he had done and hosted in a content editor web part on a classic page and “modernize” it. I did this in a variety of ways but one of the coolest was this CSS variable pattern. So, let me show you.