The pattern is unidirectional
Indeed, and asking something to a Service maintained by a State function is not against this rule, as long as the Service will provide readonly endpoint.
The only thing the View can send "out" is an Action, no?
The View have a full read access to the Representation as it is how the SAM container want to be seen by the external world.
Think at a painting, which is the Representation of the mind of an artist (the Model). You can totally see in any angle you want through your own filter (through glasses, phone, you own reproduction...)
But you can't alter it without violate it. You can't paint on it without changing its identity. (yes, you can, but you will get into trouble)
It is the same for our app. You can either get the full file and do the filter on your computer. Or the SAM Container can expose an API (like in the blog example) to serve the Representation with or without predefined or customizable filters. No one will modify the model through this.
the State is not permitted to cache or retain that state (it's a pure function over the model)
The purity of the State fn is not mandatory as long as its guarantee one thing: the Representation is in sync with the Model. The purity is just an easy way to achieve this.
(ill baby, 4am...)
What putting in the model is just a design decision.
My SOC mindset for a project like the bank example is to think as business/functional first. I will never mix UI concern like loading state or filtering with business concern like user financial data.
But SAM being just a pattern, it will work all the same if you put any domain together in the model. No doubt on that.
To push the example further. If I need to persist some UI state between screens (loading state, recent keyword search, etc.), I would use a second SAM container to handle this.
This container may be on the View, so completely separated from the Server SAM container.
what would that Headless SAM pattern look like, and where would the results of an API query go?
For a REST API :
- I would handle GET queries as actual Representation getters.
- I would handle PUT/POST/DELETE as Actions given the fact they will mutate the model.
For a GraphQL end point, I would do the same but with queries and mutations.
You have a good example of this in the SAM SAFE example. https://github.com/jdubray/sam-safe/blob/master/server-model.js
- Look at the init endpoint. It is just a getter on the current View (let's say View = Representation). Here it is empty but we can imagine sending a authorId in params or other filters to retrieve a subset of blog posts.
- The second endpoint is just the Present function (actions are on clients)
This is a good exemple of SOC, the filtering is done on the Representation and the only available mutable interface is the Present endpoint.
For a GraphQL end point, I would do the same but with queries and mutations.
note that GraphQL is a very elegant facade for SAM pattern when you have Client[View, Actions], Server[State,Model] because they provide a clear semantic which perfectly feats with SAM interface.
- the client actions will send their proposal as GraphQL mutations.
- the client view will query the Representation with only what it needs with the destructuring magic of gql.
2 replies
const intents = SAMtest({
component: {
actions: [
() => ({ test: true }),
{ label: 'LABELED_ACTION', action: () => ({ labeledAction: true }) },
['ANOTHER_LABELED_ACTION', () => ({anotherLabel: true })]
]
}
}).intents
tick = intents[0]
labeledTick = intents[1]
anotherLabeledTick = intents[2]
})getIntents is just a convenience wrapper to that initialization using SAM's global instance:getIntents: actions => SAM({ component: { actions } }),const actions = [
() => ({ test: true }),
{ label: 'LABELED_ACTION', action: () => ({ labeledAction: true }) },
['ANOTHER_LABELED_ACTION', () => ({anotherLabel: true })]
]getIntents(actions).intents.
getIntents is not what i want. const test = api();
test.addComponent({
actions: [
async (username, password) => {
let user = null;
const response = await fetch("http://127.0.0.1:8000/api/auth/token", {
method: "POST",
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify({
username,
password
})
});
const data = await response.json();
if (response.status === 200) {
user = data;
}
return { user: user };
}
],
acceptors: [
model => ({ user }) => {
console.log(user);
model.user = user;
}
],
options: {
ignoreOutdatedProposals: true
}
});
test.setRender(state => {
if (state.hasError()) {
console.log(state.errorMessage())
state.clearError()
}
console.log(state);
});
console.log(test.getIntents());SAM.intents
const { addInitialState, addComponent, setRender } = tp
// your application implementation
import initialState from './sam/initialState.js'
import todo from './sam/todoComponent.js'
import createFrom from './sam/theme.js'
import { display } from './sam/display.js'
// wire it up
addInitialState(initialState)
const { intents } = addComponent(todo)
setRender([display, createFrom(intents).representation])
// start your application
displayAll()api()