v2.1.1

What's Changed

• Fix Response handling in page() decorator by @volfpeter in #49

Full Changelog: v2.1.0...v2.1.1

v2.1.0

What's Changed

• HTMY integration by @volfpeter in #43
• Jinja doc improvements by @volfpeter in #41

Full Changelog: v2.0.2...v2.1.0

v2.0.2

What's Changed

• Jinja error rendering fix by @volfpeter in #40
• ComponentSelector typing improvement by @volfpeter in #40

Full Changelog: v2.0.1...v2.0.2

v2.0.1

What's Changed

• Workaround for a FastAPI dependency resolution bug by @volfpeter in #37

Full Changelog: v2.0.0...v2.0.1

v2.0.0 PyPI upload

Merge pull request #33 from volfpeter/v2-release-prep

V2 release prep

v2.0.0

What's Changed

Features:

• Both the core (hx() and page()) decorators and the Jinja integration got support for error rendering. Fixes #28, by @volfpeter
• Response status code and background job are preserved (if set on the Response dependency for example in a route). Fixes #26 #27, by @volfpeter
• Added a JinjaPath utility, see docs for details, by @volfpeter
• Added the Jinja.no_data property, by @volfpeter
• The RequestComponentSelector protocol and the ComponentSelector type are generic now to allow more flexible integrations, by @volfpeter
• RequestComponentSelector.get_component_id() was renamed to RequestComponentSelector.get_component() as a consequence of the above change, by @volfpeter
• More documentation, by @volfpeter
• Added migration guide by @volfpeter

Full Changelog: v1.1.1...v2.0.0

Migration summary (from v1)

• If you have custom RequestComponentSelector implementations:
  • Rename get_component_id() methods to get_component() and add the new error: Exception | None argument to the methods.
  • Well-behaved RequestComponentSelectors that dont's support error rendering should reraise the received error if it's not None (although not doing so will not break anything as result and errors are clearly separated in Jinja and the core decorators don't rely on this protocol).
• If you've overridden any of the protected methods of Jinja, please go through this PR so you can upgrade your custom implementation.
• If you've written a custom integration, just add the required generic type to ComponentSelector type hints.

v2.0.0-rc3

Changes

• Added the Jinja.no_data property by @volfpeter in #32

Full Changelog: v2.0.0-rc2...v2.0.0-rc3

v2.0.0-rc2

Changes (breaking):

• The RequestComponentSelector protocol and the ComponentSelector type are generic now to allow more flexible integrations.
• RequestComponentSelector.get_component_id() was renamed to RequestComponentSelector.get_component() as a consequence of the above change.

How to migrate from 2.0.0-rc1:

• If you have custom component selector implementations, just rename your RequestComponentSelector.get_component_id() methods to RequestComponentSelector.get_component().
• If you've written a custom integration, just add the required generic type to ComponentSelector type hints.

PRs

• Added a migration guide to the docs by @volfpeter in #30
• Generic RequestComponentSelector protocol by @volfpeter in #31

Full Changelog: v2.0.0-rc1...v2.0.0-rc2

v2.0.0-rc1

What's Changed

Features:

• Both the core (hx() and page()) decorators and the Jinja integration got support for error rendering. Fixes #28.
• Response status code and background job are preserved (if set on the Response dependency for example in a route). Fixes #26 #27.
• Added a JinjaPath utility, see docs for details.

Breaking changes:

• To support error rendering, the RequestComponentSelector protocol got a second argument (error: Exception | None).
• The internals of Jinja changed slightly.

How to upgrade:

• If you have custom RequestComponentSelector implementations, then please add the new argument to the get_component_id() method. Well-behaved RequestComponentSelectors that don's support error rendering should reraise the received error if it's not None (although not doing so will not break anything as result and errors are clearly separated in Jinja and the core decorators don't rely on this protocol).
• If you've overridden any of the protected methods of Jinja, please go through this PR so you can upgrade your custom implementation.

Full Changelog: v1.1.1...v2.0.0-rc1

v1.1.1

What's Changed

• More JinjaContext utilities by @volfpeter in #25

Full Changelog: v1.1.0...v1.1.1