Last week, on July 27, 2016, the Office UI Fabric team published a blog post (The evolution of Fabric’s components) that mentioned some changes to the Office UI Fabric project… some pretty significant changes. The changes were a little hard to understand as mentioned in the blog post, at least from my perspective, so I did a little digging and talked to the team to get clarification. In this post, I’ll explain what’s going on, what I learned, where they are & where they are going. I’ll also offer a few thoughts on this direction. In addition, at the end I’ll talk about how these changes will affect a project that I’m involved in, the Angular (v1) Directives for Office UI Fabric, also known as the ngOfficeUIFabric.
As a heads up, there are going to be a few version numbers and acronyms thrown around in this post. No way to avoid these and they are important to understanding where everything is. I wanted to give you a heads up so you don’t just blow off some numbers.
Current State of Office UI Fabric (v2.6.1)
From the initial introduction of the Office UI Fabric, we’ve been working from a single output package/library that’s rooted from a single repo in GitHub: https://github.com/officedev/office-ui-fabric. This repository contained two things: CSS and JavaScript. The CSS included all the colors, typography, iconography, animations and the classes used to implement the various components such as the toggle, button, and table. The JavaScript was mostly just sample code that demonstrated the functionality of some components, but it wasn’t included as production quality JS. This did change a bit as of recent when they moved all their code to TypeScript.
This implementation of the Office UI Fabric implemented something I’ll call MDL1 (not an official term, that’s my term). This stands for the Modern / Metro Design Language v1 and is what you saw with the original release of SharePoint & Office 365. However, if you have a keen eye you might have noticed that lately Microsoft has been changing the UI a bit… things like toggle buttons look a bit different as the navigation and command bars. For now, just file that MDL1 information away as I’ll come back to it later.
So that’s where we are today. The current version of fabric is v2.6.1 and is available via multiple package managers like NuGet and npm.
Before We Talk About Office UI Fabric v3+, You Have to Understand Something…
Before I start explaining where Office UI Fabric goes from here and their future plans, it helps if you had a bit more info in your head. If you’ve paid attention to any of the blog posts from SharePoint MVPs immediately following the Future of SharePoint event on May 4th, you know there’s a new development model coming to SharePoint: the SharePoint Framework. From what we know about this framework, Microsoft is adopting the React library from Facebook for user interface components in SharePoint that will leverage this new development model. OK… so just file that away for a moment…
Office UI Fabric (v3+) Changes
In early July, Office UI Fabric v3 was released as a preview. We saw some changes but the real change didn’t really start to hit from my perspective until the blog post was published last week (The evolution of Fabric’s components). There are a few things that are happening in this post.
First, if you were watching the repo, you would have seen references to MDL2. Recall from above the explanation of MDL1? Well, this is v2. You may have noticed as a user of Office 365, SharePoint Online and Exchange Online how some things have changed a bit like I said above, things like toggle buttons, navigation and command bars. This is referred to as Metro / Modern Design Language v2, or MDL2.
That’s not all… the other big thing that is going on is a reorganization of the libraries. Recall from above we had one library with everything in it. That’s no longer the case… now we have three projects:
- office-ui-fabric-core - This contains the core colors, typography, iconography and styles… but this does not include the CSS styles and classes used to implement the different components.
- office-ui-fabric-js - This depends on the core library and includes the CSS and JavaScript needed to implement the Office UI Fabric controls without a dependency on any specific UI library.
- office-ui-fabric-react - This depends on the core library and includes the CSS and JavaScript needed to implement the Office UI Fabric controls in React.
Because SharePoint is clearly taking a dependency on React, you can bet they will be focusing on the React library. This means the most current work on components, including the CSS classes used to implement these components, will be done in the React library.
But What If You Don’t Want to Use React?
In talking to the team, my understanding is that it is their goal to also keep the JS version of the library updated with the same code and CSS classes that are needed to implement the components. We’ll see how much the two libraries stay in sync… but I would frankly be a bit surprised if they did stay in sync. Let’s face it, their customers are primarily the SharePoint & Office 365 engineering teams who are taking the dependency on React so that’s their focus.
What Does this Mean for the Angular Directives for Office UI Fabric / ngOfficeUIFabric?
Good question. Today the ngOfficeUIFabric requires Office UI Fabric v2.6.1 and we’re marching to our v1 release. This release includes a single JavaScript library because all the CSS for typography, iconography, colors, fonts and classes implementing the controls is in the main Office UI Fabric v2.6.1 release. However going forward this isn’t the case.
The ngOfficeUIFabric project is an open source community-based project, one that is mostly run by a handful of people. Let me explain how I think we should proceed, but keep in mind I think this should be a consensus decision. If you’d like to through your thoughts in, jump over to this issue in our repo Big changes to Office UI Fabric (MDL1>MDL2, v2.6.1>v3, New Libraries & More) and make your thoughts known.
- ngOfficeUIFabric v1 - I think that we should proceed with our plan for ngOfficeUIFabric v1, where it is dependent on Office UI Fabric v2.6.1. The “v1” can be considered the implementation of Fabric’s MDL1. This release, like today, will include only a single JavaScript library (both in minified & unminified form).
- ngOfficeUIFabric v2 - Going forward, ngOfficeUIFabric v2 should be based on Fabric’s MDL2 and thus take a dependency on the Office UI Fabric’s Core v3+ library. However, this means that we will need to include our own CSS classes that will be inspired and based on the classes implemented in the React library since they will no longer be in the core release. Yeah… this means more work for us… and that stinks.
What about Angular 2 & ngOfficeUIFabric?
Good question… I get this a lot. The plan is to certainly build the components for Angular 2, but from my POV we really need to get the Angular 1 story finished first. Angular 1 is still the more used framework today so let’s focus there. But I think that when we move in this direction, we will ignore the MDL1 / Office UI Fabric v2.6.1 and just start the implementation based on MDL2 / Office UI Fabric v3+.
Adding My Personal Thoughts on Fabric’s New direction
Personally, I get what they are doing, but I can’t help but feel a bit disappointed this is the direction they are going on. Let’s face it, Office UI Fabric is the design language & implementation they want to use for their stuff: Office 365, SharePoint, Exchange, OneDrive, etc. They are simply making the language available to everyone else for us to use. However, I can’t help but feel a bit like they’ve gone more about sharing a community thing to switching over and being a bit more self-serving. They aren’t breaking any promises, either explicitly or implicitly, but it just feels like they are focusing more on what they want and less about what’s best for everyone. I say this because if you don’t want to be forced to use React and you want to use another UX library / framework like Angular or Aurelia or whatever else, you can’t use their component’s CSS classes, rather you have to roll your own. Hopefully, we’ll able to lift a bunch of them straight from the React project, but time will tell.
What do you think? Leave a comment!