make feature organization (i.e. directory collections) less type-based

Merge pull request #11 from KevinAst/next5

make feature organization (i.e. directory collections) less type-based

After the refined features of 1/24/2019

THIS TAG INCLUDES ALL OF THE FOLLOWING:

1. now have an official services layer!

   • greatly simplifies multiple actions/logic transitions INTO an
     service encapsulation
     ... ex: expose User in service, greatly simplifying auth feature

   • mockable: via a very kool feature-u use-contract "enforcer" mechanism

2. introduced featureFlags (util/featureFlags.js)

3. introduce a much improved error handler

   • Error polyfill:

     • allowing errors to be qualified as expected/unexpected and
       user-context scrubbing

   • Error reporting:

     • discloseErr() using central toasts/alerts
     • minimizes need for "fail" action and logic reasoning

   • to see example, enable AuthServiceMock (via featureFlags.useWIFI: true)

     • password: unexpect ... for unexpected error
     • password: expect ... for expected error (like invalid credentials)

4. device initialization is now accomplished through a "bootstrap"
   feature

   • now simply a use-contracts

   • see:

     • features/init/device ... the client
     • features/support/bootstrap ... the bootstrap process

   • greatly simplifies multiple actions/logic transitions

     • employing long-running logic modules
     • bypassing traditional "spread-out" redux process actions:
       fail/complete etc
     • makes logic much more concise and self-contained

     see: device feature before/after

5. misc changes

   • re-organized features into grouping directories (a personal
     preference)

   • FINALLY: made features/ directory plural

   • inline smaller resources directly into feature.js (a personal preference)

     • fassets
     • application life cycle hooks

   • KEY: simplify fasset resource names by replacing the "base feature
     qualifier" with a self explanatory name

     • external usage should not be aware which feature a resource came from
     • in general, this refactor simplifies the reference, making it's usage more intuitive
     • NOTE: we still retain base qualifiers such as actions/sel/etc.
     • Example (from eateries feature):
       • OLD: fassets.eateries.actions.remove(eateryId)
       • NEW: fassets.actions.removeEatery(eateryId)

   • KEY: refactor variables that are internal to a feature
     (featureName/actions/selectors) to be more explicit and
     self-explanatory (containing feature name)

     • Example (from eateries feature):
       • featureName: _eateries
       • actions: _eateriesAct
       • selectors: _eateriesSel

   • restructured diagnostics outside of production code (see app.js)

     • FROM: app.js
     • TO: util/configureEateryNodDiagnostics.js

   • consistently utilize a feature.js in ALL features

     • with index.js alias

6. ASK JEFF

   • should I minimize all the index.js floating around
     • both in
       • the index.js redirect to feature.js (allowing imports of the dir)
       • and the chain of index.js down a directory path (vs. just
         import all from features/ dir)

Before the refined features of 1/24/2019

This is the image just prior to the refined features of 1/24/2019.

Please refer to the "refinedFeatures_after" tag to see what was improved!

After feature-u V1 (using fassets) ... final production package

Final rendition using feature-u V1 production package

LeftNav uses withFassets() for everything (production and sandbox - making it totally modular)

After feature-u V1 (using fassets)

LeftNav uses withFassets() for everything (production and sandbox - making it totally modular)

After feature-u V1 (using fassets)

LeftNav uses withFassets() BUT only for sandbox (production use is yet todo)

Before feature-u V1 (using publicFace)

fuV1Before

upgrade to Expo SDK 27.0.0 FROM 24.0.0

eatery-nod WITH extendable features

• feature-u packaged separately (i.e. src/util/feature-u IS GONE)

eatery-nod WITH extendable features

eatery-nod WITH extendable features

• feature-u embedded in eatery-nod ... src/util/feature-u

eatery-nod WITH NON extendable features

eatery-nod WITH NON extendable features

• feature-u embedded in eatery-nod ... src/util/feature-u