ngofficeuifabric / ng-officeuifabric Goto Github PK
View Code? Open in Web Editor NEWOffice UI Fabric (https://github.com/OfficeDev/office-ui-fabric) implementation for Angular
Home Page: http://ngOfficeUiFabric.com
License: MIT License
Office UI Fabric (https://github.com/OfficeDev/office-ui-fabric) implementation for Angular
Home Page: http://ngOfficeUiFabric.com
License: MIT License
Official link to component description & demo: http://dev.office.com/fabric/components/spinner
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/orgchart
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Create an example site that will live in the repo ngofficeuifabric.github.io & live at the site http://ngofficeuifabric.com/
Ideally this will get updated automatically on new library releases & dynamically pull examples from each component's folder.
Official link to component description & demo: http://dev.office.com/fabric/components/contextualmenu
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
For toggle component, index.js files are missing for both demos.
Official link to component description & demo: http://dev.office.com/fabric/components/pivot
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/list
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/panel
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Currently the TextField directive supports defining required fields (
). This is however a custom implementation that isn't a part of Office UI Fabric.As there are many different ways in how required fields can be marked in applications and there is no specification of it in Office UI Fabric, current implementation should be removed from the directive to stay aligned with Office UI Fabric.
Official link to component description & demo: http://dev.office.com/fabric/components/label
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/searchbox
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://codepen.io/andrewconnell/pen/YyGzRv
It would be nice if the web site would show a live demo of all available components.
Official link to component description & demo: http://dev.office.com/fabric/components/persona
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/personacard
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/textfield
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
This isn't in Office UI Fabric, but would be used by multiple directives as well as outside the components. See issue #14 for reference.
Spec:
<uif-icon uif-type="plus" />
This would render out the HTML that uses the icon for a PLUS.
Official link to component description & demo: http://dev.office.com/fabric/components/link
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Add support for sorting table using column headers based on the following specs:
uif-sortable
attribute set to true
Official link to component description & demo: http://dev.office.com/fabric/components/navbar
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Currently developers must manually run builds of the library, manually vet code & manually run tests. Create a gulp task(s) that will watch for code changes and automate the above stuff.
Right now our demos are pulling CDN references for Angular & Office UI Fabric. While it works, it can also be problematic. For instance, the Office UI Fabric guys shipped 1.2 late last week, but it won't be in the CDN for another 1-2 weeks. As such @jjczopek had to self-host it and reference that link.
I propose we add two NPM dependencies on Angular 1.4.8 & Office UI Fabric 1.2.0 (both of which are live and update the demos to point to the local copies).
Thoughts? I'm in favor and can retrofit everything before our 0.1.0 release.
Picking NPM over bower to eliminate the extra step people would need to try the demos out.
Official link to component description & demo: http://dev.office.com/fabric/components/datepicker
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/choicefield
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Looking at @andrewconnell Pen @ http://codepen.io/andrewconnell/pen/MaedKX I've noticed that buttons are defined as a <button>, <div> and <a>. If we use an element directive won't we be dictating which element is rendered rather than allowing developers to choose what makes the most sense for their application? The confusing part is that if you look at the current Fabric samples @ http://dev.office.com/fabric/components/button all buttons are rendered as <button>. Fabric however supports applying the .ms-Button class on any kind of element.
If you look at ngMaterial (https://github.com/angular/material/blob/8ef798f0fe242c555ef7c11fa0abe762fb218a02/src/components/button/button.js) they support both element- and attribute-level usage and default to the <button> element. Is this something that we would like to be doing as well to provide developers with maximum flexibility?
Official link to component description & demo: http://dev.office.com/fabric/components/commandbar
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Handful of 404's and typos in docs:
After a healthy discussion in our Slack group, we've decided to make a few changes early on before we have too many directives built. These changes are going to be implemented immediately before we have our first release of the library. The motivation behind these changes are for following what the Angular team is doing, making it easier to build & consume directives & following general guidance.
I am going to work on updating the build process & also updating / adding docs along the lines of "building my first directive" as part of this process...
All directives, tests & examples will be authored in TypeScript. Examples can also be implemented using JavaScript (ES5 / ES6).
WHY? - We really need to standardize on one language and not have a collection of directives written in different languages.
All directives should be written as external modules and export themselves as a module, not exporting the actual directive.
WHY? - The general consensus from the TypeScript community of late is that external modules are the way to go, even from the TypeScript authors. You can see some of the discussions by some leaders in the space here on SO & from a leading TypeScript author here.
Since we're using modules, which is the way the JavaScript world is going, we need a module loader. Plenty of options out there to address this from browserify to JSPM to Webpack. We're going with Webpack.
WHY? - The Angular team has elected to use webpack for Angular2, so we're following their lead. It also makes it very simple for consumers of the library as there is really nothing for them to do in this space... the generated combined & minified library will have everything it needs and consumers will simply need to reference the library.
As part of this change, I'm also going to work on adding the following:
These changes directly import those who are currently building directives (@rolandoldengarm @jigargandhi @waldekmastykarz @jjczopek)... please ensure you are respecting these changes to the ROE (rules of engagement ๐) before submitting a PR.
If you want to see an example of this in action, check out the changes to the textfield directive that @s-KaiNet did. Grab his fork (https://github.com/s-KaiNet/ng-officeuifabric), switch to the branch ExModules & look at the
/src/components/textfield/demoBasicUsage/index.html
to see how it works.The steps on your machine:
$ git clone https://github.com/s-KaiNet/ng-officeuifabric ngfabricchanges
$ cd ngfabricchanges
$ git checkout ExModules
$ npm install
$ tsd install -ros
$ tsc -p ./
$ gulp webpack
$ open src/components/textfield/demoBasicUsage/index.html
The following work items as part of this update:
choicefield
and textfield
from master
until they are using resolved stuffOfficial link to component description & demo: http://dev.office.com/fabric/components/dialog
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/callout
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Setup a build process to compile all directives => minified & unminified JavaScript library. This also needs to be published to the various package management systems such as:
Ideally this should be automated upon a tagged release.
Tasks:
Official link to component description & demo: http://dev.office.com/fabric/components/overlay
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/table
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/toggle
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Spinner is not aligned properly within the containing div - circles are placed outside the container box.
Additionally defining large spinner does not take effect - it's always rendered as small one.
Official link to component description & demo: http://dev.office.com/fabric/components/listitem
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Currently located in different spots for webpack, karma & build process. Need to centralize these in a single spot.
Extend table with support for sorting using the following specs:
uif-row-select-mode
attribute on the uif-table
directivetable.selectedItems
propertyuif-row-select-mode="none"
:
uif-table-row-select
directive doesn't do anythinguif-row-select-mode="single"
:
uif-table-row-select
directive in the header row doesn't do anythinguif-table-row-select
directive in regular rows has the same effect as clicking on the rowuif-row-select-mode="multiple"
:
allRowsSelected
property on the table scope to false
~~uif-table-row-select
directive in the header row selects all rowsuif-table-row-select
directive in the header row deselects all rowsOfficial link to component description & demo: http://dev.office.com/fabric/components/dropdown
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
--verbose
is specified--verbose
is specifiedAfter recent commit & project setup structure, docs need updating... specifically things related to code checking, how to get a dev machine setup, how to contribute, testing the project, project organization, etc... all needs to get updated.
In addition, we will shut down the wiki & move docs to the repo to make it easier for community contrib.
Model process after what the Angular Material guys have done. See https://github.com/angular/material/tree/master/docs
Official link to component description & demo: http://dev.office.com/fabric/components/breadcrumb
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Official link to component description & demo: http://dev.office.com/fabric/components/button
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Currently no coverage on core.ts
& components.ts
which is hurting coverage...
Might not be necessary as all they do is define & import modules... so need to add istanbul ignore comments. However I think current transpilation process from TypeScript => JavaScript strips all comments and thus, we'd lose all code coverage reporting so this would need to get resolved.
Seeking input... we had casually set a rule that any directive that created a custom attribute would have that attribute prefixed with our namespace uif-
. However I'm seeing a lot of inconsistency in the implementations.
For instance, on the icon you set the type of icon you want to use. That's done with:
<uif-icon uif-type="plus" />
But I see other components that aren't doing that like the textfield where you can say if you want to use the underlined style:
<uif-textfield label="this is the label" underlined />
When I look at Angular Material, they favor the latter approach (no prefix on attributes).
Before we ship our first release, I'd like to have some consistency set... and I'm happy to be the one to fix all existing directives & demos... not a hard thing for me to do before we ship. I just think we should have some consistency... either DON'T require it or require that it's only used for elements and not attributes.
Thoughts? I'm sort of in favor of the latter (no prefix), more concise, style.
inputBlur and inputFocus are not covered by unit tests.
Official link to component description & demo: http://dev.office.com/fabric/components/progressindicator
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
Question for everyone to weigh in... actually two...
Q1: Should each component be in it's own Angular module?
Today it looks like we're doing two... fabric.ui.components
is defined in core.ts
that is the root of the entire library, but we also have things like fabric.ui.components.choicefield
for each one.
IMHO,
fabric.ui.components
should be renamed toofficefabricui.core
& each component should be inofficefabricui.components.*
.
Q2: Should we publish the library as a single entity, or each component as it's own in addition to the single entity?
This goes hand-in-hand with the first question. Angular Material allows for either one... you can grab the entire thing (which injects all the other modules in to the root module that you inject into your app) or you can grab just the components you want, reference the JS files independently (or concat them on your own) and then manually inject only the modules you want rather than the main one.
IMHO, we should do exactly what Angular Material is doing. We'd have a single module
officeuifabric.components
that would inject allofficeuifabric.components.*
. This would allow someone to grab just one reference & get everything, or selectively grab what they want. We can then publish each component separately on bower the same way that Angular Material does it.FWIW, might be a little while until we give people the ability to split them out... for the short term & p1 goal, we just box it up in one package.
Official link to component description & demo: http://dev.office.com/fabric/components/peoplepicker
Screenshot of web analytics for the original http://officeuifabric.com site by @andrewconnell. Use this to see what are the most popular components: http://imgur.com/gallery/buUcyQv
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.