Today we released v0.5.0 of the ngOfficeUiFabric library. This release includes two new directives, bringing us to a total of seventeen (17) directives!
- : Implementation of the datepicker; by @rolandoldengarm
- : Implementation of the navbar; by @s-KaiNet
You can read the release notes for v0.5.0 in our repo: github.com/ngOfficeUIFabric/ng-officeuifabric/blob/master/CHANGELOG.md.
At this point we are at 70% complete with our v1.0.0 release milestone which is full parity coverage where we have a directive for every Office UI Fabric component!
You can grab the latest version from npm, bower nuget or using CDNJS…
This is a collection of directives that implement the Office UI Fabric components with no script dependencies except for Angular. The aim is to make it easier to use the components in fabric within Angular applications.
You don’t have to know all the CSS classes that Fabric uses or exactly how the HTML should line up, the directives do that for you. In addition, because it’s more than just CSS, we will have useful functionality in our directives. For instance, ultimately the table will provide sortable columns!
There are other design libraries out there you can use to build your Angular applications for Office products, such as Angular Material and UI Bootstrap which are fantastic options, but why not use the same design language that the hosting application (Office clients / Office 365 / SharePoint) uses?
We have plans for a full-blown demo site in the future, but the idea was to get a handful of directives built first so we have something to work with. That demo site will live at http://ngOfficeUiFabric.com. Today each directive in the main source repo contains a few usage demos where you can see how they work. I took these demos and put them in a spot where you can easily see them working without any extra work. For now if you go to http://ngOfficeUiFabric.com/demos you can see each directive in action.
However you can also build the library yourself. Jump to the section on How Can I Get Involved below to see how this is done.
Interested in picking up a directive and contributing? Fantastic! First, I’d get a copy of the project locally, build & test it. Poke around and see if things are familiar to you to see how we do things.
For the geeky / code questions, here’s a high-level overview of the project:
- We are using the external module pattern in TypeScript to define the directives (no namespaces / internal modules).
- All code is vetted against defined rules using TSLINT.
- Module loading in the browser by employing webpack which does all bundling & dependency loading of the modules. There’s nothing for developers to do here… everything is already setup. If you need a module, you simply import it into your existing module and webpack handles loading it for you.
- All directives must have associated unit tests and a high level of code coverage (today over 99% of all lines are tested).
- When pull requests are submitted we have an automated build process that kicks off via TravisCI that builds the library, runs all tests & other checks. If something fails, it’s on the developer who’s submitting the pull request to fix it before we consider it.
- Eventually we’ll have an automated release process where each time someone adds a new directive, we’ll increment automatically build a new version & publish a release.
Want to see it in action? We have a Minimal Path to Awesome doc that walks you through getting the code, installing the dependencies (there are only two: TypeScript & TSD) transpiling the code, vetting all the code for style conformity, run all unit tests, view the code coverage reports, building the library & viewing the working demos… all from the source code in the main repo.
Interested in helping out? Check out the CONTRIBUTING guide to see our guidelines then check out our issues list to see what directives haven’t been claimed and express interest in one!comments powered by Disqus