-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nap as a flux-like store #14
Comments
Interesting. Worth spiking a POC... |
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. |
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". |
Well, #5 is more to the point of abstracting away hypermedia affordances from the underlying media type. So HTML for instance has |
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 |
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) |
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:
type
set to one of the HTTP verbs and the rest of the data as a payload.The text was updated successfully, but these errors were encountered: