-
Notifications
You must be signed in to change notification settings - Fork 262
Feature request: Locals as a context #137
Comments
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 |
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. |
I have the same issue, I want all components in any view to be able to access a Any word from the Devs on what's happening with this? I love using Update (29/12/19): Nvm just me being dumb, |
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:
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:Code that actually needs the template locals - possibly nested a few levels deep - could then do something like the following:
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.
The text was updated successfully, but these errors were encountered: