These are chat archives for jdubray/sam

Apr 2016
Jean-Jacques Dubray
Apr 22 2016 00:10
The concepts of "partial updates" or "change summary" has been around for a couple decades. Again I was the co-author of the Service Data Object specification, Microsoft had also come up with the DataSet concept. If these solutions were general enough, beleive me everyone would be using them, the problem is and will alway be the business logic.
Jean-Jacques Dubray
Apr 22 2016 00:30

@HighOnDrive we are in a situation where a) we start with the wrong factoring of the business logic and b) a bunch of people create libraries to make it less painful to adopt the wrong factoring... Sorry, I just don't see the light. I'd rather start with the correct factoring and use as few libraries/frameworks as I can. The flow to mutate application state is clear, there is no reason to warp it because you want to use the concept du jour:

  • event/intent is emitted
  • action validates and enrichs intents, propose values to the model
  • model accept value, persist the accepted values (which could present new values to the model)
  • whoever needs to "learn" about the mutation is notified
  • next-action-predicate is evaluated and action is triggered if necessary

I don't need any library to implement that flow. In some rare cases I may need a virtual-dom library in case my UI is very large and updates are very small (but in most cases this is way overkill)

IMHO when people use a library they are often (not always) trading a small gain for years of pain, this is however always true for MVC frameworks.
Stardrive ENGG
Apr 22 2016 01:19
I agree with you more and more as I'm working through my implementation :+1:
Jean-Jacques Dubray
Apr 22 2016 01:21
Again, I am not trying trash cycle.js, this is really good work, but you have to build your code/framework around the constraints of state mutation, not the other way around.
Stardrive ENGG
Apr 22 2016 01:24
Right, creating my own framework layer that can optionally sit on adapter components of any swappable framework :sparkles:
Stardrive ENGG
Apr 22 2016 11:16

The highlight of CycleConf are these slides, posting them here then sleeping for a bit. Nice to see state take it's rightful place in Cycle, even though most Cyclists don't care to see it this way:

Jean-Jacques Dubray
Apr 22 2016 11:52
@HighOnDrive I have some good news, when you use SAM you don't need a lens library the S() is responsible for decoupling the View from the Model, unlike all these pesky MVx patterns, the State function will allow you to programmatically project the model into the View components.
Incidentally everything is a side effect, when you issue an intent, someone knows that the intent exists #JustSaying...
devin ivy
Apr 22 2016 12:24

Incidentally everything is a side effect, when you issue an intent, someone knows that the intent exists

do you think this formulation of actions is flawed, or just against the stated principles of architectures that use them (intents)?

Jean-Jacques Dubray
Apr 22 2016 15:57
I am just trying to say that everything is a question of perspective, there is no reason to be apply artificial constraints such as the ones of Reactive Programming. Yes, SAM is reactive (as opposed to interactive), but the "everything is immutable" constraint does not make much sense at all.
When Matti all the sudden arbitrarily shifts to model to be a side=effect, well it is just that arbitrary, so why not step back and really think about programming model, wiring and architecture without being constrained to arbitrary rules, just because somebody like Dan, André or myself said so.
Michael Solovyov
Apr 22 2016 18:31
a thin vdom lib that seems like it would be a good mesh with sam
Jean-Jacques Dubray
Apr 22 2016 19:14
Thank you Michael, at first glance I really like it. I am going to give it a try.
Fred Daoud
Apr 22 2016 20:01
@msolovyov : looks nice! thanks for the reference
Apr 22 2016 20:20
How does it compare with snabbdom