These are chat archives for jdubray/sam

27th
Jul 2016
Vincent Jo
@chiwoojo
Jul 27 2016 00:53
Hey JJ, thanks for your thoughts on thoughts on this. So I remember that you said last time that for inputting search keywords and filtering results, it isn't too bad to keep logic in the component. Are you saying here that it would be better to keep proposing to the model every time the input is updated? And what about filtering? I remember filtering might be too heavy for the model, but it seems like there might be some benefits to do the filtering and keep the filtered list in the model. Thanks.
Vincent Jo
@chiwoojo
Jul 27 2016 01:33
also, I was wondering if saving something in the model (I just want to save some data from the input component that I processed) puts the app in an unknown state but does not affect the DOM thus leaving the page unchanged, am I making a mistake with my architecture or is that acceptable?
Jean-Jacques Dubray
@jdubray
Jul 27 2016 02:55
@chiwoojo Actually, I said that filtering/sorting could be done in the component, it can be viewed as a reponsibility of the display, rather than considered the filtered result as part of the application state. The filtering criteria should most likely be part of the application state. There is no hard rule, so if it makes more sense to do in the model (because you can represent the same data in different components), then you can do it in the model too. If each component has its own filtered view, then it's better to do it in the view rather than keeping it in the model.
No there is nothing that says that events should results in visible application state changes. However, if you have a next-action, you have to change the application state otherwise you'd go in an infinite loop.
SAM is really about building view components that publish events (to a dispatcher, not a subscriber) and recieving a new set of properties in return. The new set of properties can generate the view in a V =f(M/props) fashion or the properties can treat the property as observables and render when they change.
Jean-Jacques Dubray
@jdubray
Jul 27 2016 12:25
I continued working on the ng2 sample. I converted all the Dashboard components to a SAM implementation.
I resulted creating an action composition mechanism to create a single proposal from multiple actions:
/**
         * The compose method aggregates the proposals of multiple actions and presents it as a unit of work to the model. The composer uses an "accumulator" to combine the action proposals.
         * @param {array} events - the array of events to compose
         * @param {function} present - an optional present method, if undefined, the composer will use the default present method
         */
        compose (events: any[], present?: (data: any) => void) {
            if (events.length>0) {
                let self = this;
                let accumulate = this.accumulator();
                events.forEach( (event) => self.dispatch(event, accumulate));
                present = present || _present ;
                accumulate( {}, present) ;
            }
        },

        /**
         *  
         */
        accumulator() {
            let accumulator = {}
            return function (data: any, present?: (data: any) => void) {
                var props: string[] = Object.getOwnPropertyNames(data) ;
                    props.forEach( function(prop) {
                        accumulator[prop] = data[prop] ;
                    });
                if (present) {
                    present(accumulator);
                }
            }
        },
Overall, this is quite exciting, I like ng2 more and more despite the weight of the framework.
Fred Daoud
@foxdonut
Jul 27 2016 12:39
@jdubray nice to hear. I have to say that I am surprised, shocked even, that you like ng2. Especially since it uses RxJS. Given that we have similar opinions about frameworks, I'm interested in, what exactly do you like about ng2? What does it do for you that you couldn't do yourself, or with a lighter, simpler library?
Jean-Jacques Dubray
@jdubray
Jul 27 2016 13:27
me too...
The use of RxJS is very limited. I would not even qualify it as Reactive, this is more pub/sub, between the state representation and the view component.
I guess I like the DI architecture. It makes large apps more manageable.
Fred Daoud
@foxdonut
Jul 27 2016 13:56
Wow, ok. DI is what I dislike the most about Angular... I'd rather just use regular modules and functions.
Edward Mulraney
@edmulraney
Jul 27 2016 14:13
I'm with you @foxdonut
Vincent Jo
@chiwoojo
Jul 27 2016 15:20
Thanks JJ for your thoughts on the model/component ideas