+1 this sounds amazing Wilson, been waiting for this day! Especially the idea of using a live guide. Would be great if we can have a process in place that ensures it always stays update to date. IMO The change to the workflow would be worth it to stay aligned.
Eric > On 4 Nov 2015, at 14:56, Wilson Page <[email protected]> wrote: > > The following is an initial strategy, along with some insight behind our > thinking. > > RENAMING TO FXOS-* > > We will be renaming the Github organisation 'gaia-components' -> > 'fxos-components' along with namespaces for each component (eg. <gaia-header> > -> <fxos-header>). > > This is to improve transparency and solidify our message. Many people have > heard of FirefoxOS, but not 'Gaia'. Let's tear-down these confusing barriers > to contribution/understanding and align our vocabulary. > > PLATFORM STABILITY > > We've been using web-components in production across FirefoxOS for over a > year in various places: > <gaia-header> (all apps) > <gaia-dialog> (spark apps) > <gaia-switch> (spark apps) > <gaia-toast> (system app) > Vertical homescreen > New homescreen > All Music NGA UI > Other stuff I've forgotten :) > This has given us confidence that what we have in the platform right now is > fast and reliable enough for production. > > Shadow DOM V1 (the latest spec all vendors agree on) has shipped in Chrome > and WebKit Nightly. We're currently working on our implementation. Word from > DOM team is, that once complete, they too will be happy to ship. I have been > given a *ballpark* estimate of Q1 2016. > > All vendors have not yet agreed on the intricacies of Custom Elements. They > will be meeting in Dec/Jan for a face-to-face to present proposals and iron > our the remaining kinks of a more ES6 centric design. > > In Gaia we're using Google's initial specification which we haven't preffed > on by default yet. Third-parties are able to use this API (and Shadow DOM V0) > by using the "moz-extremely-unstable-and-will-change-webcomponents" > permission in their app manifest. > > Imagining optimistically by May 2016 we'll have Shadow DOM V1 preffed on, > third-parties will be able to use our fxos-components in Gecko by either > using the above pref, or a custom-elements polyfill > <https://github.com/WebReflection/document-register-element> (currently used > by the Google AMP project). > > For the time being we have confidence that the current implementation is > sufficient for our internal needs. New Shadow DOM and Custom Element APIs > will land parallel alongside the old, before being deprecated, giving us > ample time to upgrade. We have also abstracted core APIs behind our > gaia-component <https://github.com/gaia-components/gaia-component>wrapper, > which reduces the number of code changes required to migrate if/when platform > changes. > > SEPARATE REPOS > > Component will continue to live in their own repos on Github under the newly > named 'fxos-components' organisation. Each repo will contain source-code, > live demo(s), tests and documentation. > > PACKAGE MANAGEMENT > > After much discussion both on mailing lists and person to person, we have > decided to make the following changes to how we manage external components in > Gaia. > > We will move from Bower to NPM3. NPM has become the package manager of choice > for the majority, with NPM3, comes with several nice front-end features > <http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging> (some > borrowed from Bower). > > Due to the reasons I outlined in this thread, > <https://groups.google.com/d/msg/mozilla.dev.fxos/-Gou264FGa8/gAAnE7GSAAAJ> > components will be installed locally to each app referenced within a > `package.json` at the app root. This adds a small amount of learning/friction > to our workflow, but brings stability to our process (similar to writing > tests). > > Today external dependencies are checked-in to the Gaia tree. This avoid > complexities with install, version mismatches, build systems and dependency > on third-party servers. The downside is that it adds weight to the tree and > noisy diffs. We'll be sticking to this approach unless more attractive > options come to light. > > 'LIVE' STYLE GUIDE > > We will build a single style-guide index page that will link to each > component's individual gh-page demo. This will act as an index of the > components that we deem 'production ready' and will be Gaia devs' go-to > catalogue. > > The style-guide will link to each demo, which is turn will link to source > Github repo with code, documentation, tests and issues. Incorporating a > 'readiness' checklist within README, following on from the hard work Fred > did, <https://wiki.mozilla.org/Gaia/Shared/Components> would quickly > highlight stability and feature gaps. > > I'd also love to have visual/UX specs checked in alongside source-code as a > proof implementation matches specs, but this may require significant changes > to visual/UX workflow. > > FOSTERING CONTRIBUTION > > Many of these changes are an attempt to lower the barrier to entry for > contribution to FirefoxOS. Having components separated from Gaia increases > discoverability and sends the message that these components can be used > stand-alone. > > The scope of 'required understanding for first commit' is shrunk dramatically > when contributors have less code to look at. Using common tools and patterns > of the community, we're doing open-source in a familiar/approachable way to > others. > > --- > > Let's stop duplicate efforts, save engineering time, give designers a > fast/reliable upgrade channel and overall increase quality. > > If you're as excited by this as me, we're looking for help to make this a > success. Ping me if you have questions, suggestions or time to lend. > > Peace :) > > W I L S O N P A G E > > Front-end Developer > Firefox OS (Gaia) > London Office > > Twitter: @wilsonpage > IRC: wilsonpage > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
