These are chat archives for jdubray/sam

7th
Jul 2017
Jean-Jacques Dubray
@jdubray
Jul 07 2017 12:46
@formido yes! Note the progression to get rid of DOM manipulations:
  • server side templates
  • client side templates
  • functional HTML
Jean-Jacques Dubray
@jdubray
Jul 07 2017 12:51
The only problem with React is that it's too reactive. You don't have a good control as to when and what needs to change.
Does React work? just try any facebook client... I 5 or 6 different clients, all of them suffer from major flaws, the most obvious one is that you can't write a post when messenger is open. You can open the post window but that's about it. Really? Mark should pay more attention to his product and architecture than spending his time to lecture the world from the eyes of a lucky 30 something.
devin ivy
@devinivy
Jul 07 2017 13:07
@jdubray so you basically don't like that react might re-render while the app is in an intermediate state?
Jean-Jacques Dubray
@jdubray
Jul 07 2017 14:20
I like to have control over the programming step. "data binding" is a terrible idea, whether you do it with templates or fancy React. That approach brings nothing at all to the programming model, this is another Cargo Cult invented by some marketing guy somewhere who felt this would be a cool demo: look ma' I change data here and my UI renders!!
Semantics must be designed with the upmost precision, there is no room for marketing or coolness. Semantics is what paints you in a corner and ultimately kills your project when it gets too big.
devin ivy
@devinivy
Jul 07 2017 14:31
isn't data binding essentially at the core of the functional UI? you need some way to map data into the interface declaratively. is data binding something other than that?
or are you referring to the fact that changes in data actually cause the re-render of the UI?
in terms of timing.
Fred Daoud
@foxdonut
Jul 07 2017 16:09
I think it's a matter of not having control over it. i.e. setState(...) doesn't just set the state, it triggers a re-render. Worse in angular, obj.value = 5 triggers a re-render.
For React, again, this is entirely avoided when you stay away from using state, props, setState, etc.
You can totally take control and clearly define your programming step by just using ReactDOM.render.
Great fit for SAM, the state representation renders the view with ReactDOM.render.
Jean-Jacques Dubray
@jdubray
Jul 07 2017 17:01
@foxdonut @devinivy yes, exactly it's a question of control, for me it makes no sense to change data and have the UI change in lockstep.
It's counter to any programming principle I can think off, only a marketing guy could think that would be useful.
Now the next question is what is the relationship between data elements and the UI. Are we talking about the Model, the State? All these questions have massive consequences and if you start on the wrong foot, you'll lose balance sooner than later.
Jean-Jacques Dubray
@jdubray
Jul 07 2017 17:32
Ember's programming model:
image.png
face-palm
@foxdonut I may not know React enough but perhaps the same technique I use for Angular would work with react (pub/sub)? not sure.
Fred Daoud
@foxdonut
Jul 07 2017 19:25
@jdubray probably, yes.
I would think it'd be even simpler, though. Your state representation produces the view and you just call ReactDOM.render to produce the view representation.
It's even more explicit than Angular (I think.)
Jean-Jacques Dubray
@jdubray
Jul 07 2017 22:04
Angular allows me to publish some changes to any component on the page independently. My understanding is that React can't do that but I may be wrong
Slađan Ristić
@sladiri
Jul 07 2017 22:52
As far as I understand, Cerebral does that too @jdubray . There is the option to use immutable state, where there would rerendering of every "listening" component to an ancestor of a changed leaf in the state tree.
Jean-Jacques Dubray
@jdubray
Jul 07 2017 22:56
I think that's a really good architecture
Slađan Ristić
@sladiri
Jul 07 2017 23:00
I like it too, I think they use Baobab.js, which allows you to listen for change events in the tree. And you declare what events are relevant for a component.
But you cannot defer, batch or prevent rerendering on state-change easily (out of the box). I could implement SAM by sticking to a convention for the state change, building a container, so to speak.