These are chat archives for jdubray/sam

5th
Mar 2018
Fred Daoud
@foxdonut
Mar 05 2018 01:00
@devinivy redux alternatives are a dime a dozen and most of them are "meh" to me, but immer actually looks useful
Jean-Jacques Dubray
@jdubray
Mar 05 2018 01:05
@victornoel I was brushing up on ngrx this afternoon and the part that I don't like about observables is that they couple the view with the model or even the state representation. I prefer "push/publish" semantics. That would enable building reusable components.
that's what I am talking about:
constructor(private store: Store<AppState>) {
    this.freelancers = Rx.Observable.combineLatest(store.select('freelancers'), store.select('filter'), this.applyFilter);
  }
Jean-Jacques Dubray
@jdubray
Mar 05 2018 02:43
Could there be some unwanted coupling for force you to relax DRY? https://twitter.com/AdamRackis/status/970477018306539520
Paolo Furini
@pfurini
Mar 05 2018 08:24
@jdubray That's not exactly what I call coupling.. the actual store dependency is injected into the constructor, and from that point on you simply agree on a defined interface, being it an object path, a named subscription, or a typed message on a queue
What's important is documenting it well if the component should be used again by the future you or colleagues
Paolo Furini
@pfurini
Mar 05 2018 08:29
What's really bother me is the lack of proper typing in typical JavaScript. That's the main problem in reusing such a component. Using typescript I'm able to use the code, and not a disconnected HTML file, to document the definition of the message types supported by the component. The fact that these messages come from a queue or an observable doesn't matter to me
Victor Noël
@victornoel
Mar 05 2018 08:29
of course if the store's observable is publishing the model itself, yes, you have coupling that is unwanted in SAM. But you don't need to use the store for storing the model
Paolo Furini
@pfurini
Mar 05 2018 08:31
We are already agreeing in publishing the state and not the model. @jdubray was referring to the explicit named select over the store
Victor Noël
@victornoel
Mar 05 2018 08:32
also @jdubray, I'm going to nitpick, but please stop confusing observables with ngrx: observables is a term from the RX paradigm, which is implemented in js/ts via rxjs and that you actually use in your angular/SAM example
@pfurini I agree with you, I'm just not sure @jdubray wasn't complaining about the fact that in the example he looked at of ngrx, there was only one thing: a state/model (confused) in a store
Paolo Furini
@pfurini
Mar 05 2018 08:33
But that could be parametrized for example, to be able to change the path where the payload is retrieved. That's the same as using a filter expression to retrieve a message from a queue, you can hardcore the filter, or parametrize it
Victor Noël
@victornoel
Mar 05 2018 08:33
exactly
the only interest I have in things like ngrx is for them to simplify my life and not reimplement by hand something like this: https://github.com/jdubray/sam-samples/blob/master/angular4-Bootstrap4-SB-Admin-master/src/app/state/state.ts
Jean-Jacques Dubray
@jdubray
Mar 05 2018 10:27
@victornoel Unlike my earlier comments, I understand the difference between the two kinds of observables (including MobX too). It's basically a pub/sub model And yes, they could be parameterized. I just don't like using the semsntics of snow assignment for what is essentially message passing. As we have seen conflating mutations wiith assignments is not ideal, now we are conflating assignments with messages. That's a but too "cool" for my taste.
@devinivy could we go again through the rationale of using immutability to manage mutations? Especially in the context of temporality? Special points if we can talk about the size of models/application state vs the size of any given view for any application other than Facebook, Instagram or Twitter.
Victor Noël
@victornoel
Mar 05 2018 10:44
@jdubray thx for the clarification :)
question: is that acceptable to access the model from the actions?
(for example to detect something has already been retrieved before)
Victor Noël
@victornoel
Mar 05 2018 11:03
or should I have two actions: one to say I need some data and the other to actually retrieve this data (and the second would be triggered by NAP if the data is not here)
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:03
No from a temporal oersoevtive it is not, it also creates all kinds of concurrency problem. The state representation is what you want to use.
Victor Noël
@victornoel
Mar 05 2018 11:05
ok, so the actions can look at the state representation directly, or should the component that wants to trigger an action only do so if the state representation is not to their liking?
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:05
It's better to use cashing and present the cashed results. Otherwise you can create all kinds of corner cases.
Victor Noël
@victornoel
Mar 05 2018 11:06
I don't understand what you mean
let me give a proper example of what I'm doing :)
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:07
I prefer to pass the parts of the state representation that I will need in the action to the view components. Concurrency is going to be a problem otherwise
Victor Noël
@victornoel
Mar 05 2018 11:08
so the view component knows the state needed by the action, it gives it to the action and it is the action that decides to do something or not, right?
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:09
Yes, that's how I resolve the case when I need to access the model in the action.
Victor Noël
@victornoel
Mar 05 2018 11:09
ok, cool, makes sense in my case
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:10
From a temporal perspective it's cleaner because the action is triggered with respect to that state representation, which could be way different than the current state representation.
Victor Noël
@victornoel
Mar 05 2018 11:15
but then doesn't it meant that in this particular example, we are liable to execute an action twice while you wanted to do it only once, only because the state passed to the action was outdated?
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:16
I would say that in general, software engineers tend to stereotype any bit of semantics they use. For instance stereotyping an assignment into a pub/sub is not ideal. When your app is small, sure it looks cool but before you know it you'll be struggling with the granularity of your assignments. It you are disciplined they will be exactly equal to messages, but the temptation to use properties will be too high, and now you sent uncontrolled messages each time you make an assignment
@victornoel again, the best way (temporally) is to maintain a proper cache. It is wrong temporally to think that an action can be "skipped" in a generic way like this.
Do not stereotype a cache for state representation. If you do, do it clearly by passing a state representation that details what the current state is and what the action needs to do.
Victor Noël
@victornoel
Mar 05 2018 11:21
Here is my use case: I have a view component that shows a list of items, those items are known by the backend and never change. Currently I have: the view component, based on the state, show the list of items (or nothing if they were not retrieved) and trigger the action "retrieveItems". The actions "retrieveItems" queries teh backend and present the items to the model. The model update the state with this information. which is used by theview component to show the list of items.
From there you say I should give the current state from the view component to the "retrieveItems" action and the action will decide not to do the query if it's not needed.
Do we agree on that? and where a cache would be in that current example?
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:22
Yes, it's preferable.
The cache would be at the API call level, you can wrap API calls in a small caching engine, mapping query strings to resuts.
You will hit corner cases on both sides otherwise. You may, at some point decide the data needs to be refreshed, in which case you just change the cache (believe me you don't want to do that in the model).
Victor Noël
@victornoel
Mar 05 2018 11:25
oh, API cache, ok, I understand what you mean now
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:29
From what I can see in practice, sooner or later you always pay the price of breaking the temporal relationship of SAM building blocks. You should never ask the question: how should I go around it, rather, how can I achieve a particular outcome while staying temporally correct. The answer is often easy to find.
But I know we were trained otherwise. OOP, FP, RP have no temporality.
Jean-Jacques Dubray
@jdubray
Mar 05 2018 11:43
We were also trained (eg MVC) to think that an action can orchestrate the response to an event, that's not the case.
Paolo Furini
@pfurini
Mar 05 2018 11:50

The model update the state with this information. which is used by theview component to show the list of items.

One clarification, so to see we're on the same page.. In the case I have several views, encapsulated in several Angular components, that need to consume the same model, what's the best approach:

  1. do not reuse models, because we should have 1 model <-> 1 state representation (state function) <-> 1 view (angular component)
  2. we can and should reuse models, so we can have 1 model <-> N state representations (state functions) <-[tied with]-> N views (angular components)
In my mind, it's always been 2., because I tend to associate models to the concept of business models, but maybe that's not correct from the POV of a frontend UI architecture
Victor Noël
@victornoel
Mar 05 2018 11:55
I would have gone for 2 too, because the model (in my case at least) represents a single truth related to the backend, so it makes no sense to have multiple time the same data in the model
Paolo Furini
@pfurini
Mar 05 2018 11:57
so in that case we should always decouple the model from the state representation processors (I don't like the term "functions", too restrictive to me)
Victor Noël
@victornoel
Mar 05 2018 11:57
I think that's actually one important point of decorellating the model from the state: so that for one given data in the model, you can have various state representations (and thus views) for it.
hmmm, in a way, isn't the role of the model to compute the state ? but it makes sense to have code in the model pertaining to producing the state while there is code pertaining to mutating the model
hmm, don't listen to me, of course the state is separated from the model in terms of code
Paolo Furini
@pfurini
Mar 05 2018 12:04
the single responsibility of the model is to accept changes and mutate its encapsulated data in a consistent manner, reasoning about acceptable mutations in a given state, so every code that actually "mutates" data should be isolated in the model code
that's why we could "query" data in the actions, but never mutate it
but computing state representation could and should be factored away the model code, but placed next to it. That is, state processors are aware of the model they are connected with, but they are actually separated so that I could have N processors that, based on the same mutated model data, are able to compute N different state representations
that's what I've done in my own SAM samples, and what I've understood of the overall architecture..
Paolo Furini
@pfurini
Mar 05 2018 12:10
how to connect the moving pieces is implementation specific IMHO, but message queues (or call it Pub/Sub) are the more straightforward way to do it (again in my opinion)
what bothers me is message ordering.. I prefer solutions that guarantees ordered delivery of messages to subsribers
Jean-Jacques Dubray
@jdubray
Mar 05 2018 12:13
Yes I would go with 2 as well, I believe the distinction between model and state is profound. In particular because it allows for multiple state representations, and also because it favors message passing semantics over observables.
Message ordering is rarelyan issue in front-end architecture.
Paolo Furini
@pfurini
Mar 05 2018 12:15

Message ordering is rarelyan issue in front-end architecture.

yeah, but maybe it could be with Web Assemblies in the future, with real multi threading code.. but that's something I didn't study yet

Jean-Jacques Dubray
@jdubray
Mar 05 2018 12:15
Now, just to be clear, and that's why we have approches like MobX or ngrx observables, change detection is not trivial, nor do I believe it can be trivialized.
The bakery algorithm makes it rather simple to create a critical section, which then would help in sending these messages in an orderly fashion.
Paolo Furini
@pfurini
Mar 05 2018 12:17

Now, just to be clear, and that's why we have approches like MobX or ngrx observables, change detection is not trivial, nor do I believe it can be trivialized.

that's true.. but if we use message passing exclusively in all of our UI code, it becomes like a reactive UI, so change detection becomes useless

I mean, if every UI change is driven by messages, a change should only be the result of a new message arrived
Paolo Furini
@pfurini
Mar 05 2018 12:23

The bakery algorithm makes it rather simple to create a critical section, which then would help in sending these messages in an orderly fashion.

true, but only if the queue implementation guarantees ordered delivery by design.. they can just use internal optimisations, or store data, in a way that can potentially re-order the messages

Jean-Jacques Dubray
@jdubray
Mar 05 2018 12:29
In any case, because of SAM temporal structure and the model critical section every state representation can be stamped with a step counter value.
Paolo Furini
@pfurini
Mar 05 2018 12:30
then, I should say that glueing everything together with a message oriented architecture, can cause some headaches in the future, especially for very big projects.. I experimented this in a WPF project where I refused to use classic MVVM approach, and tried to decoupling everything via Pub/Sub.. too many disconnected pieces that had to be documented more than simple declared interfaces (code documents itself, messages should be documented outside)

In any case, because of SAM temporal structure and the model critical section every state representation can be stamped with a step counter value.

yes, that could be used to re-order on arrival

Jean-Jacques Dubray
@jdubray
Mar 05 2018 12:38
That's why I prefer functional HTML! No pub/sub
Paolo Furini
@pfurini
Mar 05 2018 12:44

That's why I prefer functional HTML! No pub/sub

I can't agree more on this, but if you have to use angular there's no better choice as of today

Jean-Jacques Dubray
@jdubray
Mar 05 2018 12:44
Yes
Paolo Furini
@pfurini
Mar 05 2018 12:45
I wonder if we could hack the NG core to support a reactive rendering pattern
Jean-Jacques Dubray
@jdubray
Mar 05 2018 13:11
Back in 2016 I had built some PoC code based on dynamic templates, but I don't think it's the right approach. The solution seems to be closer to lit-html.
Victor Noël
@victornoel
Mar 05 2018 13:26
@jdubray another question of the same type as with the cache question: let's say I have a component that shows a list of item, this list comes from the backend but is filtered based on some criteria. I have another component to express this criteria. so currently what I have is: the filter component triggers an action to set the current criteria: it is directly presented to the model and maybe given to the state if needed. the list component triggers an action to retrieve the items: it does a query to the backend, but it needs the criteria to do so. How would you implement that?
Janne Siera
@jannesiera
Mar 05 2018 13:27
Just took a look at immer
It is very similar to what vuex is doing
But cognitively I like the concept of a 'draft'
Paolo Furini
@pfurini
Mar 05 2018 13:39
@victornoel I think the flow isn't correct.. filtering by a criteria becomes part of the requirements, so becomes part of the model
Paolo Furini
@pfurini
Mar 05 2018 13:47
so when the user changes the filter, the filter component presents the new filter payload to the model, and the model should trigger a retrieveItems NAP to retrieve fresh data based on the filter (or filter the items already in cache, but that's require more thinking), and then this NAP will present the fetched items to the model, and finally the model will present the updated items to every state processors (functions) that in the end will update your list component and every other connected component
Jean-Jacques Dubray
@jdubray
Mar 05 2018 13:53
Yes, correct. View Components should never have any other responsibility than emitting events and listening for new state representations.
@jannesiera could you please explain how a draft relates to mutation and temporal logic?
Victor Noël
@victornoel
Mar 05 2018 13:56
@pfurini so for the NAP to know that the retrieveItems should be triggered (with the filter as a parameter), it must know that the list component wants to show it, because I don't want to retrieve it for nothing, the filter is used for other things too... so does it mean that I should have some kind of flag in the model to know if the view component is actually present (the flag would be set to true if the view component has trigerred an event to notify the model of that…). That seems a bit complex
Jean-Jacques Dubray
@jdubray
Mar 05 2018 14:04
@victornoel you need to let go the "component" view of the world. How does this flow really works? You set a filter, the action that recieves that event should also be responsible for fetching the data. That action is not coupled to the set filter component. View components emit events and wait for props. Your application logic is 100% decoupled from the view.
In sngular it's a bit harder to shift because you'll need a component method to handle the event.
All you have to do is call the action in that handler with a proposal containing the new filter value.
Then the model accepts the results and a message is dispatched to the other component with the new data.
Victor Noël
@victornoel
Mar 05 2018 14:14
so you mean I shouln't try to have the filter to be stored in the model/state? my problem is that the filter is used for many things that are not shown at the same time (you could say there is a header with the filter and multiple pages which depends on the filter). From what you say it seems that I should handle the state of the filter from outside of SAM…
Paolo Furini
@pfurini
Mar 05 2018 14:18
@victornoel it's really up to you, there is not a single way to abstract a model, and so there isn't a single way to implement a data flow.. like @jdubray said, you could for example take the filter parameter in action, which in turn retrieves the filtered data, and presents it to the model, throwing away the filtering information. This flow is ok if the only side-effect in setting a new filter is to actually filter the data
but if, for example, there is another part of the application that really "needs" the filter itself, then the filter should become part of the model (as a contrived example: a status bar that should display the current applied filter)

From what you say it seems that I should handle the state of the filter from outside of SAM…

that's not what he said.. he said that you could use the filter only as a parameter for an action, and used only by that action to perform a query and present the results to the model

Victor Noël
@victornoel
Mar 05 2018 14:24
ok, thx for taking the time to explain :) it makes sense
Paolo Furini
@pfurini
Mar 05 2018 14:30
just to add my 2c.. to me the filter expression SHOULD be part of the model anyway, because it's the "core" data for the filter view. If you'd like to recover the current state of the UI, for example by serializing and then de-serializing it, you'll not be able to recover the state of the filter view because of the lack of its data in the model
Jean-Jacques Dubray
@jdubray
Mar 05 2018 14:30
:+1:
Paolo Furini
@pfurini
Mar 05 2018 14:35
I think it's beneficial to always think in terms "given the current model, can I successfully rebuild a functional UI in the current state?".. I always try to make everything recoverable, 'cause that means I have built on the right abstractions
(and I'm not talking about time-travel stuff and things like that, I'm only stating that a model should always be self-sufficient for the "current" state of a UI)
Jean-Jacques Dubray
@jdubray
Mar 05 2018 14:43
Yes, that was the paradigm shift that changed everything for me.
Fred Daoud
@foxdonut
Mar 05 2018 14:47
@pfurini no but you could still get the time-travel stuff as a bonus ;)
Paolo Furini
@pfurini
Mar 05 2018 14:50
@foxdonut yes. but that implies you're storing the history somewhere else, if that's for debugging purposes and it can be opted out then it's ok
Fred Daoud
@foxdonut
Mar 05 2018 14:51
:thumbsup:
Paolo Furini
@pfurini
Mar 05 2018 15:00
also, time travel is subtle if used improperly. It's based on the assumption that you live in a side-effect free world. That is, if every external call you make is idempotent, then it basically works always. On the other hand, if you try to apply it on less-than-trivial cases where you call several APIs with unpredictable side-effects, it can't work, period.
If you use it with mocked APIs, or 100% APIs that are themselves baked with a temporal logic, then it could work. But, apart from mocked APIs, I don't know of real-world APIs that support the concept of replay-ability
so in the end, time travel is a fun toy, but not that useful in complex scenarios
devin ivy
@devinivy
Mar 05 2018 15:04
it's useful for sharing bugs with friends :)
Paolo Furini
@pfurini
Mar 05 2018 15:09
yeah, in the end it's a great "debug visualizer".. if you know what it is for, it's useful and harmless, but I wonder if everyone knows its scope, and not try to abuse it
Fred Daoud
@foxdonut
Mar 05 2018 15:11
@pfurini but if you do a series of interactions with your UI which has side effects (calling the server etc.), then you travel back and forth in time, it shows you the view for snapshots of the model, it does not replay the side effects..
of course if you delete item 42 and time-travel back to where item 42 was still on the screen, and you click on Delete again... :boom: but that's expected.
Paolo Furini
@pfurini
Mar 05 2018 15:15
@foxdonut I'm not sure how it could work in SAM.. the view is not connected directly to the model, like in other approaches, and in that relies the strength of the architecture itself
Fred Daoud
@foxdonut
Mar 05 2018 15:15
@pfurini state representation then, which is derived from the model
Victor Noël
@victornoel
Mar 05 2018 15:16
in the implementation I'm doing, I'm using ngrx only for the state, so travelling should only show the difference between the view changes, but would not impact API calls and stuffs
Fred Daoud
@foxdonut
Mar 05 2018 15:16
it's no different from derived/computed properties, that is not really unique to SAM
Paolo Furini
@pfurini
Mar 05 2018 15:16
yes, because you're time-travelling the state representation, not the model
devin ivy
@devinivy
Mar 05 2018 15:17
there are a lot of ways to slice it— replay side-effectful actions, replay proposals, replay model changes, replay state representation changes
they're all a tad different! it depends what you're trying to do.
Fred Daoud
@foxdonut
Mar 05 2018 15:17
agreed! @devinivy
Paolo Furini
@pfurini
Mar 05 2018 15:20
but again, that could work only if you rely exclusively on observables to capture a change in the state representation store
devin ivy
@devinivy
Mar 05 2018 15:20
if you're doing any of these as a part of your application—not just for debugging—i've found that replaying actions is the safest. and perhaps that's what you're getting at @pfurini . for example, if i want a user to be "remembered", i find it best to "play" a login action when the app starts rather than rehydrate the model directly from a past state.
Paolo Furini
@pfurini
Mar 05 2018 15:20
switching to message passing, time travel is not possible
@devinivy yes, that becomes a necessity and not an option if I opt out completely from observables
in that case I need someone to put a message that says "logged state is changed, redraw"
but it's more complex and expensive to do, that's why for simple apps and for starters, observables are more simple to use
Paolo Furini
@pfurini
Mar 05 2018 15:34
a question: VueX has a time-travel debugging tool? I haven't looked deeply in such time-travel tools, and given that vuex is aligned to SAM (if I remember correctly), I'm curious to see how they tackled the problem
Jean-Jacques Dubray
@jdubray
Mar 05 2018 15:39
@pfurini time travel works with SAM as well: https://www.youtube.com/watch?v=o7ZIG4jT0xM
@pfurini that being said, I believe too that pub/sub makes it harder, if not impossible to time travel.
Paolo Furini
@pfurini
Mar 05 2018 15:44

that being said, I believe too that pub/sub makes it harder, if not impossible to time travel.

that's my fear.. regarding your time-travel example, is it possible to implement it purely on client-side?

Jean-Jacques Dubray
@jdubray
Mar 05 2018 15:48
Yes, of course, it just makes more sense to implement it on the server, IMHO. SAM is 100% isomorphic.
Paolo Furini
@pfurini
Mar 05 2018 15:55
yes but these are at two different levels.. with SAFE you're travelling through model mutations, while on the client you want to travel state representations, and "mock" the resulting view changes
I'm trying to figure out how this could be accomplished in angular, where we have more constraints at play
Jean-Jacques Dubray
@jdubray
Mar 05 2018 16:05
Yes, correct. I guess you could just replay the messages (pub/sub). Caveat there can be multiple messages per step.
Paolo Furini
@pfurini
Mar 05 2018 16:06
so that's a POC of an undo/redo plugin for vuex, and it's straightforward to implement.. if we capture in a similar way the messages that are published, by the way of an interceptor, it doesn't matter how many messages per step we have, because we simply capture them all
Janne Siera
@jannesiera
Mar 05 2018 16:09
@jdubray If your takeaway of TLA+ is comparing primed and unprimed variables to check if a certain mutation (ergo the next state) is allowed then a draft can be an interesting concept. By looking at the immer github page they explain a draft as the following: the current state gets copied to a draft, the draft gets mutated, the draft gets copied again to function as the new state. In this scenario you could do your mutations on the draft and then have some invariants check if your draft is valid, if it is you accept it as the new state, if it is not valid you simply reject it.
Paolo Furini
@pfurini
Mar 05 2018 16:10
if the interceptor is transparent (and it should be), like a Vue plugin is, we could setup it in a debug environment, and simply avoid it in a production bundle
Paolo Furini
@pfurini
Mar 05 2018 16:16
if our messages are typed, or tagged, properly (as I always do), we can filter out and capture only the "state representation update" messages, and replay only them.. if we have a chain of NAPs, that's not a problem, because we're not registering the "action" messages, but only the state ones, and all of them, in order. The only problem is that the "undo" will undo at a lower granularity level, the one of single NAPs, and not at a "step" level as a whole
by doing this there is no problem with side-effects, because we're always recording the output (state mutations) of every side effect, and never the actions
then, like in the vue plugin above, we should invalidate the undo queue whenever we intercept a new action message on the queue
Paolo Furini
@pfurini
Mar 05 2018 16:24
so yes, in the end I like even more the message based approach over the observables.. it's more aligned to a reactive pattern, where you swap out function calls with message passing (anyone old enough to remember smalltalk?)
Jean-Jacques Dubray
@jdubray
Mar 05 2018 16:33
@jannesiera yes, that what I was talking about. I am not sure TLA+ talks about anything else.
Primed and unprimed.
Victor Noël
@victornoel
Mar 05 2018 17:52
OK! Today I've finally done my first real world SAM implementation in angular :) it's not excellent, but it's a good start I think. I already feel some stuffs are cleaner.
Unfortunately is proprietary code, but here how it is currently: I used ngrx for the state only (for the record: a store to which you send events that triggers an update of its interanl state via functional reducers and you can watch the state in view components with observables). The actions an object with a set of methods (they sometimes takes some data as input) and do most of the time some query and present the results to the model. The model is an object with a set of methods that triggers some event towards the state store as well as trigger new actions if needed (NAP). For now I haven't had the need to actually store any data in the model, it is quite empty except already for some NAP, but the datastructure manipulated in the model and sent to the state via events is different from the datastructure exposed by the state (derived data for examples are computed in the reducers).
Thanks for your help today, I will be back with more questions I'm sure :)
Jean-Jacques Dubray
@jdubray
Mar 05 2018 17:56
:+1:
I think the fact that your model is rather empty (only keeps track of internal state, as opposed to visible state) is due to the reactive nature of the store.
Jean-Jacques Dubray
@jdubray
Mar 05 2018 18:11
@victornoel it would be different if you move the mutations in the model and only use message structures in the store/state and observe these "messages". I think over time that decoupling model/mutation vs state/notification could prove healthier.
Victor Noël
@victornoel
Mar 05 2018 18:14
It is clear that the whole temporal and mutation aspects of SAM is a bit non-present in my current code… I wonder how it will look after I move the whole app to SAM ! I will certainly have to revisit some of the choices I made…
got to go, thx again @jdubray and @pfurini for the feedbacks!
That's a long response to several complaints (like mine in flutter repo) about why dart over typescript or plain ES6.. I'm impressed on dart strengths, I admit I didn't know a fraction of its power
If flutter could adhere to SAM architecture, I think it could become part of my future arsenal
Paolo Furini
@pfurini
Mar 05 2018 23:30
What's really interesting is that dart can be both AOT compiled and JIT compiled.. so compiled down to machine code in production, and interpreted during development