These are chat archives for jdubray/sam

25th
Jul 2016
devin ivy
@devinivy
Jul 25 2016 12:33
@jdubray are you familiar with relay at all? i see they call their actions "mutations" so i wondered if they had similar semantics to SAM's proposals.
Jean-Jacques Dubray
@jdubray
Jul 25 2016 12:43
No, I stopped at GraphQL. To be frank, I think I have developed a severe allergy to any kind of framework. They all come with opinionated semantics that are generally not worth the tradeoff. I am fighting ng2 subscriptions right now. Looks like their could learn a trick or two from MobX.
Edward Mulraney
@edmulraney
Jul 25 2016 12:44
I'm using Apollo which I think is similar to relay. In Apollo, the mutation relates to server request which is akin to POST/PUT. They use a single state tree with references (by id) to pieces of model state, so a mutation response overwrites the previous model property state, like a regular assignment or redux reducer, rather than using PAL semantics.
Jean-Jacques Dubray
@jdubray
Jul 25 2016 12:46

All I can say is that in ng2

this.ref.detectChanges() ;

is your best friend ...

Edward Mulraney
@edmulraney
Jul 25 2016 12:57
What are you comparing with ng2 vs GraphQL ?
Jean-Jacques Dubray
@jdubray
Jul 25 2016 13:00
no, just talking about frameworks in general (@#$&(*#)
Edward Mulraney
@edmulraney
Jul 25 2016 13:04
how come you're working so hard on ng2 integrations? just to attract angular devs to the pattern?
Jean-Jacques Dubray
@jdubray
Jul 25 2016 13:13
I work with enterprise clients, angular and especially (migrating to) angular2 what I have been asked to demonstrate.
Google manages Angular in a way that's quite reassuring for enterprise customers. When Facebook clearly states that they are developing React for their own needs, that's not the kind of message an enterprise customer wants to hear. They are used to software vendors who follow the market needs.
Here is my first take on converting a large ng2 application to the SAM pattern. It's easy and incremental, you don't have to convert the entire app before you start seeing the benefits.
I will also use this sample to answer larger questions about structuring a large project with the SAM pattern (model + state).
Edward Mulraney
@edmulraney
Jul 25 2016 13:24
I'll have a loot at that tonight. Makes sense to target enterprise
Jean-Jacques Dubray
@jdubray
Jul 25 2016 13:26

From the README file of the project:
This is work in progress, so currently, only the following components have been converted to use the SAM pattern:

  • /app/pages/dashboard/feed/feed.component

The SAM pattern elements (actions, state, model) are instantiated from the SamFactory (/app/services/sam.service) in the app.component

  • The Actions are mounted in a global variable actionsMount (index.html). This global variable is visible from a component when you use the following statement:
    declare var actionsMount: any;

There are better ways to achieve the same result (such as creating a dispatcher service) which I am currently exploring.

  • The Model (as a single state tree) can be found in /app/model/model. It's structure will be refined as I make progree in converting the template to a full SAM implementation.

  • The State Representation function is implemented in /app/state/app.state. At present, the components subsbscribe to changes to the State Representation. For instance the feed component's subscription looks like this:

    this._state.subscribe('dashboard.feed', (feed) => {
          this._feed = feed;
          this.ref.detectChanges() ;
        });

When the State function detects an update to the state representation related to that subscription, it notifies its subscribers:

this._onEvent({event:'dashboard.feed',data:model.feed});

As a result, the view component's callback simply refreshes the component's properties.

That being said, you can see from the original template's implementation that developers are encouraged to call APIs directly from components. So far I have seen angular devs asking me what's wrong with that? People don't see how bad a coupling it is until you explain it to them.
Fred Daoud
@foxdonut
Jul 25 2016 13:57
@jdubray looking at your mobx example, it seems to me that it is similar to the difference in pattern that I noticed when comparing, in Meiosis, virtual dom views (React, Snabbdom, Mithril) vs reactive template views (Vue, Riot). Meaning, with the vdom views, the reactive loop is to return a new view from the model, and let the vdom library refresh the UI. With the reactive templates, the reactive loop is to just update the model, and let the library update the view. MobX seems to be the "in-between" layer that makes any view become reactive by updating the model.
Personally though I don't like the idea of tying the model to a library, i.e. having to wrap models with observable() or add @observable and @computed annotations everywhere.
Jean-Jacques Dubray
@jdubray
Jul 25 2016 14:08
@foxdonut yes, I think that's a great way to look at it. It's a very interesting question too, what's better? a rigid state representation/view relation or a more flexible one where you logically create a new view each time from scratch and let an algorithm (such as vdom) to optimize the display of that view.
I'll have to play with container components to see it's just a perceived rigidity or a real one.
Fred Daoud
@foxdonut
Jul 25 2016 14:15
@jdubray great, I'll be interested in hearing about your thoughts on container components.