dependabot[bot] on npm_and_yarn
Bump @angular/core from 7.2.15 … (compare)
dependabot[bot] on npm_and_yarn
Bump @angular/core in /angular4… (compare)
dependabot[bot] on npm_and_yarn
Bump eventsource from 1.0.7 to … (compare)
dependabot[bot] on npm_and_yarn
dependabot[bot] on npm_and_yarn
Bump nodemailer from 2.7.2 to 6… (compare)
dependabot[bot] on npm_and_yarn
Bump moment from 2.24.0 to 2.29… (compare)
const matched = (x) => ({
on: () => matched(x),
otherwise: () => x,
})
const match = (...x) => ({
on: (pred, fn) => {
const _pred = typeof pred !== 'function' ? (z) => z === pred : pred
const _fn = typeof fn !== 'function' ? () => fn : fn
return _pred(...x) ? matched(_fn(...x)) : match(...x)
},
otherwise: (fn) => (fn === undefined ? x[0] : typeof fn !== 'function' ? fn : fn(...x)),
})
const matchReduce = (...x) => ({
on: (pred, fn) => {
const _pred = typeof pred !== 'function' ? (z) => z === pred : pred
const _fn = typeof fn !== 'function' ? () => fn : fn
return _pred(...x) ? matchReduce(_fn(...x)) : matchReduce(...x)
},
end: () => (x.length > 1 ? x : R.head(x)),
})
const a = match(someValue)
.on(exists, 'foo')
.otherwise(bar)
if (x == 2 && y > 5) a = x + y
// a = match(x, y)
// .on( (u,v) => u == 2 && v > 5, (u, v) => u + v)
// .otherwise( (u, v) => u - v) // a = x - y
const p = (x,y) => x == 2 && y > 5
So I would not be concerned by that, in practice I have not seen it happening:
This could result in a long chain of actions that need to occur before the view is updated again
@arcfide
in the example wiring, the persistence will only ever happen after rendering,
I agree, I am not disputing that, what's important to note is that the pattern first appeared in 2016 and since then lots of discussions have happened and I have produced a lot of materials that may sometimes conflict with the current view of the pattern. It was shaped with discussions such as this one by the community, not just by me.
persisting the model should be considered a separate Action that is triggered automatically from the NAP due to changes in the model state
That would be my view, though, as I mentioned you have to distinguish between persisting the entire application state (model.persist()) and side effects of the current actions (persisting the data from a form, after proposal and application state mutation).
I'm thinking here of a waiting/loading bar or spinner
Yes, that's the tough case :-), last time I checked, even Redux was spinning it before entering Redux and the rendering of the application state would them stop it. What's original about SAM is the positioning of API calls with respect to the pattern (queries in actions and synchronous updates in the model).