4 ms·

I appreciate your responses, but I think we got off track somehow. I'm quite familiar with the general architecture of SPA's... my question is specifically abou

I appreciate your responses, but I think we got off track somehow. I'm quite familiar with the general architecture of SPA's... my question is specifically about how this library implements this feature. I didn't see anything in the docs about how to use URI or HTTP headers (or anything else) to specify which fragments you want -- instead it just says "?spf=navigate will be appended to the url". So I was wondering how this library specifically thinks more fine-grained details about what to return should be communicated to the server.

aaronem 11y ago
As far as I can tell, that's pretty much all you've got. Given the heavy concentration this library seems to place on converting static navigation to dynamic, my surmise is that, instead of responding to a navigation link with an entire HTML document, it just responds with the content that document would contain in the response object's "body" member, with content fragments organized by the ID of the element they're meant to populate. View changes seem to be supported by sending the appropriate template fragments in the "head", "title", and optionally "foot" members of the response JSON object. More complex state transitions such as form submissions appear to be provided for in the second argument of the spf.navigate method, which can take an object including a POST method specification and the corresponding data. It looks like that's about all the library provides in terms of request flexibility; per the code, setting custom request headers on navigation requests is definitely unavailable, but it doesn't do anything to override the default behavior by which XHR passes on e.g. Authorization headers already set by client code, so (in conjunction with e.g. OAuth) you'd be able to identify and authenticate the user making the request. I guess the idea is that, for the purpose the library's meant to answer, what it provides in the URI is just about all the information the server should need on what content to include in the response.

aaronem 11y ago

As far as I can tell, that's pretty much all you've got. Given the heavy concentration this library seems to place on converting static navigation to dynamic, my surmise is that, instead of responding to a navigation link with an entire HTML document, it just responds with the content that document would contain in the response object's "body" member, with content fragments organized by the ID of the element they're meant to populate. View changes seem to be supported by sending the appropriate template fragments in the "head", "title", and optionally "foot" members of the response JSON object. More complex state transitions such as form submissions appear to be provided for in the second argument of the spf.navigate method, which can take an object including a POST method specification and the corresponding data. It looks like that's about all the library provides in terms of request flexibility; per the code, setting custom request headers on navigation requests is definitely unavailable, but it doesn't do anything to override the default behavior by which XHR passes on e.g. Authorization headers already set by client code, so (in conjunction with e.g. OAuth) you'd be able to identify and authenticate the user making the request. I guess the idea is that, for the purpose the library's meant to answer, what it provides in the URI is just about all the information the server should need on what content to include in the response.