I’ve waited a long time to write this post but after some recent developments were made more public last week, I finally feel like it’s time to start moving forward.
TL;DR
Heads up, this is a long post. The goal is to have a single link to point people to when they ask about the future & state of the ngOfficeUIFabric project, including the backstory. Therefore I’ve broken it up into the following sections:
- Office UI Fabric - November 2017, State of the Union - Think of this as the “state of the union” on the Office UI Fabric. This set the stage for the future of the ngOfficeUIFabric project.
- ngOfficeUIFabric - AngularJS Directives for Office UI Fabric - This community project provides AngularJS directives for the Office UI Fabric for projects leveraging AngularJS 1.6.x.
- ngOfficeUIFabric - @NEXT - The future of ngOfficeUIFabric, including supporting Angular (v5.0) and so much more. I suspect many came just for this… feel free to skip ahead!
Office UI Fabric - November 2017, State of the Union
The Office UI Fabric is a design language, styles, and components that implement the UX for virtually all Office-related products and services including Office 365, SharePoint, Exchange Office (Outlook, Word, Excel, PowerPoint, etc) on the web, desktop and mobile. It was based on Microsoft’s Metro Modern design with sharp, flat edges with solid colors.
The Office UI Fabric is built by the OneDrive Design Studio team and consists of styles, typography, icons, fonts, colors, layouts and animations. It also has a number of controls defined like buttons, panels, drop down selectors, dialogs, and many more things. Most of this is done with CSS, but a lot requires JavaScript to implement it.
Let’s look at how you can get & use the Office UI Fabric… at least how it’s provided by Microsoft. I’m going to just stick to the facts for now… I have some strong opinions but I’ll hold onto those for a moment and make it clear when the opinion part starts.
Office UI Fabric Core CSS
If you want just the CSS in your project, stuff like colors, typography, icons and a few other things… basically nothing that’s interactive… you can use the core CSS project. This is available from the Github repo OfficeDev/office-ui-fabric-core.
While this doesn’t include everything the Office UI Fabric has to offer, it’s sometimes all people need.
Fabric React
As I stated above, the Office UI Fabric is not just styles, but also controls that you can use in other applications. What the OneDrive Design Studio team decided to do was use ReactJS to create these controls and provide them in a library called Fabric React.
This is what Microsoft uses in Office 365 properties like SharePoint, OneDrive, and Exchange. One nice point is that Microsoft makes these controls available to developers for free. So, if you are building an Add-in for Outlook or client-side web part for the SharePoint Framework to host in SharePoint, you can use these controls Microsoft has created so your thing looks like the hosting application which makes for a good experience. These controls are also already loaded on the page where your component runs because Microsoft is using them.
Current Microsoft-provided Office UI Fabric Challenges
Some of what follows is my opinion, some is fact… feel free to drop a comment and challenge me in the form at the end of this post!
There are a few challenges developers have been running into with the different things the OneDrive Design Studio team provides as they related to the Office UI Fabric.
First, let’s say you only want to use the core CSS. The stuff in the core CSS is refactored from the Fabric React project. Not everything is here… as I said above its just colors, fonts, icons and stuff like that. No components. That’s fine, but it also lags behind changes the team is implementing in the Fabric React project.
Second, if you want to use the interactive controls in Fabric React, you just got self-selected into using ReactJS in your Office Add-in or SharePoint Framework client-side web part. Why? Fabric React is React, so your app that leverages it must be ReactJS.
Third, while the SharePoint team has provided guidance on how to leverage the Office UI Fabric, the recommendation is still to embed the Fabric React controls in your bundle and not rely on the version that’s used by the hosting app. Why? No way to slice this: the Fabric React team has consistently shown to have a bad track record in making changes without much notice and not being backward compatible. The only way to avoid this: you have your own copy.
What if you are an Angular developer and want to use the Office UI Fabric? Today there’s only one option, and it’s dated: ngOfficeUIFabric. This library is written to work with AngularJS which is v1.6.x; it does not work with current versions of Angular (v4.0 / v5.0).
Clearly, we have a few challenges… but enough history. Is there a path forward?
Yes… but I need to explain something first…
ngOfficeUIFabric - AngularJS Directives for Office UI Fabric
I am the project steward for the ngOfficeUIFabric project. This library was started years ago as a community project to build AngularJS directives for projects that leverage AngularJS v1.6.x. Let me be clear, this isn’t my library. This library is the product of some rock-star contributors in the SharePoint community.
There are two current challenges with this library:
Works with AngularJS (v1.6.x); Doesn’t work with Angular (v4.0 / v5.0) - Developers usually find their way to the library when they are working with Angular only to realize it only works with older versions, not the current version of Angular.
Implements MDL1, not current Office UI Fabric MDL2+ - Huh? I did my best to explain this in issue #405. The gist is that when Office UI Framework first came out, it was using what’s called the modern design language (MDL) v1 (well… we didn’t know it was v1 at the time, but we did when MDL2 came out). That’s what the library was based on.
Then they decided to make a bunch of changes to the CSS and called that MDL2. And then later there were a few more tweaks to the Office UI Fabric.
The ngOfficeUIFabric library does not implement these latest changes. At times when you try to use the ngOfficeUIFabric in some SPFx projects, the CSS that the ngOfficeUIFabric depends on (Fabric Core CSS v2.6.3 which is MDL1) could conflict with the CSS already on the page that implements MDL2+.
People have been asking “what’s next” for a while now…
ngOfficeUIFabric - @NEXT
The name isn’t settled… ngOfficeUIFabric@NEXT is just a temp placeholder for now & won’t be the final name by any means.
Yesterday in my blog post, Solve the SharePoint Framework + Angular Challenge with Angular 5.0 Elements, I talked about the work that Google is doing with Angular Elements that will yield a viable and better development experience for those of us who want to use Angular in our SPFx solutions.
But it doesn’t stop there. Why can’t we take this one more step and leverage this for the next iteration of ngOfficeUIFabric… what I’ll refer to as ngOfficeUIFabric@NEXT for the time being? We will!
The Pitch for ngOfficeUIFabric@NEXT
Wouldn’t it be cool if contributors to the project…
- used Angular 5.0, Angular Elements and TypeScript to build Office UI Fabric controls…
- used the specs for Fabric React controls, (which are already spec’d out like this
<Button>control)… - strictly adhere to semantic versioning so there were no surprising breaking changes
… so that consumers of the library…
- referenced a component from a CDN hosted JavaScript file…
- this would self-declare the component like as a custom element
<uif-button></uif-button>
- this would self-declare the component like as a custom element
- used the control with standard HTML & JavaScript…
- all with ZERO requirements on what web framework you use…
- have faith in a library that is backward compatible
Do you prefer ReactJS, Vue.js, jQuery, Angular or {new-framework-coming-out-on-2nd-Tuesday-of-the-month}? fine… you can still use this library!
The spirit of this is spelled out in the answer that Rob Wormald from Google’s Angular team gave at the Chrome Dev Summit recently. To paraphrase Rob: “can’t we write the date picker just one last time and be done with it, not write one for Angular, ReactJS, Preact, jQuery, Vue.js, etc… just one date picker element and be done with it?”
That’s the plan… it’s too early to start the project as Angular Elements needs to be fully baked and a few other things need to get settled. Like what? Consider the following list…
- Take a dependency on the Office UI Fabric Core CSS or implement our own copy?
- Project names - this isn’t as straightforward as you might think… consider:
- In my opinion, ng and Angular shouldn’t be in the name because that implies you need Angular to use it, which you don’t, that’s just the requirement for contributing to the source.
- Fabric Elements doesn’t work either for the same reason
- Fabric Components might work because the output are web components
- Maybe ngOfficeUIFabricElements is the source project you contribute to, but it generates Fabric Components? Will that be confusing though as the current Fabric React contains components?
- Should it leverage the Component Development Kit (CDK) that would be the underpinning of the controls? It’s what that Angular Material guys use and might save a lot of time. You can learn a bit more from the Angular Material docs & demo site and from this blog post.
Like I said above, it’s a bit too early to get started on the project. I’m keeping a close eye on the state of Angular Elements and as soon as it makes sense, we’ll spin up a new repo in the ngOfficeUIFabric Github organization and leverage our current CDN investments.
Am I sure you’ve got questions… maybe some ideas? Are you interested in contributing? Drop a comment below and join the discussion!