These are chat archives for jdubray/sam

2nd
Feb 2017
Slađan Ristić
@sladiri
Feb 02 2017 00:22
@jdubray Thank you JJ. I did saw your SAFE repo, but I want to play around with the pattern. :)
Jean-Jacques Dubray
@jdubray
Feb 02 2017 00:22
sure!
@foxdonut yes, I agree, I connected with Leo to see if we could do something to that effect.
Slađan Ristić
@sladiri
Feb 02 2017 00:36
The actions checking the IDs was a bit intentional, but your feedback here helps to find implementations of the pattern. I was forgetting the single "next action" restriction for example. I tried a generator function, and it looks interesting too :) https://github.com/sladiri/sam-simpler/blob/feature/fix_fabric/src/fabric.js
Jean-Jacques Dubray
@jdubray
Feb 02 2017 13:25
I am not a big fan of generator functions, they hold state in an inaccessible/encapsulated way. They simply make no sense. There will be a time when we'll take them off from the language once enough people get burned by them and declare them useless.
Jean-Jacques Dubray
@jdubray
Feb 02 2017 13:30
It's like everything, designers feel compelled to add bells and whistles with the assumption that people can still decide to not use any of them. So again, my recommendation is to always make conscious decisions with respect to programming model, wiring and architecture. Throwing a shiny wrench in a well running engine, will still result in the same outcome, no matter how shiny it is.
Slađan Ristić
@sladiri
Feb 02 2017 16:55
hm, I find it is very readable, the sam node is just a loop :) The generator does not add any state here, it just waits for the next action at one point.
an async version allows you to wait for api calls to, and it is just normal code without callbacks
It looks like we are going to use sam like this for a "medium" sized project, which uses polymer and, redux-polymer. I can integrate them pretty well, it seems. redux is a given, it could be easier without, probably.
Jean-Jacques Dubray
@jdubray
Feb 02 2017 17:12
yes, I understand how it would control the SAM loop, but the question is what does it bring compared to the traditional wiring V = State(Model.present(Action(event))).then(nap) ?
Slađan Ristić
@sladiri
Feb 02 2017 17:14
I find it more readable, compared to that functional style. I am not against functional style, but in this case I do not see the benefit. :)
Jean-Jacques Dubray
@jdubray
Feb 02 2017 17:15
it's ok, maybe you need to show me a sample.
Slađan Ristić
@sladiri
Feb 02 2017 17:16
will do, yes, on the weekend I have some free time
Rodrigo Carranza
@DrecDroid
Feb 02 2017 17:16
What does this means ::generator.next?
this operator ::
Jean-Jacques Dubray
@jdubray
Feb 02 2017 17:16
yes, I was wondering the same thing
Rodrigo Carranza
@DrecDroid
Feb 02 2017 17:17
ok, found It, looks like It is the same as generator.next.bind(generator)
Jean-Jacques Dubray
@jdubray
Feb 02 2017 17:18
I think the bind operator should be rename "bend" as in "mind bending"
Fred Daoud
@foxdonut
Feb 02 2017 17:42
or "bend the rules" ;)
Jean-Jacques Dubray
@jdubray
Feb 02 2017 17:54
:-)
Slađan Ristić
@sladiri
Feb 02 2017 18:01
:D I went with babel, yes. The async generator is in stage3 already I think. That bind operator is not that far.
Also the queue is not doing much btw, I just need have a single item there in my current experiment.
I recently saw an interesting video about programming styles, that was an inspiration too:
https://www.youtube.com/watch?v=449j7oKQVkc
Jean-Jacques Dubray
@jdubray
Feb 02 2017 18:41
@sladiri this is very interesting thank you for sharing, I understand now why you think "pausing is cool"!
Jean-Jacques Dubray
@jdubray
Feb 02 2017 19:27
Why You Shouldn’t Use ReactJS For Complex Interactive Front-End Projects
Rodrigo Carranza
@DrecDroid
Feb 02 2017 22:07
What is the solution for javascript then? He is only marketing his own framework.
Jean-Jacques Dubray
@jdubray
Feb 02 2017 23:24
These issues need to be considered. For instance Angular2 offers much more control over the change detection mechanism since you get a chance to wire a pub/sub mechanism between your state representation and your view components. Only the components subscribing to the topics being updated would participate in the change detection. React/Redux don't seem to provide any mechanism like that, it's just too reactive.
Rodrigo Carranza
@DrecDroid
Feb 02 2017 23:26
What about MobX + React
Jean-Jacques Dubray
@jdubray
Feb 02 2017 23:36
I am not sure you would gain much, do you know how MobX is wired to React's rendering? Are you rendering each time you change the value of an observable? or is there a prepare/commit mechanism?
Rodrigo Carranza
@DrecDroid
Feb 02 2017 23:39
But, I mean, at least It solves the deeply nested component problem using Its mobx-react function inject
Jean-Jacques Dubray
@jdubray
Feb 02 2017 23:40
sorry, I don't know enough of its underlying capabilities.
Rodrigo Carranza
@DrecDroid
Feb 02 2017 23:46
The article addresses that the React principal problem is full tree rendering/comparison, and deeply nested components callback passing. But It doesn't give any solution other than using Binding.Scala which requires the use of, of course, Scala.
Jean-Jacques Dubray
@jdubray
Feb 02 2017 23:47
You may be better off implementing your rendering in straight ES6, templates literals are quite nice compared to anything I am seen. At a minimum you should be conscious of these issues when starting a react project.