Add ergonomic control over behaviour of missing variables in templates

[LilyAcorn]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Introduce ! as an explicit marker that a template variable is required to exist in the context.
Introduce ? as an explicit marker that a template variable is optional. (Django's default behaviour.)

Problem

Templates silently convert missing variables to an empty string. This behaviour is useful in many situations:

• Pages still render instead of returning a 500 error when a minor programming error is made.
• Template authors can deliberately design a section to be omitted when variables are not in the context.

However, this implicit behaviour is inconvenient for people who want to get an error during development when a variable that should always be present is omitted by mistake. By adding explicit syntax for required and optional variables, we give developers and teams extra control to opt-in to the desired behaviour where appropriate.

Request or proposal

proposal

Additional Details

This has been discussed on the forum: https://forum.djangoproject.com/t/raise-error-for-missing-variable-used-in-template/39776
This could also resolve this accepted ticket.

Implementation Suggestions

Instead of:

{{ name }}
{{ biography }}

we could allow:

{{ name! }}
{{ biography? }}

and name would be required whereas biography would be optional.

[github-actions]

Thank you LilyFoote for sharing your idea! We have a lot of them so please be patient. You can see the current queue here. If you'd like to learn about other ways to get this idea more attention, please see this page.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[tim-schilling]

How do you envision this working with template inheritance?

[LilyAcorn]

I'm not sure this would need to do anything special with template inheritance. Do you have any specific examples in mind where you think there might be a problem?

[tim-schilling]

I don't know if it'll be a problem. I'm thinking a parent template from another library has a variable as required and the developer isn't aware of it. Adding a required variable to templates that are already in use would probably be a backwards incompatible change.

[LilyAcorn]

Right! I think that would be a decision for projects defining those templates to make on how they want to handle the change. In Django itself, I think we'd be pretty cautious about it.

[sergei-maertens]

What would happen with filters applied to optional variables? I'm not even sure what happens now when a variable is undefined - does the empty string get passed down to the filters?

I see an opportunity here to maybe short circuit filter evaluation if the variable is undefined, similar to the JS ?. operator.

I'm a little bit concerned about readability though, especially the exclamation mark being quite similar to the pipe symbol.

[LilyAcorn]

What would happen with filters applied to optional variables? I'm not even sure what happens now when a variable is undefined - does the empty string get passed down to the filters?

The current behaviour is: an undefined variable becomes an empty string, unless string_if_invalid is set, in which case that is used instead. This is then passed to the filter. If a variable is used as an argument to a filter (after a :) then an exception would bubble up.

For the new behaviour, I think we'd want the undefined variable to become ''. I can see an argument for None, but I think an empty string would make adding ? to existing templates more straightforward.

I see an opportunity here to maybe short circuit filter evaluation if the variable is undefined, similar to the JS ?. operator.

Potentially, yes.

I'm a little bit concerned about readability though, especially the exclamation mark being quite similar to the pipe symbol.

Yeah, this is something I'm concerned about too, but I'm not sure the alternative of a named filter (undefined|optional) is any better - in more complicated scenarios it could be overwhelmingly verbose. I think this will need exploration - perhaps looking at examples in the admin templates?

[tim-schilling]

In Django itself, I think we'd be pretty cautious about it.

Is it even possible to use this in django the same release it comes out? The templates we'd use it in would have to be ones we're confident aren't being inherited from.

[nanuxbe]

We have moved this issue forward, so the next step here would be to assert how valuable it would be to write this as a third-party package.

@LilyAcorn now would be a good time to ask for participants if you need a team to help with this feature?

[rixx]

The discussion linked in the issue above raises an interesting point, in that adopting this syntax has the potential of being very noisy, by basically making it best practice to add ! to (nearly) all variables. I still voted for this issue (any way to enforce variables to exist is better than none), I just wanted to raise it to avoid it getting lost in the forum → GitHub transition.