These are chat archives for jdubray/sam

23rd
Nov 2016
Edward Mulraney
@edmulraney
Nov 23 2016 09:41

can you clarify why it's better to tie my view components to control-state in stateRepresentation rather than in the view layer? at the moment I don't see what stateRepresentation is good for, other than deriving control-state, but I would simply return my control state from that function and not introduce my view layer to it.
e.g.

const model = {users: 4, maxUsers: 5}
function stateRepresentation(model) {
    return {isAtMaxCapacity: model.user >= model.maxUsers}
}
function view(stateRepresentation) {
  if (stateRepresentation.isAtMaxCapacity) {
    return <div>max capacity reached...</div>
  }
  return <div>not at max capacity.. add user...<div>
}
view(stateRepresentation(model))

Now my state representation can be used with React as view layer or vanilla templates, riot etc. etc.

Edward Mulraney
@edmulraney
Nov 23 2016 09:49

your question about nap:

I don't see a strong coupling between the view components and the next-actions.

Lets say I have a list of users and a list of cars. They live in seperate pages/screens/components. When I view the users component I want to fetch users from the server, so nap might do something like if(!status.usersLoaded) fetchUsers() which is fine - i now have users. Now when I navigate to cars component, nap will do the same thing: if(!status.carsLoaded.... loadCars(). But given this all happens in a global nap, i can't say that i only want cars loaded when the user visits the cars page, it will load them even if i visit the users page only. I'd have to couple my nap to view components in some way: if(!status.carsLoaded && isOnCarsComponent) loadCars()

Fred Daoud
@foxdonut
Nov 23 2016 13:05
@edmulraney fwiw in meiosis, each component can have their own nap(), and the state is a function as you described.
Edward Mulraney
@edmulraney
Nov 23 2016 13:32
yeah - nice :)
Jean-Jacques Dubray
@jdubray
Nov 23 2016 16:56
To answer your first question, there is no strong requirement for how the state/view/theme connects. That is way beyond TLA+, at a minimum the state function will decouple the model from the component properties and of course compute the equivalent of the control state of the application, which could turn out to be a page, error condition, ...
With respect to your example, this can be easily solved considering that when you enter a new page/control state, the action could propose a value for carsNeedsLoading = true;
Jean-Jacques Dubray
@jdubray
Nov 23 2016 17:01
So the condition would be something like:
if(!status.carsLoaded && status.carsNeedsLoading) loadCars()
Edward Mulraney
@edmulraney
Nov 23 2016 17:23
oh good point! that does make more sense actually, it forces you to think of your system as a whole - total status understanding
unexpected states less likely to happen

To answer your first question, there is no strong requirement for how the state/view/theme connects.

Ah okay - i based my comments off of what you wrote on sam.js.org - might be worth mentioning that in the stateRepresentation section

Jean-Jacques Dubray
@jdubray
Nov 23 2016 18:20
sure, thank you for all your questions!
the problem is that HTML is not 100% declarative, not sure you can do without JQuery and nap() is going to have quite a bit of it. That's perhaps why @foxdonut has a nap per component.
Fred Daoud
@foxdonut
Nov 23 2016 18:25
I have a nap() per component for the same reason I have the other functions per component, so that code can be modularized when appropriate. But you're right, because HTML is not completely declarative, you sometimes need a hook to e.g. run jQuery code. For that, Meiosis has the postRender function.
Likewise, the use of a dispatch prop in React components is highly discouraged. Instead, action creators are used exclusively to post updates to the state so that components can remain totally agnostic to state schema design:

I won't talk about the second recommendation (use Sagas for async stuff) since we just discussed that:

Redux-Saga is a coroutine runner (a feature sorely missing from native Javascript) that wraps generator functions called sagas. These functions can yield out declarative effects, promises, other sagas, or other types that are automatically handled.

Edward Mulraney
@edmulraney
Nov 23 2016 21:52
@foxdonut the way i would do it is have nap defined per component but combined into one single nap via wiring
benefit of that is that you could have app or parent level nap running even tho the active component is a page with its own nap
rudimentary example
<app> // has some higher level nap running in background
  <userComponent isActive=true> // has data fetching nap running due to shouldFetchUserData
  </userComponent>
  <carsComponent isActive=false> // has own nap but shouldFetchCarData would be false 
  </carsComponent>
</app>
Fred Daoud
@foxdonut
Nov 23 2016 21:57
@edmulraney not sure what you mean by this:
benefit of that is that you could have app or parent level nap running even tho the active component is a page with its own nap
in Meiosis each component can have nap, and a parent-level component can have a nap also, one does not prevent the other from running.
Edward Mulraney
@edmulraney
Nov 23 2016 22:14
ah okay i assumed only the component from active router item would run
@jdubray good article - it echoes a lot of what we've disussed here. we came to the same conclusions in a company i contracted in this year, except we wrote our own async middleware rather than using sagas
we didnt use Immuatable js either, didn't really need it
Edward Mulraney
@edmulraney
Nov 23 2016 22:19
you can achieve sagas with nap i believe
Jean-Jacques Dubray
@jdubray
Nov 23 2016 23:40
:thumbsup: