Add request argument to TemplateResponse#2191
Conversation
request argument to TemplateResponse
Kludex
left a comment
There was a problem hiding this comment.
This is a breaking change.
Please make both request and context optional, and raise a deprecation warning when the "request" is in the context.
Actually, the request must be the first argument. TemplateResponse(request, 'index.html', {})
TemplateResponse('index.html', request, {}) |
"Must" is a bit strong, isn't it? 👀 I don't think the argument here justifies the breaking change. It's just cosmetics. |
Can you suggest an alternative? Seems that I am stuck.. |
|
Hmm... I was writing a huge text as to why my last suggestion was the only one... And I actually got an idea... 🤔 You can make the two first arguments as
My guess is this is going to look hideous, but it's not a breaking change, and we can easily remove all this logic on 1.0. |
|
Okay, it worked. The code is a bit ugly but it's okay for the transition period. |
Eh... Yeah... It was within my predictions hahaha Would you like to open a PR against this already to show how it would look like on 1.0? I think it will make it easier to get this in. |
Kludex
left a comment
There was a problem hiding this comment.
I've added some comments. @alex-oleshkevich Can you check them, please?
| ) -> _TemplateResponse: | ||
| if "request" not in context: | ||
| raise ValueError('context must include a "request" key') | ||
| # Deprecated usage |
There was a problem hiding this comment.
Unfortunately, we can't use @typing_extensions.deprecated without making typing_extensions mandatory for Starlette.
Also, the @deprecated PEP was still not accepted.
There was a problem hiding this comment.
yes, so we have a comment here.
There was a problem hiding this comment.
yeah yeah, just explaining for future reference 👀
|
|
||
| async def homepage(request): | ||
| return templates.TemplateResponse('index.html', {'request': request}) | ||
| return templates.TemplateResponse(request, 'index.html') |
There was a problem hiding this comment.
Is this the only thing in the documentation that uses TemplateResponse?
| if "request" not in kwargs.get("context", {}): | ||
| raise ValueError('context must include a "request" key') |
There was a problem hiding this comment.
This error is being raised with the warning above, can we make sure we only have the warning if this doesn't raise?
There was a problem hiding this comment.
This preserves current behavior.
Co-authored-by: Marcelo Trylesinski <marcelotryle@gmail.com>
Co-authored-by: Marcelo Trylesinski <marcelotryle@gmail.com>
…ette into templates-request
|
Thanks @alex-oleshkevich 🙏 For the record, this was accepted given that it is not a breaking change, and that we already have a follow-up PR to clean-up everything for V1: #2199. 🙏 The idea is to warn the users now, and then remove the |
Addresses jowilf#574 DeprecationWarning: The `name` is not the first parameter anymore. The first parameter should be the `Request` instance. Replace `TemplateResponse(name, {"request": request})` by `TemplateResponse(request, name)`. warnings.warn( Before Starlette 0.29.0, the name was the first parameter. Also, before that, in previous versions, the request object was passed as part of the key-value pairs in the context for Jinja2. See: - https://www.starlette.io/release-notes/#0290 - Kludex/starlette#2191 - https://github.com/encode/starlette/blob/c78c9aac17a4d68e0647252310044502f1b7da71/starlette/templating.py#L166-L178 - https://fastapi.tiangolo.com/reference/templating/#fastapi.templating.Jinja2Templates.TemplateResponse - https://fastapi.tiangolo.com/advanced/templates/#using-jinja2templates
* Ignore .venv * Fix DeprecationWarning: The `name` is not the first parameter anymore. Addresses #574 DeprecationWarning: The `name` is not the first parameter anymore. The first parameter should be the `Request` instance. Replace `TemplateResponse(name, {"request": request})` by `TemplateResponse(request, name)`. warnings.warn( Before Starlette 0.29.0, the name was the first parameter. Also, before that, in previous versions, the request object was passed as part of the key-value pairs in the context for Jinja2. See: - https://www.starlette.io/release-notes/#0290 - Kludex/starlette#2191 - https://github.com/encode/starlette/blob/c78c9aac17a4d68e0647252310044502f1b7da71/starlette/templating.py#L166-L178 - https://fastapi.tiangolo.com/reference/templating/#fastapi.templating.Jinja2Templates.TemplateResponse - https://fastapi.tiangolo.com/advanced/templates/#using-jinja2templates * Fix DeprecationWarning: Extra environment options are deprecated. Resolves #574 According to the Starlette 0.28.0 release notes, the **env_options parameter in Jinja2Templates has been deprecated in favor of the new env parameter. The relevant pull request #2159 explains this change. See: - Kludex/starlette#2159 - https://www.starlette.io/release-notes/#0280 * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
The previous implementation was too complex and difficult to understand. Bug introduced in Kludex/starlette#2191, found in Kludex/starlette#2906.
This PR makes
requesta required argument toTemplateResponse.Also, as the request is now passed explicitly, the template context can be optional.
Why?
The
requestis mandatory in the template response. However, the class requires the request to be passed viacontextand there are asserts to check it. I found it better to pass therequestexplicitly. It is similar to what Django does.Was
Become
This is a breaking change.
Ref #2174
EDIT [@Kludex]: This is not a breaking change anymore - It now introduces deprecation warnings instead.