Skip to content
This repository has been archived by the owner on Jun 14, 2018. It is now read-only.

Big changes to Office UI Fabric (MDL1>MDL2, v2.6.1>v3, New Libraries & More) #405

Open
andrewconnell opened this issue Aug 5, 2016 · 20 comments

Comments

@andrewconnell
Copy link
Member

andrewconnell commented Aug 5, 2016

Spinning this issue up as a place to have a discussion. Recently the Office UI Fabric guys made some big changes with their project that you can see posted on their blog (http://dev.office.com/fabric/blog)... look for the July 27, 2016 post.

I've summarized it here on my blog:
http://www.andrewconnell.com/blog/updates-to-office-ui-fabric-and-ngofficeuifabric-roadmap

At the end of that post, I pitch what I think we should do with ngOfficeUIFabric. What do you think? Here's what I said in summary:

  • 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+.

Thoughts?

@waldekmastykarz
Copy link
Member

Would you use Angular 1.x or Angular 2 for ngOfficeUIFabric v2?

@andrewconnell
Copy link
Member Author

andrewconnell commented Aug 6, 2016

@waldekmastykarz Seems ng1 because it won't require a whole rewrite. Updated my original issue with what I said in the blog post about Angular 2.

@waldekmastykarz
Copy link
Member

If I understand the impact correctly then what we would need to do is to include CSS in our components (basically copy & paste what MS have in React components) and check if there is any functionality that we haven't implemented. Agreed that with Angular 1 it would be less work than with Angular 2 where we would need complete rewrite.

@andrewconnell
Copy link
Member Author

That’s pretty much it for the ngOfficeUIFabric v2… v1 would be based on Fabric’s v2.6.1 which really isn’t any change.

@s-KaiNet
Copy link
Member

s-KaiNet commented Aug 8, 2016

Very good post, @andrewconnell. I understood only a small piece of info from the original post (from MS in July) . Now the direction for Office UI Fabric is much more clear.
I absolutely agree with your plans to have v1 for current 2.6 version and v2 for "MDL2". Since you commented that ngOfficeUIFabric v2 stands for angular 1, how to name the library for angular 2? ng2OfficeUIFabric? Also may be we just need to skip implementation of MDL2 in ng1? I mean we release ngOfficeUIFabric v1 (MDL1), right after that we will start working on ngOfficeUIFabric v2 but in ng2 (some thoughts below).

Some thoughts about ngOfficeUIFabric (just my POV nothing else). This update introduces more work for us - we still need to complete v1, then update to v2 (not whole rewrite, but I'm guessing a good piece of work, also styles and templates which are good for React, may not be so good for angular, we may have issues with that). By now we can see, that the whole contribution process has slowed down a bit, because the project is open source, you can contribute if you have a free time, etc. etc.... We simply don't have enough time to implement every component, do all possible tests, implement all possible usage scenarios (currently React repository contains ~40 components). There will be bugs, issues. ng2 will be released this year (I guess), but we still don't have ngOfficeUIFabric v1 released. That's why may be it's better to start implementation of ngOfficeUIFabric v2 in ng2 (skip ng1 just to save the time). So what I want to say that we don't have enough resources to move forward fast to be inline with React and release of ng2.
Also MS introduced great news for React developers, but angular is also widely used (with release of ng2 angular will become even more popular, I think). So why don't they support angular? In order to move forward in a faster way I thing FTE(s) on this project is required, and that will be great if MS can find a person (or even persons) to work on this project on regular basis. In that case MS will prove their direction to modern technologies and community support. But I would agree with your words in blog post that it looks like currently MS more cares about what they want, rather what community needs.

@andrewconnell
Copy link
Member Author

I'm sort of thinking the same thing @s-KaiNet ... We've already lost a lot of momentum with this project in the recent months, so I think for the time being we should just focus on pushing through with v1.

Having a v2 that is based on Angular 1 & MDL2 would be great, but I'm with you that it might make more sense starting the ng2 implementation that uses MDL2. Maybe two separate code paths...

At any rate... that's stuff we can focus on once v1 is complete.

As for your point about MSFT, they simply chose React because it suited them for their SharePoint Framework (SPFX). They looked at other libraries but that's what they went with. I understand why, but I don't like it as personally I'm not a fan of React (the syntax stinks... JSX just doesn't work for me). But yes... just like everything coming out of the SharePoint engineering teams, they focus not on what the community needs but on what they need. It's a big reason why I'm not building projects for clients on top of SharePoint... it's not a platform no matter what they say. They change the rules and abandon the last way of extending it every 3 years. After going through multiple cycles with them, I'm done... I'd rather build outside where I can just use their APIs rather than have them constantly change the game 😄

@waldekmastykarz
Copy link
Member

Is Angular 2 still a moving target or are the current builds stabilized? Otherwise we would have two moving targets (Angular 2 and Office UI Fabric) which could make it complex to provide a stable release.

@andrewconnell
Copy link
Member Author

Ng2 is very stable… it’s currently in RC but from my POV its strong enough to build against. With that being said, we need to have all focus on our v1 release with ng1 before we start working on ng2.

@Abrissirba
Copy link

Ng2 has been released and I would love to see v2 based on Ng2.

@andrewconnell
Copy link
Member Author

@Abrissirba While we feel the same way, it's not a trivial undertaking. Open source so you can always jump in and help :)

@sjclemmy
Copy link
Contributor

sjclemmy commented Oct 6, 2016

I'm currently developing an Office add-in for a client and I like the direction and purpose of this library. Sorry for my comments being a bit negative it's not meant to be critical. Some things I have noticed / experienced...

I submitted a PR for the toggle component a while back, which passed tests etc, but since using it I notice that it doesn't work as expected. I think that as it depends on ngModel the component becomes a victim of the priority sort in the compilation process so where I'm using it inside a nested component it doesn't apply the values at the correct point in the compile cycle.
I have hacked this and just wrapped it in a $timeout.

In addition I have recently looked at using the MessageBanner component - but I don't want a button, but there is no way to communicate this to the component. Obviously this is a candidate for an update and a PR, however looking at how the banner works, it looks easier just to use the core js library and add my own logic rather than updating the component as the whole PR process is very time consuming.

MS have changed the documentation to point to the React stuff by default and pointed to this library as the go to place to use for angular1. Their documentation is confusing with regard to versions of the core components and which icons are used etc.

So, what's my point?
Microsoft are pushing this library, but it is not really mature enough to use properly without further modification. Further modification is time consuming (especially if the contributor isn't familiar with typescript) in comparison to an implementation of the official 2.6.1 js components (it is just the implementation of classes and a bit of control logic). In addition, if I want to use the new MDL (2?) I can't use this library at all - it's easier to include core and js 2.6.1 and replace the icon names (even if it is a bit hacky).

I think all these things have a negative impact on this library and its usefulness in its current form.

Things that need to be done:

  1. Finish the library in its current form to make it useful 'out of the box'
  2. Update the library to be in line with the React version and the new icons etc.
  3. Create Angular 2 versions of all the components.

Given funding I think all 3 should be done. Without funding I would probably just start on step 3 - create angular 2 versions and as painful as it it, cut your losses with angular1 support.

@andrewconnell
Copy link
Member Author

andrewconnell commented Oct 7, 2016

@sjclemmy There's no debating everything you say. We had good momentum bashing bugs from people using the library, but Microsoft's switch to MDL2 & only focusing on the React implementation frankly has hurt that quite a bit.

You're reiterating what we've already said in this thread IMHO... #1 on your list is what we're doing.

The problem with #2 is that is a SIGNIFICANT amount of work. Even the team doing the react components for Microsoft are having big challenges extracting the styles from their react components to their basic JS libraries.

Frankly, one thing I'm seeing are folks who were using fabric and are pulling back. Microsoft's frequent changes with their direction isn't good. Thus, people are looking to Material Design & back to Bootstrap. I'm in the same boat. Will 2 & 3 happen? We'll see... #1 is the first marker.

My $0.02: I feel confident that 2 for ng1 of this library will NOT happen...

@andrewconnell
Copy link
Member Author

BTW, your last statement is key: there’s never been funding for this. People have dedicated their free / personal time.

@krishna15873
Copy link

@andrewconnell Any progress for Angular 2 ? Workaround on Integrating existing fabric version with Angular 2/4 would be of great help.

@andrewconnell
Copy link
Member Author

Not at this time... hopefully, we'll have a bit of clarity at the end of October / early November.

@Alex-Torres
Copy link

Any updates on Angular 5 UI Support?

@andrewconnell
Copy link
Member Author

@The-Meek-Developer Yup... writing it all up today actually. Watch my blog for plans...

Sneak peek: we aren't ready to start dev just yet, but the story has firmed up significantly.

/cc: @krishna15873

@andrewconnell
Copy link
Member Author

SEE: http://www.andrewconnell.com/blog/future-of-the-ngofficeuifabric-project-office-ui-fabric-components

It's still a bit too early to get started on it... we need Angular Elements to be finalized. We may be a few months to further out than that. Have to see...

@StfBauer
Copy link

StfBauer commented Nov 23, 2017

I will already use the time to create a Fabric version that makes it usable with Angular Elements/Web Components. Through the move of Office UI Fabric moving away from HTML/CSS first to fast run an React Component Library it lacks of proper CSS/SASS.
The HTML code spit out by Office UI Fabric sadly needs to be cleaned up too.

Through a development approach on creating CSS this should be easier adjustable to upcoming changes in Office UI Fabric. In addition it is a more safer approach than you are facing now with Office UI Fabric. High goals but the upcoming month will show.
A fallback to the provided Office UI Fabric then can be done anyway.

@temka1234
Copy link

Is there any chance to use it with angular 2+?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants