Make Feathers universal

[daffl]

This pull request adds a client side shim for Express, allowing to use Feathers in non-Node environments like the Browser and React Native to build fully universal applications with Feathers best practises like services and hooks. The Browserified build is around 8k minified and gzipped.

Also adds a .defaultService functionality. This will be needed when initializing non-existing services on the client which should then just connect to their configured endpoint as it is already done in feathers-client.

Closes #191

[ekryski]

@daffl can you spec out a quick example of how this would be used? Is it in conjunction with feathers-client or is it a replacement for now?

[daffl]

feathers-client would still exist (and also be backwards compatible) but just re-export the respective clients (feathers/client, feathers-socketio/client, feathers-primus/client and feathers-rest/client) to provide a non-CommonJS/NPM distributable.

Importing feathers directly only works with CommonJS compatible module loaders like Webpack, Browserify or Steal that use the browser field in package.json. With those it should now be possible to architect client side Feathers apps the same way as on the server though:

import feathers from 'feathers';
import socketio from 'feathers-socketio';
import hooks from 'feathers-hooks';
import localStorage from 'feathers-localstorage';
import React from 'react';

const app = feathers()
  .configure(socketio('http://chat.feathersjs.com'))
  .configure(hooks())
  // You can register your own services to manage application state
  .use('/store', localStorage('storage'));

// Add hooks e.g. for client-side validation
app.service('messages').before({
  create(hook, next) {
    if(typeof hook.data.message !== 'string') {
      return next(new Error('A message needs to be provided'));
    }
    next();
  }
});

class TodoList extends React.Component {
  componentDidMount() {
    app.service('messages').find().then(messages => 
      this.setState({ messages }));
  }

  render() {
    if(!this.state.messages) {
      return <div>Loading...</div>;
    }

    return <ul>{this.state.messages.map(message => <li>{message.text}</li>)}</ul>;
  }
}

To use the client in Node you'd import feathers from 'feathers/client', import socketio from 'feathers-socketio/client' etc.

[ekryski]

Man this looks awesome!! You'll probably do the same thing in react native: import feathers from 'feathers/client'.

Let's merge this sucker. I want to play!! 😄

On another note, you didn't write feathers-localstorage yet did you?

[daffl]

Not yet. It was just an idea and as an example that you could use services and other Feathers best practises to also manage application state on the client. Working on migrating the REST, SocketIO and Primus clients now.

[ahdinosaur]

wow this is great @daffl, really keen to play around with this, thanks. :)

[daffl]

@ahdinosaur Thanks for bringing that up! It definitely turned out even better than I expected. Everything should be released now in feathers 2.0.0-pre.1 and 1.1.0 in the feathers-rest, feathers-socketio and feathers-primus modules. If you and/or @ekryski want to take it for a spin, please let me know if you are seeing any issues (I'm hoping I got the browser field right but there wasn't an easy way to test it).

[ekryski]

Yay! I'll check it out today! I guess this means that we now no longer need https://github.com/feathersjs/feathers-client.

[daffl]

We still need a non CommonJS/NPM build. The question is if they should be provided as distributables in their respective repos or consolidated in feathers-client as a dist that includes all the provider clients and probably hooks.

The first option makes it a little annoying to get set up in a non CommonJS/NPM environment because you'll have to include a whole bunch of dependencies manually. Namespacing is also trickier than having the feathers-client module that simply does something like

// src/client.js
import feathers from 'feathers/client'
import socketio from 'feathers-socketio/client';
import primus from 'feathers-primus/client';
import rest from 'feathers-rest/client';
import hooks from 'feathers-hooks';

Object.assign(feathers, { socketio, primus, rest, hooks });

export default feathers;

And then Browserifies that as an UMD module or a global feathers variable. That way we also won't break any existing feathers-client users too badly. Depending on how it goes I think we can definitely think about deprecating the client in v3.

[ekryski]

@daffl Ya I'm for option 2: feathers-client just being a simple wrapper for all the feathers libs. It will make it easier if we need to make any modifications to it (or create a separate client) for React Native.