Extract events manipulation to Fluxo.Radio

[sobrinho]

Does not makes sense to the stores have the events implementation on itself, it is a specialized feature that can be external.

[sobrinho]

This is a working in progress, I will make some comments on the code.

[samuelsimoes]

About privatize the radio: :ok_hand:

About the callback binding: well, I don't know, if we remove the bindings at all, will the "computer functions" be called without context, like this:

class Person extends ObjectStore {
  static computed = {
    fullName: ["change:firstName", "change:lastName"]
  };

  fullName (store) {
    return `${store.data.firstName} ${store.data.lastName}`;
  }
}

If so, I think that it's counterintuitive, since that it's a class method.

[sobrinho]

I believe that binding is not a responsibility of Radio, it should not know who is using it.

Also, ObjectStore#registerComputed already binds the method to the instance before attaching it to the radio, so it will work as expected.

[sobrinho]

@samuelsimoes code review, pls.

After this pull request, I have some proposals to make but they are related to Radio, we have to close this one first.

[samuelsimoes]

Great, I was thinking that you will invoke the computed properties callbacks without context like my example above, but if it not changes, no problem for me.

[sobrinho]

Okay, I will merge it and start to refactor the radio itself.