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.
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 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…
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.
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.
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.
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 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.
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+.
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!