Open lxbarth opened 13 years ago
I've run into this head first today.
I'm trying to build an application where the router instantiates a 'State' model, which represents which page is active and so forth. There is a central interface view, which listens to events on the state model, and handles re-rendering component views. The router would only be responsible for changing the context object. (ie: set the current page).
There's a leak in the abstraction due to this. The environment that renders the initial page, versus renders subsequent page loads, is different. This means that on the server side, there is no way to set up a state/context object for the request.
I actually think the correct solution for this is to standardize on TJ's new pages.js client side router (heavily inspired) by express, that solves this kind of thing already. http://visionmedia.github.com/page.js/
will keep you updated if i figure something out.
Right now we hang client-space singletons like
admin
oruser
off of theBones
object - only client-side. Typically, a code like the snippet below is executed client-side to set up a global object, modules likebones-document
would then rely on it.Two problems:
1) This pattern cannot be replicated on the server as such global objects would be in the global application scope, not in the client (= window) scope. 2) Having a global object X set up to make a module work as expected is not ideal, we should review better patterns (passing a user/admin/whatever object into constructors?)
Right now we're making hesitant use of the existing pattern described initially. If we solve this issue, we could make much safer assumptions around client space singletons and push more code into modules like
bones-auth
andbones-document
= reuse more code.Potential solutions
Bones could provide a 'request' object that would hang off an Express request server side and the
window
object client side. This 'request' object (better name?) would provide a safe space for client space objects.More thoughts needed.