Allowing automatic interpretation of complex data via a function - for example, dates, addresses, etc. (NOTE: Depends on the refactors in the repeater branch). This would not be a breaking change (after the repeater branch).
Motivation
Our session store and forms can only handle very simple JSON data, but often we want to re-use code by wrapping the values in rich objects. These objects may also need access to the request - for example, date objects that contain a locale for month names. While painful to do manually, it is convenient to, for example, register that a particular key is a date, and have that automatically translated in res.locals.
Design Detail
There are a few design kinks to work out, but a presenter is essentially a function that we register to a particular session key. In loadKeys, we would set res.locals[key] = presenters[key](res.locals[key], req, res). This function, unlike customSanitizer from express-validator, is allowed to return a rich object, such as a date or a custom class.
In the case that no presenter is registered for a key, we simply use the original data as-is - so that the default behaviour remains exactly the same.
Drawbacks
This requires saving the "original" data somewhere accessible by views, so that getData still works transparently - res.locals._original or similar.
Prior Art
The presenter pattern is an established pattern for presenting rich data in different contexts.
Unresolved questions
Where and how do we register presenters? (they need to be used mainly by "data-consuming" routes - such as confirmation or PDF rendering, where a schema is not readily available)
Do we place restrictions on the objects returned by presenter functions? Must they have toString or asJSON methods?
Do we allow use of presenters in validation?
What kinds of presenters do we want to ship with? (at minimum, date and address?)
Summary
Allowing automatic interpretation of complex data via a function - for example, dates, addresses, etc. (NOTE: Depends on the refactors in the repeater branch). This would not be a breaking change (after the repeater branch).
Motivation
Our session store and forms can only handle very simple JSON data, but often we want to re-use code by wrapping the values in rich objects. These objects may also need access to the request - for example, date objects that contain a locale for month names. While painful to do manually, it is convenient to, for example, register that a particular key is a date, and have that automatically translated in
res.locals.Design Detail
There are a few design kinks to work out, but a presenter is essentially a function that we register to a particular session key. In
loadKeys, we would setres.locals[key] = presenters[key](res.locals[key], req, res). This function, unlikecustomSanitizerfrom express-validator, is allowed to return a rich object, such as a date or a custom class.In the case that no presenter is registered for a key, we simply use the original data as-is - so that the default behaviour remains exactly the same.
Drawbacks
This requires saving the "original" data somewhere accessible by views, so that
getDatastill works transparently -res.locals._originalor similar.Prior Art
The presenter pattern is an established pattern for presenting rich data in different contexts.
Unresolved questions
Where and how do we register presenters? (they need to be used mainly by "data-consuming" routes - such as confirmation or PDF rendering, where a schema is not readily available)
Do we place restrictions on the objects returned by presenter functions? Must they have
toStringorasJSONmethods?Do we allow use of presenters in validation?
What kinds of presenters do we want to ship with? (at minimum, date and address?)