Skip to content
This repository has been archived by the owner on Feb 1, 2022. It is now read-only.

Feature request: Locals as a context #137

Open
joepie91 opened this issue Dec 12, 2018 · 3 comments
Open

Feature request: Locals as a context #137

joepie91 opened this issue Dec 12, 2018 · 3 comments

Comments

@joepie91
Copy link

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.

@greguintow
Copy link

I am with the same problem I want to show success, errors, info or warning messages and until find how to access the locals variables from a component, will be necessary to put the variables into each page from view

@joepie91
Copy link
Author

I've now published a fork with this feature.

I've not submitted a PR to this repository, as I'm not wiling to sign CLAs. The maintainer(s) should feel free to absorb those changes into this repository under the licenses stated there (which allows relicensing), though.

@geist-2501
Copy link

geist-2501 commented Dec 29, 2019

I have the same issue, I want all components in any view to be able to access a props.locals.user object for displaying user data, and right now the only way I can figure out how to do that is to pass arguments to every res.render and then modify all my components to pass the props.local down manually.

Any word from the Devs on what's happening with this? I love using express-react-views for templating but this makes it unsuitable for anything big 😖. Unless I just can't figure put how to use global props properly?

Update (29/12/19): Nvm just me being dumb, props.locals does get passed, it's just not global and still has to get passed down.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants