Adding context processors for templates

[jtraub]

Sometimes all templates share same variables (for example, username to display profile menu in the top right corner or number of items in cart). Straightforward approach would be calculating values and passing them to Template in context kwarg in each route handler.

Better approach would be adding functions that take Request as an argument and return dict that should be merged into template context. These functions should be execute by Starlite before template rendering.

Something like this

def user_info(request: Request):
      return {"username": request.user.name, "role": request.user.role}

template_config.engine.register_template_context_processor(user_info)

# {{ username }} and {{ role }} are now available in every template

Other frameworks offer similar concept:

• View sharing in Masonite
• Context processors in Django
• Context processors in Flask

We already have Template Callables in Starlite which can be used to resolve the problem. However, there are two downsides:

• Callable will be executed each time it is accessed in a template. So the user will have to apply some kind of memoization if a variable they want to share requires expensive computations and is being used multiple times in the template.
• Callable always returns a single value so if computation derives multiple values they should be returned as a dict making templates code more complicated in case you need .

I am hesitant about context processors.

[Goldziher]

why are you hesitent?

[jtraub]

I like to keep API surface small. Template callables kinda solve the problem but require more skill to not become a footgun.

Basically my question boils down to picking between keeping small API or improving user experience.

[provinzkraut]

@jtraub I think this is a worthwhile feature, since it's very commonly used.