A big +1 from me, this can't come soon enough! --Chris
On 4 November 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
