These are chat archives for jdubray/sam

10th
Apr 2017
Rodrigo Carranza
@DrecDroid
Apr 10 2017 03:33
Yeah but when you change the code that renders on one side you have to modify the other accordingly. I've accomplished both server and client side rendering with the same core code
but It makes difficult to make changes without worrying if something will break on the client or the server or both
ChangJoo Park(박창주)
@ChangJoo-Park
Apr 10 2017 03:52
@jdubray translated in Korean about 90% :smile:
Paolo Furini
@pfurini
Apr 10 2017 08:03

@DrecDroid

Yeah but when you change the code that renders on one side you have to modify the other accordingly.

That's not true.. Otherwise that library and the equivalent ones for other stacks would be pretty useless.. From the docs it does: Server-side prerendering of SPA components (tested with React, NG2, Knockout), Hot module replacement, Server-side and client-side routing integration plus other goodies like caching

Jean-Jacques Dubray
@jdubray
Apr 10 2017 12:20
@ChangJoo-Park thank you!
Rodrigo Carranza
@DrecDroid
Apr 10 2017 13:30
@pfurini but now you're tied to JS + React + Webpack + ... , why not better do the old server side rendering with the language of your for everything that is static and needs SEO, and for the app forget about SEO and do the rendering on client side.
Paolo Furini
@pfurini
Apr 10 2017 14:41
but that was exactly my original point! :smile: I was only arguing that, despite many people think, you are not tied to everything JS if you need server-side rendering..
if you could avoid it altogether, then you should, for the sake of overall simplicity.. you can also do hybrid SPAs, that is pages augmented with SPA semantics, with browser history merging (back goes back in SPA router, then it goes back to real history)
Rodrigo Carranza
@DrecDroid
Apr 10 2017 16:10
:smile: exactly that, hybrid SPA will be my way to go
Paolo Furini
@pfurini
Apr 10 2017 16:19
@jdubray Hi, I tried to assemble a PoC written from scratch in ES6 here: http://plnkr.co/SjKe4T
It's simply a rocket launcher clone, but with some glue code that can make it reusable in different contexts. What do you think?
Jean-Jacques Dubray
@jdubray
Apr 10 2017 16:45
@pfurini very nice, the "action resolver" is exactly what I meant for decoupling the UI components from the actions themselves.
I would just rename rocket.js to rocket-actions.js, I think that's what it's file is for.
The rootView is what now I implement as a "theme", otherwise yes you have pretty much everything.
Paolo Furini
@pfurini
Apr 10 2017 16:50
you're right, that Rocket class is somewhat I must reason more about.. I named it like that, cause I've seen an analogy with the OOP concept of messages (aka instance methods) and the actions themselves
Paolo Furini
@pfurini
Apr 10 2017 16:57
but TBH, with that generic signature (data, actionResolverService) they lose a bit of that message semantic
Paolo Furini
@pfurini
Apr 10 2017 17:07
another question.. when I was writing the propose method on the model class, I started by checking if the counter had reached 0, and then set launched:true on the model data. I didn't have a 'Rocket.launch' intent.
Then I asked myself: is it ok to do more mutation than the proposal asked me? So I introduced the launch intent/action pair, and changed the propose function accordingly.
What's the best approach, if any? Given a simple model like this, it doesn't matter so much, but I'm wondering how to deal with complex model mutations..
Zach Dahl
@schtauffen
Apr 10 2017 18:14
I think nap would generally launch the rocket
Jean-Jacques Dubray
@jdubray
Apr 10 2017 18:21
Yes you could treat as an automatic action with nap. That sounds the closest to reality. You could even think in real world system the launch action could present to more than one model...
In any case, yes that's the point of the action/model separation, in the action you don't want to know the whole scope of what accepting these values would entail. If you can the proposal should be as close as possible to the values you want to model to have, but that's not a hard rule and more changes are expected to happen in the model as a result of accepting, partially accepting or rejecting a proposal (generically described as accepting a proposal). That the general problem in MVC, the controllers know too much (the controller is a mash up of action, model and state).
Marcus Feitoza
@mfeitoza
Apr 10 2017 18:38
@pfurini great ideia of actionResolver.
Paolo Furini
@pfurini
Apr 10 2017 18:58
@jdubray Thanks, more clear now. What you said about partially accepting or rejecting a proposal reminded me another question I had: In my simple PoC I had adopted a simple optimisation, that is if the model is NOT mutated (for example if the proposal is rejected), then the state function is not called at all..
Is it a correct behaviour even in real-world apps?
Jean-Jacques Dubray
@jdubray
Apr 10 2017 19:46
Yes, absolutely. You should not bother informing anyone if no changes have happened! That's maybe one advantage of SPAs, you more easily implement this kind of optimization.
In the extreme you could also implement a SAM instance for each controller instance in the MVC world (I don't recommend it), but you could factor a controller in terms of actions, updates it makes to the model and DOM manipulation. At a minimum it would make the controller code a bit more streamlined. I think there is value is breaking up the controller(s) in terms of Actions, Mode, and State+nap, but that maybe just me.