These are chat archives for jdubray/sam

28th
Aug 2017
Paolo Furini
@pfurini
Aug 28 2017 10:32
@jannesiera so which template language do you end up using? Are you precompiling templates as part of npm/webpack/gulp script/pipeline?
Janne Siera
@jannesiera
Aug 28 2017 11:40
@pfurini we're not using any of this at the company. I just wrote a compiler to compile handlebars to incremental DOM as we are using handlebars already. Those would be compiled with gulp and bundled with Web Components.
But you're probably more interested in something like this: https://github.com/google/incremental-dom/blob/master/ECOSYSTEM.md
If you're interested in using webcomponents this way, also check out SkateJS
Fred Daoud
@foxdonut
Aug 28 2017 13:54
All, I will be presenting Meiosis at Web Unleashed in Toronto, the conference is Sept. 25-56, if you are there let me know, it would be cool to meet :)
Also, you can add code SPEAKER to save 20%.
Vertex21
@Vertex21
Aug 28 2017 14:45
@foxdonut Funny you mentioned InfernoJS.. I was just looking at that last Wednesday! It does look pretty good.
Jean-Jacques Dubray
@jdubray
Aug 28 2017 14:46
is it still alive, I thought the main contributor was hired by Facebook
Vertex21
@Vertex21
Aug 28 2017 15:05
There were changes to the repo in Github 5 days ago and Inferno tweeted Dec 26th that there was no need to worry as active development was going to continue.. so it looks like they're trying to keep it alive! Who knows how long that will last.. lol
Vertex21
@Vertex21
Aug 28 2017 15:12
@jdubray what are your thoughts on MobX?
devin ivy
@devinivy
Aug 28 2017 15:15
observers aside, i think mobx-state-tree is the best option out there for a multi-purpose store. i.e. if you want one store to power multiple interfaces.
i expect it was inspired somewhat by cerebral-state-tree, and took those ideas to the next level.
Vertex21
@Vertex21
Aug 28 2017 15:17
What exactly is a store?
Like a controller?
devin ivy
@devinivy
Aug 28 2017 15:19
i mean store in the sense of "a container for state"
a place to put application state
Vertex21
@Vertex21
Aug 28 2017 15:20
ok gotcha.. thanks!
devin ivy
@devinivy
Aug 28 2017 15:20
:thumbsup:
Janne Siera
@jannesiera
Aug 28 2017 15:32
Store = Single State Tree (where each implementation might have different properties for mutability, observing changes, etc)?
Jean-Jacques Dubray
@jdubray
Aug 28 2017 16:02
the coupling action mutation in MobX State Tree is horrific, non starter for me.
devin ivy
@devinivy
Aug 28 2017 16:03
i disagree there– i think you're getting caught-up in the examples. they aren't explicitly coupled!
the examples don't reflect that though
Jean-Jacques Dubray
@jdubray
Aug 28 2017 16:05
It's ok, we can disagree, happy to be proven wrong, but even Michel seems to be pushing that model.
devin ivy
@devinivy
Aug 28 2017 16:06
i see that the terminology implies exactly what you're saying
but really you could just rename their actions() to mutations() and live a happy life
what i mean is the library itself is fine
there's no reason actions need to be part of your state tree at all, so it's not a practical issue for me as a user to use their API to define mutations
Jean-Jacques Dubray
@jdubray
Aug 28 2017 16:08
well not quite... it's very important to run across the entire set of mutations/acceptors. MobX Programming model is "execute a single -action-"
I know people find my "present" method quite funny because of the way it introspects the proposal, but I view it as an essential part of the pattern, decoupling action/mutation is critical.
I wish I could be smart enough to find a better implementation, but just like the TLA+ "next-state" function, you need to run over all the acceptors, otherwise, you are pretty much stuck in the traditional "event handler" model
Jean-Jacques Dubray
@jdubray
Aug 28 2017 16:15
SAM acceptors are different in nature from "computables" because of the implications on mutation
In other words the mutation(s) depend on the shape of the proposal, I am not sure I can express that as a set of computables
Janne Siera
@jannesiera
Aug 28 2017 16:59
@jdubray what does the decoupling of the Action and Mutation achieve exactly?
Jean-Jacques Dubray
@jdubray
Aug 28 2017 17:09
This is really about reusing acceptors based on the proposal's structure, otherwise you are back into a standard event handler, just like in the case of MobX, you start thinking I call "X" and I expect a number of things to happen in response to calling "X"
the way acceptors are structured is they respond to a particular structure of the proposal, so you can "compose" acceptors in a very loosely coupled way. I propose { x, y} and many acceptors can respond to that proposal, I don't know exactly which ones or how many (I know it's scarry), but that's how I interpret the mutation process from the next-state function.
devin ivy
@devinivy
Aug 28 2017 17:13
i appreciate what you're saying– you may need to perform multiple mutations atomically.
yes?
Jean-Jacques Dubray
@jdubray
Aug 28 2017 17:13
yes,
the coupling would be too strong if the action had to know about which atomic mutations/acceptors are triggered. That's supports a very healthy (and easy to reason about) maintenance workflow
devin ivy
@devinivy
Aug 28 2017 17:14
add this to the list of things one might need to use SAM with redux– batching "actions." of course there already is fairly popular middleware for this.
Jean-Jacques Dubray
@jdubray
Aug 28 2017 17:16
I don't doubt all of this can be done in the React/Redux framework, I am only concerned by the lack of guidance in that community, I just don't like "recipe" based approaches. I prefer to understand first principles and then decide whether I want to optimize or not. The "basic" React/Redux approach does not seem to be based on first principles.
The React community would be much better off it everyone took a breath and discussed that first principle level
For instance, if MobX is a first principle of React, so be it. Today all these libraries/guidance contribute to a fragmentation of the React community, I am not sure it does itself a good service, not that Facebook cares a bit about guiding that community. They are busy building their stuff, they get some value/ideas from the community but IMHO, they are not leading that community in any way.
Jean-Jacques Dubray
@jdubray
Aug 28 2017 17:22
The recent licensing story even seems to indicate that they just flipped the bird on it.
Vertex21
@Vertex21
Aug 28 2017 18:06
@jdubray Motorcycle.js looks interesting! I haven't heard anything about the Most.js library it works with.. Do you have any experience with it?
Jean-Jacques Dubray
@jdubray
Aug 28 2017 18:21
no, no experince, nor do I plan to touch it.
Vertex21
@Vertex21
Aug 28 2017 18:22
Is it not usable in the SAM model?
Fred Daoud
@foxdonut
Aug 28 2017 18:26
@Vertex21 just be aware that motorcycle.js has merged with cycle.js, I believe -- search for motorcycle on this page
Vertex21
@Vertex21
Aug 28 2017 18:53
I know that the creator of motorcycle.js was working with cycle.js early on but it seemed to me that he broke off and created motorcycle.js as a separate entity.
Vertex21
@Vertex21
Aug 28 2017 18:59
@foxdonut the date of your referenced article is 2016-06-27 and the date of the interview on survivejs.com that @jdubray posted is 2017-08-18.. and the motorcycle.js github page is currently being updated as early as today.. so I'm not sure what's going on.. lol.. it seems almost like cycle.js just took some components from the motorcycle.js project and incorporated them.. motorcycle.js still looks like it's moving forward as it's own framework though.
Vertex21
@Vertex21
Aug 28 2017 19:08
It seems counter-productive to be going forward with both of those projects though when they're obviously so closely related..
Jean-Jacques Dubray
@jdubray
Aug 28 2017 19:15
@Vertex21 maybe it's just part of my limitations, but I have trouble implementing SAM in a pure reactive environment. I am not a big fan of Reactive programming (a la more.js). I get the value (e.g. Excel) and where it can be used, I just like to be in control of mutations, but I again, I'd be the first one to admit that's just part of my limited intellect.
or lack thereof
Fred Daoud
@foxdonut
Aug 28 2017 19:54
@Vertex21 I was under the impression that they had merged, but clearly I'm mistaken. Sorry for the misinformation!
Personally I dislike (motor)cycle.js because your model gets lost in a maze of stream operators. Also, the way to handle events with CSS selectors is clumsy. Ajax requests and responses are awkward; you issue a request and then get all responses back and have to filter through to find the response you're interested in.
Jean-Jacques Dubray
@jdubray
Aug 28 2017 20:06
:+1:

For me the top 3 priorities of a frawework should be:

  • robust application state management/mutation
  • ability to weave API calls as easily as possible
  • render moder UX effortlessly/efficiently

I understand people may have different priorities, in different contexts, but in IT, that's pretty much all you need

Reactive programming does not seem to add much value in any of these categories
Nivani
@Nivani
Aug 28 2017 20:18
Wouldn't recalculating state representation after model mutation fall under reactive programming?
Jean-Jacques Dubray
@jdubray
Aug 28 2017 20:21
It's one possibility of many, it is "reactive" for sure in a broad sense, but for me recalculating the state representation is functional. I don't need more than that. Again, happy to admit my limitations, and @foxdonut feel free to elaborate.
Fred Daoud
@foxdonut
Aug 28 2017 20:30
@jdubray I agree and perhaps along the same lines I would say that I value being in control of the model and not have its management be tied to a framework's API. This is why I would hesitate to use MobX or Cerebral, for example.
devin ivy
@devinivy
Aug 28 2017 20:33
@foxdonut i think that's interesting, as i have the same value but think about it a bit differently.
i would be open to working with mobx-state-tree, for example, because it would bridge the gap across the frameworks that a store might need to provide state to.
i'm more interested in creating view-agnostic state containers
Fred Daoud
@foxdonut
Aug 28 2017 20:35
@devinivy hehe, I would choose Cerebral over MobX myself :D
devin ivy
@devinivy
Aug 28 2017 20:36
try creating one state container for both polymer (highly mutable and observer-oriented) and also react (relies heavily on immutability)
Fred Daoud
@foxdonut
Aug 28 2017 20:36
But I hear you about view-agnostic state containers, that's certainly one of my goals with Meiosis. Choosing a vdom lib involves a one-line change.
devin ivy
@devinivy
Aug 28 2017 20:36
mobx-state-tree excites me because it can flush a description of changes (works with mutable-oriented frameworks) or apply the changes immutably.
Fred Daoud
@foxdonut
Aug 28 2017 20:37
Does polymer have a way to have a render(view) function?
devin ivy
@devinivy
Aug 28 2017 20:37
sort of– you can control when you flush changes to a component, which is what causes it to update.
i think we'll learn a lot more soon, with polymer v3.
cerebral-state-tree is very cool but doesn't flush changes with as much detail, last i checked
that's the library that originally got me thinking about what a proper store might look like, to sit on top of both react and polymer (just as an example, since they're so different)
Fred Daoud
@foxdonut
Aug 28 2017 20:46
@devinivy interesting :thumbsup:
Janne Siera
@jannesiera
Aug 28 2017 21:08
@foxdonut check SkateJS for functional web components. You might enjoy talking with the author about vdom and polymer as well. He's on the skatejs gitter as well.
devin ivy
@devinivy
Aug 28 2017 21:10
@jannesiera thanks! yes, skate looks very interesting :) i'm sure it would fit into @foxdonut's meiosis more naturally than polymer
it seems like an ideal application of incremental-dom
Fred Daoud
@foxdonut
Aug 28 2017 22:43
@jannesiera cool!