Today we released v0.2.0 of the ngOfficeUiFabric library. This release includes four new directives, bringing us to a total of ten directives!
- Implementation of the choicefield ; by @rolandoldengarm
- Implementation of the link ; by @tdwhite0
- Implementation of the overlay ; by @johnmeilleur
- Implementation of the progressindicator ; by @johnmeilleur
We have also started to add validation to directives. For instance if you specify an icon that isn’t supported by the Office UI Fabric in the directive, a error message will be written to the console. Further, we are creating TypeScript enums for all directive properties with deterministic settings. If what you specify is not in the enum, we log the error inthe console. In the near future we plan to publish a TypeScript type definition that includes all these enums & public properties on the directives.
You can see all the changes by viewing the project’s changelog .
At this point we are at 39% complete with our v1.0.0 release milestone which is full parity coverage where we have a directive for every Office UI Fabric component!
Just like before, you can grab the latest version from npm, bower or nuget…
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!