Feature request: Locals as a context #137
Description
In some circumstances, one might want to access locals passed into the template from elsewhere in the rendering tree, without needing support code in every single view.
A typical example of this is dealing with form validation errors; a common approach is to pass a set of form validation errors into the locals for the view, and then highlight each input field that appears in the set of errors, accompanied by a descriptive error. Previous values are also usually prefilled. This works more-or-less out-of-the-box in other templating engines, since locals are usually global to the entire template hierarchy.
An ergonomic approach to this in React would be to create a custom <Input> component or something along those lines, but... there's no way to get at the set of form errors, without some sort of support code in the top-level view, by eg. passing it as context.
Since the views are the only place that have access to the locals directly (given that they are passed in as props there), you'd end up with something like this in every single view:
module.exports = function SomeView(props) {
return (
<LocalsContext value={props}>
<SomeLayout>
<p>Hello world!</p>
...
</SomeLayout>
</LocalsContext>
);
}This is obviously not very ergonomic, and violates DRY. A more useful approach would be for express-react-views to expose the full set of locals by default in a special context, so that a view would look like this instead:
module.exports = function SomeView() {
return (
<SomeLayout>
<p>Hello world!</p>
</SomeLayout>
);
}Code that actually needs the template locals - possibly nested a few levels deep - could then do something like the following:
const LocalsContext = require("express-react-views/locals-context");
module.exports = function Input(props) {
return (
<LocalsContext>
{(locals) => {
return <input name={props.name} value={locals.formData[props.name]} />;
}}
</LocalsContext>
);
};This would put express-react-views on equal footing with other templaters, from the perspective of supporting template-global values - and keeps the complexity for handling them in the places where they're actually used, instead of preventatively sprinkled throughout every view.
As far as I can see, this wouldn't be a breaking change (since the context doesn't interfere with anything else), and it wouldn't violate any expectations that developers have in the context of rendering server-side templates; if anything, it would meet them more closely.