Use microstates library i.e. a new API

[knownasilya]

WIP, don't merge yet!
Resolves #68

This change removes all of the helpers for a (currently) single HoC state-for component which takes a type class and a value to create a microstate using the default middleware.

I removed all of the tests and update to the latest cli and ember versions. This change will require a major version bump because it fundamentally changes this addon.

New API

Component API

class MyApp {
  counter = Number
}

<StateFor @type={{MyApp}} @value={{value}} @onchange={{action (mut value)}} as |app|>
  {{app.state.counter}}
  <button type='button' onclick={{action app.counter.increment}}>+1</button>
</StateFor>

Service API

// services/current-user.js
import Service from '@ember/service';
import { Store, create } from 'microstates';

class User {
  name = String;
  email = String;
  superuser = Boolean;

  get isFilled() {
    return this.name && this.email;
  }

  get notFilled() {
    return !this.isFilled;
  }
}

const value = {
  superuser: false
};

export default Service.extend({
  init() {
    this._super(...arguments);
    const initial = create(User, value);
    this.set('microstate', Store(initial, (next) => {
      // set the internal state of the component to the next state
      this.set('microstate', next);
    }));
  }
});

Using

import Component from '@ember/component';
import { inject as service } from '@ember/service';
import { alias } from '@ember/object/computed';

export default Component.extend({
  currentUserService: service('current-user'),
  user: alias('currentUserService.microstate'),

  actions: {
    // pretend 'save' action
    save() {
      let userMicrostate = this.user;
      let value = userMicrostate.valueOf();

      alert(JSON.stringify(value));
    }
  }
});

Template

<form {{action 'save' on='submit'}}>
  <input type='text' placeholder='Name' oninput={{action user.name.set value='target.value'}}>
  <input type='text' placeholder='Email' oninput={{action user.email.set value='target.value'}}>
  <label>
    Is an admin?
    <input type='checkbox' checked={{user.superuser.state}} onchange={{action user.superuser.toggle}}>
  </label>
  <button disabled={{user.state.notFilled}}>Submit</button>
</form>

TODO

• Update to released version of microstates since we us a hash version which needs to be built locally atm Release fully packaged umd to npm thefrontside/microstates#134
• Resolve needing IE11 in targets Supporting real classes thefrontside/microstates#136 Ability to build from dependency's src directory embroider-build/ember-auto-import#32
• Using with default action helper, currently we write our own invoke helper Auto binding transitions thefrontside/microstates#135
• Tests
• API Docs
• Allowing custom middleware
• Organizing types/default values maybe in a special subclassed service? Or maybe something like https://github.com/stefanpenner/ember-state-services
• More?

Trying it out

• Clone and npm install
• Enter node_modules/microstates and npm install.
• In ember-microstates main dir run npm start.
• Open localhost:4200

[taras]

With this kind of service, for now it might be better to use service actions instead of the invoke function. This was the approach that Charles and I planned for until the Applicatives wrapper is ready.

What do you think?

[knownasilya]

I'm for that as well, it's a little used pattern that should be used more.

// services/current-user.js
export default Service.extend({
  typeClass: User,

  defaultValue() {
    return {
      superuser: false
    };
  },

  actions: {
    setName(name) {
      this.microstate.name.set(name);
    },

    setEmail(email) {
      this.microstate.email.set(email);
    },

    toggleSuperuser() {
      this.microstate.superuser.toggle();
    }
  }
});

<form {{action 'save' on='submit'}}>
  <input type='text' placeholder='Name' oninput={{action 'setName' value='target.value' target=currentUserService}}>
  <input type='text' placeholder='Email' oninput={{action 'setEmail' value='target.value' target=currentUserService}}>
  <label>
    Is an admin?
    <input type='checkbox' checked={{user.superuser.state}} onchange={{action 'toggleSuperuser' value='target.checked' target=currentUserService}}>
  </label>
  <button>Submit</button>
</form>

[knownasilya]

The only issue is that it might be repetitive especially if you are nesting many classes for the "schema".
Also it won't be very clear if you should nest or create a new service with a disconnected microstate.

[cowboyd]

Why not create an implicit action for each custom transition of the microstate?

[taras]

@cowboyd would they be recursive like the microstate?

I don't think it's possible for actions hash to be a computed property. Right?

[knownasilya]

Unsure, probably not supported. But you can use functions outside of the actions hash as actions, e.g.

// services/current-user.js
export default Service.extend({
  typeClass: User,

  defaultValue() {
    return {
      superuser: false
    };
  },

  init() {
    this._super(...arguments);
    this.toggleSuperuser = this.microstate.superuser.toggle.bind(this.microstate.superuser);
  }
});

<button type='button' onclick={{action userService.toggleSuperuser}}>
  Toggle Super User
</button>

The above would work if the method was bound before hand (example twiddle).

[knownasilya]

👍

[taras]

@knownasilya ember-auto-import 0.2.6 made it work without the explicit import using es module build. This is sweet!

[knownasilya]

You'd still want this value='target.checked' since otherwise you get an event and that is set. I think..

[taras]

toggle doesn't take any arguments. Event will be ignored.

[knownasilya]

@cowboyd or @taras could one of you restart the tests? Trying to figure out if that was a fluke or not.

[knownasilya]

Never mind, I updated and the error seems to have gone. Adding some basic acceptance tests.

[knownasilya]

Closing in favor of #72