These are chat archives for jdubray/sam

17th
Mar 2016
Jean-Jacques Dubray
@jdubray
Mar 17 2016 03:31
Anyone has tried deku? https://github.com/dekujs/deku
Michael Solovyov
@msolovyov
Mar 17 2016 03:32
Yes, I like it
Had to setup babel and webpack to use it. But it makes view functions a lot cleaner
Jean-Jacques Dubray
@jdubray
Mar 17 2016 04:02
it looks like a good fit for SAM
iambumblehead
@iambumblehead
Mar 17 2016 06:35
@msolovyov do you have any thoughts on your experience with deku?
I have been using virtual-dom but it looks un-maintained
I need to look through the source to find answers to some questions which are undocumented
I've thought about using something else but am not sure what replacement is best
weepy
@weepy
Mar 17 2016 07:17
I think snabbdom is good
@jdubray how would you compare and contrast SAM with the Elm Architecture?
Jean-Jacques Dubray
@jdubray
Mar 17 2016 09:27

From what I understand, Elm is an MVI pattern like cycle. js or Redux.
MVI SAM
Intent -> Action
Model -> Model
_ -> State

I believe SAM offers a much better decoupling between the View and the Model (which was my original intent)

  • I prefer using Actions rather than pure intents like Redux. It is unlikely that a View triggered Intent will be structured to propose values readily to the model, at a minimum you need to do some basic validation and transformation. If you don't have a good place to factor that code, it will end up in the model. Actions should be reusable, across solutions (think about a submit address action), there is no reason for the model to understand what's the difference between a post address and a user defined address. All the model cares about is "the address".
  • on the other end of the pattern, State decouples the Model from the View. Again, there is no particular reason for the Model to understand how it will render in the View. the State() function interprets the property value to decide which components of the view needs to be rendered as well as any potential "next action" that needs to be taken.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 09:35
MVI patterns tend to move all this code inside the model creating a big ball of unmaintainable mud.
This is true of Redux which require that you add thunks and sagas when you need the same kind of decoupling as SAM.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 09:40

Actions -> Propose values to the model
Model -> Accept values (or not)
State -> "Learn" about these values and display state representation, and if any, triggers next-action

SAM offers a simple way to factor the code that generally people would put in the controller for MVC or in the model for MVI. SAM does not conflict with your favorite framework, but at the same time it greatly reduces the need for any framework.

weepy
@weepy
Mar 17 2016 09:48
Ok thanks. I'll think about that when I next look at the code
Gunar Gessner
@gunar
Mar 17 2016 13:05
Happy birthbday, @jdubray ! And thank you for all the shared knowledge :D
Tiago
@tiagocpontesp
Mar 17 2016 13:08
+1 ! :clap:
brusand
@brusand
Mar 17 2016 15:02
joyeux anniversaire Mister JJ, thx for sharing your knowledge. you are so clear that i feel more clever :)
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:09
:-)
Alex
@whitecolor
Mar 17 2016 15:23

Actions -> Propose values to the model
Model -> Accept values (or not)
State -> "Learn" about these values and display state representation, and if any, triggers next-action

Intents -> Propose values to the model
Model -> Accept values (or not)
View -> "Learn" about these values and display state representation, and if any, triggers next-action (intent)

What is the difference? There was assumption IMV !== MVI, but for me its just rotating leters in cycle.

You probably won't like Intents -> Propose values to the model well intents -> commands but it is too just words. I do not see there really "game changing" paradigm.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:25
the difference is major, as I mentioned,
  • Intents are anemic, this is not enough to "propose" value
  • the State() function logic will have to be moved in the view which is a poor factoring, it is better to separate the logic of displaying a component V = f(M) from the logic of which component needs to be displayed (computing the state representation)
Alex
@whitecolor
Mar 17 2016 15:28
well "propose" is your word
and "view" is too just word
it can be replaced with "state" nothing changes
intents could be replaced with "actions", but in my view action is more abstract (and maybe vague)
for example words like intent and command has more concrete meaning, but at the end of the day its just words
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:30
The question is code factoring, it is not because an intent proposes values that an intent can do what an action can do. Please refer to Redux thunks. Dan started with anemic intent, then he realized it was not working so he created a new concept instead of admitting that (anemic) intents are not enough.
this is not just "words" these are precise semantics that we establish a shared understanding
No intents are not actions, in any way shape or form
intent means intent ~ request for something to happen
action means action ~ performing something
Alex
@whitecolor
Mar 17 2016 15:31
Well I agree here about semantic, then you should give very solid defenition of this words Action Model State
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:32
this is not whatever we want it to mean
Alex
@whitecolor
Mar 17 2016 15:32
it is a connerstone of understanding SAM
in MVI I believe there was no clear intention to give a solid attributions to this words
and can be end up with MVA (mode-view-action)
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:33
well the meaning is in the pudding (code), you look at what an intent is and it is not an action
Alex
@whitecolor
Mar 17 2016 15:34
your acions is like commands in CQRS I believe
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:34
not quite, they are both queries and commands
queries have side effects with respect to the model... since after a "query" the model property values change
Alex
@whitecolor
Mar 17 2016 15:35
action means action ~ performing something
performing what?
change state?
Tiago
@tiagocpontesp
Mar 17 2016 15:39
i think only states change state (views), and actions don't perform model("state"?) changes -- only propose them. the validation of model changes is responsibility of the model itself
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:39
no actions do not perform model change that is the core of SAM
actions perform validation and transformations (including calling an API for instance to transform a user address into a postal address before it is presented to the model)
yes, the model has integrity rules that separate from actions.
Let's say you are a company doing business in many countries
you roll out a new product just in Canada
the action will validate that the address' country is canada
the model will not
conversely, you could have actions that do not validate the country, only the model validates the country
the key is to have the right place to put it... this is why I believe SAM is very important compared to everything else that I have seen
SAM separates the logic of "systems of engagement" from "systems of record", this is gold.
Tiago
@tiagocpontesp
Mar 17 2016 15:43
maybe some scaffolding, and an SCM npm module would get this going
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:47
I am really trying hard not to force people to use SCM (STAR component model), it's not fun to use State Machine semantics...
The scaffolding is SAFE. Did you see it?
Tiago
@tiagocpontesp
Mar 17 2016 15:47
not yet
later today :)
Jean-Jacques Dubray
@jdubray
Mar 17 2016 15:56
I really want to say that all the choices in SAM are not arbitrary, I didn't make up these semantics they come from TLA+ (what an action is, what the present method it, what the model is, what the next-action-predicate is)
There is no "intent" in TLA+
...
Tiago
@tiagocpontesp
Mar 17 2016 16:23
model.state = state ?, like the pc moniker?
Jean-Jacques Dubray
@jdubray
Mar 17 2016 16:25
sorry what do you mean by "pc moniker"?
I need to keep a reference somewhere...
Tiago
@tiagocpontesp
Mar 17 2016 16:26
you mentioned it from the TLA spec in your posts i think
so i guess my question is, you keep a reference to the active state/type (am i getting this right?).. in order to facilitate determining which state to change to next?
Jean-Jacques Dubray
@jdubray
Mar 17 2016 16:28
this is just a reference to the state function, everything is a pure function with respect to the model (it can have side effects but not on the model)
SAFE has a tiny bit of state to validate the allowed actions in a given (control) state.
pc in TLA+ refers to (control) state, i.e. the states of a state machine (S1, S2, S2...) where (S1, A, S2)...
Stardrive ENGG
@HighOnDrive
Mar 17 2016 16:33

@jdubray @whitecolor Straight from the Cycle docs here: http://cycle.js.org/model-view-intent.html

"MVI is an architecture, but in Cycle it is nothing else than simply a function decomposition of main().

In fact, MVI itself just naturally emerged from our refactoring of main() split into functions. This means Model, View, and Intent are not rigorous containers where you should place code. Instead, they are just a convenient way of organizing code, and are very cheap to create because they are simply functions. Whenever convenient, you should split a function if it becomes too large. Use MVI as a guide on how to organize code, but don’t confine your code within its limits if it doesn’t make sense.

This is what it means to say Cycle.js is sliceable. MVI is just one way of slicing main()."

MVI is just a basic slicing of main(), something to channel reactive flow in Cycle. It is good for simple apps but when there is something more going on with an app it begins to bulge and that is where a more meaningful pattern comes into play.

Of course the ultimate pattern still comes from the uniqueness of the app and it's purpose. With this in mind I use MVI as a first level pattern and then SAM as an overlay on that, as long as they do not interfere with what my app actually has to accomplish.

The other thing to note is "MVI itself just naturally emerged from our refactoring of main() split into functions". This implies that Cycle is focused on it's reactive flow and making something with it's operators and that after a while all that flow needed to get cleaned up a tad.

So no, not a whole lot of thought went into creating the best pattern in Cycle, just a nod to MVC and some spring cleanup of the code.

Jean-Jacques Dubray
@jdubray
Mar 17 2016 16:47
I agree that cycle.js provides a good way to implement SAM, but when I hear "intent", intents have very specific semantics in programming and intents are not actions. For me cycle.js is just wiring. Good wiring, but just wiring. This paragraph tends to confirm it. It's not about "naturally emerging", semantics don't "naturally emerge", just ask Leslie Lamport.
Stardrive ENGG
@HighOnDrive
Mar 17 2016 17:02
I agree intents and actions are very different stages. Also, believe that not intermingling stages is the way to go, so action functions for instance would be in a separate module and reusable across apps as required.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 17:57
I am not against intents but you have to be careful applying concepts just because, if you generate the view components as V = f(M), the wiring between the view and the actions does not require further decoupling.
The functional nature of Actions make is easy to create libraries that you can wire via adapters:
A(data) = ma( the_reusable_action( va(data) )) where ma() is the model adapter and va() the view adapter.
The are essential to land these API calls that enrich the view data or perform webhooks (unrelated to the model). Not quite sure why anyone would prefer intent over actions as a base concepts
Stardrive ENGG
@HighOnDrive
Mar 17 2016 20:14

@jdubray I like the abstraction of Intent and think it deserves a stage in the reactive flow. Why? Because modern client side apps deal with a lot of interaction. This interaction streams from common input devices like the mouse or extended event providers like digital pens and wearable sensors.

The Intent stage is the necessary and valid space where these providers and their events can be captured and processed to prepare them as inputs into actions.

Jean-Jacques Dubray
@jdubray
Mar 17 2016 20:16
always start with why, please articulate the problem intent solves in the programming model.
why do you need to capture and process intents? are we talking about the va() view adapter function? something else?
we have to stop bringging ideas into the programming model just because they look "cool" like thunks, sagas, reducers and I would argue intent have little place in the architecture.

to create a successful Front-End architecture, we have to follow Saint-Exupery's lead:

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

so far I can see that most frameworks I see focus on the wrong problems and clutter their architecture with a bunch of unnecessary wires. I'd argue that TLA+ on the contrary seems to have achieved a level of perfection rarely experienced in our industry.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 20:23
It is all about asking the hard question: why?
Stardrive ENGG
@HighOnDrive
Mar 17 2016 20:30
It's all about inputs and outputs, makes perfect sense. Surely TLA+'s perfection needs to align with the real world as well. I like boiling everything down to it's essence but not when it removes or ignores a fundamental part of modern event flows.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 20:35
To be brutally honest, that part of cycle.js makes no sense as all, the user is not "a function". The user has both application state and control states... no? We have to stop seeing everything as a nail when we have a hammer. Again Cycle.js offers some nice wiring (sorry nothing more) and the implications of generating the view as-a-function have not been carefully explored.
As soon as you write this:
function computer(inputDevices) {
  // define the behavior of `outputDevices` somehow
  return outputDevices;
}
you have left the real-world, IMHO
cycle.js focuses on "inter-actions" (one of my specialties as the editor of the ebBP specification), SAM focuses on the Model. All its semantics are centered on state mutation (before, during, after). Again, wiring is irrelevant, state mutation IS-THE real-world
Jean-Jacques Dubray
@jdubray
Mar 17 2016 20:42
I know a lot of people have invested a lot in Cycle.js and they might view SAM as a bit of a shock, it does not have to be that way, SAM does need some nice wiring which enables / supports cool architectures. SAM is neither prescriptive about the wiring nor the architecture.
I would argue that has been the problem that has plagued our industry that state mutation is viewed as a simple function call, perhaps, ever since the first bit of data was persisted.
You can't buy something more real world than TLA+ (IMHO).
Stardrive ENGG
@HighOnDrive
Mar 17 2016 20:48

This comes from a level above SAM. The user is indeed a function in that they dynamically interact with the computer and the app/computer is then the other function in the exchange. Cycle use to call this dialogue request and response, now it's known as source and sink.

I hear your frustration, face it we live in a world of several primary players. At its most basic I see the players as input > state > output. Cycle is such a WOW moment for seeing how interaction flows that it has just not had the time to work in the model to satisfaction yet. However, state is at the center of much Cycle discussion so it will find it's natural strata I'm sure.

Jean-Jacques Dubray
@jdubray
Mar 17 2016 20:52
well, my role is to say what I tried to say to Dan, don't reinvent the wheel, 99.99999% of the people can't play at the level of a Leslie Lamport. No offense to anyone.
Imagine, you would have to find semantics that beat his, what is the probability? A 20 year effort on his part.
I am actually shocked that Andre is not all over SAM, he could in one move (action) take React out. Ah I forgot, there is no action in Cycle.js :-) just intents...
Stardrive ENGG
@HighOnDrive
Mar 17 2016 20:59
@jdubray No, there are indeed actions, which are the result of intents, this is a common pattern in Cycle. I can see why Cycle kept the pattern hum low because there was much more to do in what is known as the functional reactive revolution.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 21:00
that is indeed a revolution
Stardrive ENGG
@HighOnDrive
Mar 17 2016 21:04
I once had the displeasure of having an older so called genius placed as the overlord on a project of mine. This "genius" had worked on missile defense and advanced radar systems but he knew dick all about modern front end development. He had to be removed from the project because it really just made him tear what little hair he still had out :smile:
Jean-Jacques Dubray
@jdubray
Mar 17 2016 21:08
I guess if people were less focused on "making up stuff" and using what true geniuses like Dr. Lamport are gifting to us, we would not have any of these discussions. But what do I know?
Stardrive ENGG
@HighOnDrive
Mar 17 2016 21:11
True art is working with the colors we got in the actual world :+1:
Tiago
@tiagocpontesp
Mar 17 2016 22:41
It is typically tough and inappreciative to uphold such a categorical imperative, so I find this effort noble.
Just a thumbs up.
Jean-Jacques Dubray
@jdubray
Mar 17 2016 22:50
Anyone knows how Cycle.js does with the security tests (https://files.gitter.im/jdubray/sam/6oXv/blob)
I cannot find any google results when I search for cycle.js xss or sec-a sec-b,...
Stardrive ENGG
@HighOnDrive
Mar 17 2016 22:56
@jdubray What was the context of that chart?
Jean-Jacques Dubray
@jdubray
Mar 17 2016 23:31
it was part of a presentation talking about the security of Web Frameworks. It looks like ng is the "safest", unfortunately there seems to be no data on cycle.js
I like cycle.js (don't get me wrong) but it would be hard for me to recommend it until there are some serious security data around it.
Stardrive ENGG
@HighOnDrive
Mar 17 2016 23:34
Cycle is the eye of the storm, just a bleep on the radar right now. It's paradigm along with Rx is going to reshape everything we know, along with SAM of course :smile:
well... both SAM and Cycle are pretty far from reshaping anything if you ask me. When you are facing FB and Google... I would not bet much on either.
If Rx is what would make it special, there is already Rx/ng
weepy
@weepy
Mar 17 2016 23:38
I liked the look of flyd as an alternative to rx
Stardrive ENGG
@HighOnDrive
Mar 17 2016 23:40

Well right off the cuff we know that Cycle takes side-effects very seriously and its whole architecture is based on keeping main() pure. Everything is modular and secure so there is not much more need for Cycle to speak to that.

On the other hand complicated monsters like Angular and React need to assure everyone that they are safe, when nothing could be further from the truth.

Maybe ask in the https://gitter.im/cyclejs/core room for further security details. Over all side-effects are contained so the security breach if any comes down to external APIs.

Jean-Jacques Dubray
@jdubray
Mar 17 2016 23:43
I did
@weepy I think I am going to develop some kind of JavaScript fever if I hear about another library I had never heard about before :-)
Stardrive ENGG
@HighOnDrive
Mar 17 2016 23:44
@jdubray I would not be surprised if the reactive paradigm will not keep being lead by Cycle and it's off shoots. React and Angular are monolithic monsters who will take on the role of serving basic web needs in the years to come, while Cycle and the reactive crew will boldly go and explore the new worlds. Don't say I did not tell you so ;-)
Jean-Jacques Dubray
@jdubray
Mar 17 2016 23:53
As with any discontinuity there is room to take on incumbents but you still need to reach critical mass. My goals is not to develop a framework, so I am not playing that game, Cycle is... Thinking that a dose of Rx and a couple of sinks will be enough to move the needle is at best naive. Disruption 101 says that you have to:
  • solve a problem for non consumers (e.g. SAM makes it really easy for devs with minimum dev skills like me to build Front-Ends they can be proud of) or
  • solve a problem significantly better than the incumbent(s) such that existing devs will have the incentive to not enter the Angular/React ecosystems for their new projects (migration at this point is not even thinkable)
    I don't see cycle doing either. That's Christensen 101, even React can't move the needle, granted that they got lost in their architecture.
Stardrive ENGG
@HighOnDrive
Mar 17 2016 23:58
@jdubray Unfortunately Cycle came after Angular and React already hooked everyone on their BS. See how fast Cycle has been growing on their gitter counter, most of these new devs coming over in droves are from React and Angular. The only thing that React and Angular are good for is job security for firms that have CEO's that don't know jack shit, they just follow the herd and step into the same dung over and over.