Nap as a flux-like store

[cristiano-belloni]

This is the other side of #13: I'm using redux.js at home and I was wondering how to make a flux-like store with Nap / resourceful.

Turns out, IMHO, that they are conceptually very similar:

• Redux has actions. An action is "the only source of information for a store", and "must have a type property that indicates the type of action being performed". Sounds similar? Our RESTful requests are actions, with type set to one of the HTTP verbs and the rest of the data as a payload.
• Redux has reducers and stores. Reducers "specify how the application’s state changes in response". They are essentially request handlers. The store holds state, and can be easily achieved within a module that uses immutables.
• Redux has middlewares, which come out of the box with Nap.
• The only thing we don't have currently is subscribing to a store, aka being called back when the store changes. We had the stream type implementation in am-address that would be perfectly suited for it and probably could have a space in Nap.

[aaronhaines]

Interesting. Worth spiking a POC...

[mstade]

I'm going to provide a more reasoned response in due time, but I just wanted to quickly comment on your last point about streams. I haven't seen the am-address implementation, so please excuse anything I might say that's redundant, I'll have a look for it later. Anyway, streams is a thing we discussed a lot back in the early days – and whether to make it core or not. Thing is, the request/response model isn't by itself very well suited to streams, and moreover there are different kinds of streams that make finding a generic abstraction difficult. So what we decided back then was that the request/response model stays put, but that you should be able to respond with a stream. This would allow us (and others) to implement different kinds of streams (such as event source) while not limiting ourselves. So in essence, the stream isn't a primitive construct like responses. Instead, it is the response – or well, the response body anyhow.

[cristiano-belloni]

Yep, understood. Makes sense, and that's how we do it now with zap streams. I guess that, in the spike, we just need to respond with a dispatchers or whatever form of one-way evented communication.

Also, probably #5 is related to this: if we can specify our custom media types, it'll be easy to have a whatever.stream type and use it requesting from our "store".

[mstade]

Well, #5 is more to the point of abstracting away hypermedia affordances from the underlying media type. So HTML for instance has <form>, and JSON-inspired hypermedia format may use URI templates or some other construct, but from a Javascript perspective they can be abstracted away as simply functions. There was some work to that effect in the experimental branch I think (and if not, I probably have it not-pushed somewhere.) Frankly, it's more of a client side aspect, and ought to perhaps be part of a pure client project like am-address instead. It's just that I think there may be an opportunity for a feature in nap there to provide for a away to add media type handlers (or "renderers", in the sense that they render a function) such that clients can be composed instead of being monoliths.

[mstade]

So, to clarify, the point of adding that level of abstraction is such that you can consume a resource and make use of its hypermedia affordances, without ever really having to know or care what media type the returned representation is. As well, because nap has request metadata (a one-up on actions) even media types that do not support hypermedia (such as plain ol' JSON) could do so via Link headers. A consumer wouldn't, and shouldn't, have to care how the links are represented, if nap abstracts that away.

[mstade]

And again to clarify, because clearly I can't get it all in one post. You're absolutely on point with the streams thing. :o)