v0.5.3
Notable Changes
New Request-Response Semantics (without correlation IDs)
Clearly, not all changes should propagate to all nodes. The decoupled request (from) and response (to) handlers are capable of contextually blocking incoming/outgoing streams, in addition to transforming representations. However, as in the case of validation, blocking an incoming message is not always enough either - you need to respond with details why. It's common for request-response implementions over a channel like WebSockets to hinge on a sufficiently random correlation ID. However, since we use logs as the underlying core data structure, we can leverage the index of the change (time) as a simpler and more robust UID. The implementation is conceptually simpler and literally a couple of one-liners, but as a convenience, a respond function is provided to from transformation functions to respond to particular incoming changes. On the client, you can use done to wait for a reply to a change, whose implementation is also one line. Example:
// client
done(push(user)(members))
(d => o.draw(d.invalid
? (state.invalid = d.invalid)
: (state.invalid = false
, state.confirm = true)))
// server
function from({}, { value, type }, respond) {
if (type !== 'add') return
const me = ripple('user').whos(this)
, user = validate(me, value)
if (!user.invalid) push(user)(ripple('users'))
respond(user)
}Refinements to the View Layer
By one categorisation, there are two types of elements that may need to be drawn:
- Newly added elements
- Existing elements
By moving the .draw function from the element to Node.prototype, the approach for dealing with both of these becomes the same (call draw after updating state) without having to reference any globals (ripple.draw). This means we don't need to rely on the Custom Elements attachedCallback, or the Mutation Observer polyfills (which have been removed) for the former, and now all scenarios work in all browsers (IE9 has been added to CI to reflect official support). Note that if you are using once it will call .draw for you so you never have to do this manually. If desired, the Mutation Observer code that invokes ripple.draw on newly added elements could also be moved into a separate Ripple module.
Commits
- [
9c9fda7] - remove mutobs polyfill, addNode.prototype.draw - [
6ae145b] - isolate ripple instances per test - [
f2d9a8d] - remove extends functionality - [
41baf7e] - test on ie9 on ci
- [
ead0541] - put each resource on newline for readability
- [
0a17a58] - add request-response semantics