Today we released v0.3.0 of the ngOfficeUiFabric library. This release includes one new directives, bringing us to a total of thirteen directives!
In Addition, we are now listed in a public CDN! Using the popular CDNJS, when we cut a new release the new files will get sucked into CDNJS within an hour or so, but all old versions will be preserved. Get more info at cdnjs.com/libraries/ngOfficeUiFabric.
You can read the release notes for v0.3.0 in our repo: github.com/ngOfficeUIFabric/ng-officeuifabric/releases/tag/0.3.0.
We’re in the middle of some big changes to the repo that you should be aware of. First, we’re working to add validation & error logging to all directives that have an attribute with a deterministic set of expected values. We are also working to resolve an issue that was exposed with a new check added in Angular’s
$compile service in Angular 1.4.9.
Finally, we have updated our test suite so it assumes jQuery is not being used on a page. Previously we were using a library that let us leverage jQuery within our tests to select elements, classes and the like. It made writing tests easier. However it was also adding jQuery to the tested pages which Angular was seeing and defaulting to that instead of it’s internal jqLite version. Since we don’t want to take a dependency on jQuery in our library, we had to make some changes to the test suite to make sure that we can still use jQuery in our tests, but not in the library. If you’re curious about this, check out the discussion in issue #106 and the resolution in pull release #121.
I’m sure some are wondering about breaking changes… yes we introduced one in this release. We have said we will use semantic versioning. As for the breaking changes bit… we are currently in our infancy and as we bump into some issues, we are addressing them head on and making changes immediately. I would expect to see a few of these crop up, but settle down soon.
At this point we are at 50% 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 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!comments powered by Disqus