These are chat archives for jdubray/sam

16th
May 2016
Jean-Jacques Dubray
@jdubray
May 16 2016 04:30
How else would you do it?
dnson
@imnutz
May 16 2016 06:21
pass actions as parameter then?
weepy
@weepy
May 16 2016 06:24
The handlers are all evaluated in the global scope so need to attach to something there. Otherwise you could add th handlers after
Jquery stylw
Btw I think you can just to onclick="actions..." and leave off "JavaScript: return"
Tomas Roos
@ptomasroos
May 16 2016 09:56
Just recapped last days discussions, seems you had some fun :)
Fred Daoud
@foxdonut
May 16 2016 10:46
@jdubray you can't pass actions to HTML code, so instead you could add your event listeners in a module of JavaScript code such as document.getElementById('..').addEventListener("dblclick", function(evt) { actions.xyz(); }); and then pass actions to that module.
Tomas Roos
@ptomasroos
May 16 2016 10:46
Or just use a packaging tool to structure the rest of the code according to ES6 as well
Jean-Jacques Dubray
@jdubray
May 16 2016 11:28
I cleaned a bit the theme code along these lines:
<div class="view">
        <input class="toggle" type="checkbox" ${(checked ? 'checked' : '')} 
                      onclick="return ${intents['done']}({\'id\':\'${todo.id}\'});">
       ${(todo.edited ? input : label)}
       <button class="destroy" onclick="return ${intents['delete']}({\'id\':\'${todo.id}\'});"></button>
</div>
The intent now contains "actions.done" so the theme does not know which global variable it will be bound to.
I would prefer leaving the responsibility of wiring events and intents to the view component. The application should not know how the component works and the component should not know which application is using it.
Jean-Jacques Dubray
@jdubray
May 16 2016 11:33
As I mentioned before, actions are adapters between the view and the model, such that the event payload does not have to match the model semantics. Data structures like this {\'id\':\'${todo.id}\'} can be adapted by the action, assuming the theme was designed by someone else and you want it to work with your model.
It's a key design goal for SAM to keep the theme as autonomous as it could be from the application logic.
I also would like to emphasize that because V = f(M) works like a mini "code generator" for the View components, you don't need sophisticated wiring mechanisms to achieve that decoupling.
Jean-Jacques Dubray
@jdubray
May 16 2016 11:40
@ptomasroos I am trying really hard not to use a packaging tool. Between HTTP2 and ES6, they should go away pretty soon?
Jean-Jacques Dubray
@jdubray
May 16 2016 16:59
I found the redux-effects library: https://github.com/redux-effects/redux-effects
The effects supported include:
  • redux-effects-timeout - setTimeout/setInterval/requestAnimationFrame
  • redux-effects-fetch - HTTP Requests
  • redux-effects-cookie - Cookie get/set
  • redux-effects-location - Location (window.location) binding and setting
  • redux-effects-random - Generate random numbers
  • redux-effects-events - Dispatch actions in response to window/document events (e.g. scroll/resize/popstate/etc)
  • redux-effects-localstorage - localStorage effects driver
  • redux-effects-credentials - Automatically decorate your fetch requests with credentials stored in state if the url matches a certain pattern.
Jean-Jacques Dubray
@jdubray
May 16 2016 17:04
IMHO, and unless I am missing something, the problem is that the decision to dispatch is made prior to the effect being instantiated.
In SAM, a "fetch" effect runs independently until it's ready to present data. It can be checked then if the application state is such that the action can present data to the model. Similarly an update can be instantiated in the critical section because it makes no sense to accept other actions until the update has succeed. It's not because you don't want to block the UI that you logically can.
Erik has not replied yet to my question, but from my perspective, the idea of creating a declarative model for effects and decouple the application state mutation from the effects seems to be a dead end. In the end, there are effects, that's a fact, and you have to come up with a programming model that is able to deal with them. It seems to me that you cannot arbitrarily say: "I'll separate the business logic from the effects".
Fred Daoud
@foxdonut
May 16 2016 19:06
interesting, @jdubray ... I am experimenting with that as well
Jean-Jacques Dubray
@jdubray
May 16 2016 22:04
Another redux-sideeffect library: https://github.com/salsita/redux-side-effects, using generators to wrap the effects. If I understand correctly, it still based on the assumption that one triggers the effects with the assumption that the effect may trigger another action:
function* reducer(appState = 1, action) {
  yield sideEffect(loggingEffect, 'This is side effect');

  return appState + 1;
}
That's a bit cleaner than a full Saga but that sounds a bit overkill, just to keep the reducer pure.