Add make_context Jinja context customization option to JinjaTemplate

[volfpeter]

Summary by CodeRabbit

• New Features
  • Jinja templates now accept an optional make_context hook to compute extra context dynamically at render time.
  • The dynamically generated mapping is merged with existing static context, with slot content retaining priority.
• Bug Fixes
  • Slot context handling is now consistent (the slots entry is set even when no slots are provided).
  • Dynamic context can override non-slot fields (e.g., title) without affecting slot values.
• Tests
  • Expanded Jinja template coverage to validate make_context behavior and precedence rules.
• Chores
  • Bumped package version to 0.12.1.

[coderabbitai]

Warning

Review limit reached

@volfpeter, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 9b0cb3cb-79bc-45c6-9e63-8e2b39b255d0

📥 Commits

Reviewing files that changed from the base of the PR and between baec9c3 and 96f3f97.

📒 Files selected for processing (1)

• tests/test_jinja.py

📝 Walkthrough

Walkthrough

Adds an optional make_context callable to JinjaTemplate, introduces a new JinjaContextFactory type alias, updates reserved slot handling, extends tests, and bumps the package version.

Changes

make_context feature

Layer / File(s)	Summary
JinjaContextFactory type alias and imports htmy/jinja.py	Adds Callable/TypeAlias imports and defines the JinjaContextFactory type alias.
JinjaTemplate constructor and render wiring htmy/jinja.py	Adds make_context storage to JinjaTemplate, merges make_context(context) into the render context, and always sets the slots entry.
Tests for make_context behavior tests/test_jinja.py	Expands the parametrized coverage with make_context, including cases for static context overrides and reserved slots.
Package version bump htmy/__init__.py	Updates __version__ from 0.12.0 to 0.12.1.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Caller
  participant JinjaTemplate
  participant JinjaEnvironment

  Caller->>JinjaTemplate: htmy(context)
  JinjaTemplate->>JinjaTemplate: build jinja_context
  alt make_context provided
    JinjaTemplate->>JinjaTemplate: update context with make_context(context)
  end
  JinjaTemplate->>JinjaTemplate: apply reserved slots
  JinjaTemplate->>JinjaEnvironment: render template with context
  JinjaEnvironment-->>Caller: rendered output

Loading

Possibly related PRs

• volfpeter/htmy#110: Introduced the Jinja support implementation in htmy/jinja.py that this PR directly extends with the make_context feature.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: adding a make_context customization option to JinjaTemplate.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jinja-make_context

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

htmy/jinja.py (1)

93-124: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Always reserve slots in the final Jinja context
make_context can still leave a "slots" entry behind when no template slots are rendered, so the reserved key isn’t consistently enforced. Setting jinja_context["slots"] = slots unconditionally would match the documented precedence, though it does change behavior for callers that intentionally provide their own "slots" value.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@htmy/jinja.py` around lines 93 - 124, The final Jinja context does not
consistently reserve the slots key because make_context can leave an existing
"slots" entry when no template slots are rendered. Update the Jinja context
assembly in htmy/jinja.py so the rendering path always assigns the reserved
"slots" entry after _build_context() and make_context, using the slots value
from __init__ and enforcing the documented precedence in the Jinja template
context.

🧹 Nitpick comments (1)

tests/test_jinja.py (1)

3-3: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Consider typing make_context with JinjaContextFactory instead of Any.

Other parameters (jinja_context, slots, default_slots) use precise Mapping/None types; make_context: Any loses type-checking benefit here since JinjaContextFactory is already exported from htmy.jinja.

♻️ Proposed refactor

-from typing import Any
+from htmy.jinja import JinjaContextFactory

-    make_context: Any,
+    make_context: JinjaContextFactory | None,

Also applies to: 143-144

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/test_jinja.py` at line 3, The type annotation for make_context is too
broad and should use JinjaContextFactory instead of Any, matching the other
precise parameter types already used in this test. Update the relevant test
setup in test_jinja to import and apply JinjaContextFactory from htmy.jinja, and
make the same typing adjustment where make_context is repeated in the other
referenced spots so type checking remains effective.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@htmy/jinja.py`:
- Around line 93-124: The final Jinja context does not consistently reserve the
slots key because make_context can leave an existing "slots" entry when no
template slots are rendered. Update the Jinja context assembly in htmy/jinja.py
so the rendering path always assigns the reserved "slots" entry after
_build_context() and make_context, using the slots value from __init__ and
enforcing the documented precedence in the Jinja template context.

---

Nitpick comments:
In `@tests/test_jinja.py`:
- Line 3: The type annotation for make_context is too broad and should use
JinjaContextFactory instead of Any, matching the other precise parameter types
already used in this test. Update the relevant test setup in test_jinja to
import and apply JinjaContextFactory from htmy.jinja, and make the same typing
adjustment where make_context is repeated in the other referenced spots so type
checking remains effective.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8f578451-8457-4ff0-a2ea-ee746bb9ec5b

📥 Commits

Reviewing files that changed from the base of the PR and between 6ddc432 and b6228a9.

📒 Files selected for processing (3)

• htmy/__init__.py
• htmy/jinja.py
• tests/test_jinja.py