These are chat archives for jdubray/sam

15th
Nov 2017
Fred Daoud
@foxdonut
Nov 15 2017 18:07
interesting, @formido
Jean-Jacques Dubray
@jdubray
Nov 15 2017 18:38
:+1:
devin ivy
@devinivy
Nov 15 2017 18:44
@formido i've been wanting something like this for a while– excited to dig into it!
@jdubray so cool. glad people are spending time on this in academia.
Jean-Jacques Dubray
@jdubray
Nov 15 2017 20:16
@devinivy agreed, very helpful to be able to put some formalism around this debate. From what I see the author even touches on FSMs in GUI.
Michael Terry
@formido
Nov 15 2017 21:41
I enjoy these UI/state management problems
there's also the flux challenge and this https://github.com/slorber/scalable-frontend-with-elm-or-redux
Antanas A.
@antanas-arvasevicius
Nov 15 2017 21:50
I
Jean-Jacques Dubray
@jdubray
Nov 15 2017 22:27
Yet another Template Literal Library: https://github.com/yallajs/yalla
@formido yes, there is a lot of attention now on dissecting them.
Jean-Jacques Dubray
@jdubray
Nov 15 2017 22:41
image.png
Eugen makes an interesting point, encapsulation/global state is irrelevant to mutability. I am shocked!
That is short of heresy
devin ivy
@devinivy
Nov 15 2017 22:49

@jdubray

Eugen makes an interesting point, encapsulation/global state is irrelevant to mutability. I am shocked!

is that how you interpreted the screenshot of text above?

Paolo Furini
@pfurini
Nov 15 2017 23:21
I'm currently against central store patterns, if not implemented as a hierarchical tree of encapsulated stores. Every application component, down to UI components, must maintain own state, or we are simply giving away decades of advances in architecting maintainable software
devin ivy
@devinivy
Nov 15 2017 23:31
i think as long as it is not so hard to hoist state higher when the time comes.
meiosis has a good take on this!
what's more important than there being a single store
is that there's a single source of truth for any given piece of state
Paolo Furini
@pfurini
Nov 15 2017 23:32
How to maintain micro state is a component's business, and potentially each component can make different decisions, as far as it adheres to its purpose and public interface. If using a SAM driver in a component (say an atomic UI component, like a tree, but the same goes for a business component, like a portlet in a dashboard) there must be some published state that can be consumed, and some intents that can be called.. in the end that's not so different than properties/methods, the difference lies in the glue and culture around it
The central state as a single source of truth is nothing else than nosql like store maintained in the browser's memory. I see nothing special around it.. if one wants to build really reusable components must write them to be completely independent. The fact they store their state tree as a subtree in a giant json object makes not so much difference to me