You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 30, 2018. It is now read-only.
Our current "page" data object is unique to each request, and is a great place to store request-specific objects/data. However, there's no way for middleware to put objects/data into it.
The text was updated successfully, but these errors were encountered:
Since the page obj is probably going to have contextualized stuff (don't know), I will suggest to allow requests to attach a page object into the request object (or potentially req.locals, which is the standard way of doing it in express 3) and then getting mojito.js to augment that object with more stuff if it exists, or just create a new object.
Well the middleware is actually just as request-specific as the page object (including contextualization).
I'm looking at line 33 of lib/output-handler.server.js, which is where the page object is created. Right after creating it we could also merge in req.page (or req.locals or whatever we want to call it).
Oh hmm... I see what you mean, mojito.js is pushing data into the page object. That's a little dirty and is being done that way because the output handler doesn't have direct access to the store. However, the output handler does have direct access to the request object, so I argue that the output handler ctor should be responsible (instead of mojito.js) for moving data from req.page[1] to the page object.
[1] ... or whatever we call it
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Our current "page" data object is unique to each request, and is a great place to store request-specific objects/data. However, there's no way for middleware to put objects/data into it.
The text was updated successfully, but these errors were encountered: