If you'd like to discuss your feature idea first with the community (highly recommended!) please visit our Discord channel.
Is your feature request related to a problem? Please describe.
I believe hardcoding route strings directly in FastHTML's hx_* attributes is poor practice, especially as projects grow larger and undergo early‑stage iteration. This creates significant friction when distinguishing view vs. action routes, refactoring paths, or maintaining consistent routing across the codebase.
Most full‑stack frameworks provide a reverse‑routing mechanism to solve this problem, but I have not found an equivalent function in FastHTML.
Describe the solution you'd like
I initially planned to request a url_for(name: str) utility function that returns the URL for a named route.
However, I was pleasantly surprised to discover that hx_* attributes already support passing route functions directly, as they are implicitly converted to strings. The following example works perfectly:
from fasthtml.common import (
fast_app,
Div,
P,
serve,
Button,
Main,
H1,
A,
Form,
Input,
Title,
)
app, router = fast_app()
count = 0
@router("/")
def home():
return Title("Count Demo"), Main(
H1("Count Demo"),
P(f"Count is set to {count}", id="count"),
Button(
"Increment", hx_post=str(increment), hx_target="#count", hx_swap="innerHTML"
),
)
@router("/increment")
def increment():
print(increment, type(increment))
print("incrementing")
global count
count += 1
return f"Count is set to {count}"
serve()
In other words, FastHTML already supports reverse routing: simply convert a route function to a string with str(), and the result is its corresponding path, which can then be passed to hx_post and similar attributes.
Therefore, my proposal has evolved. I would like the maintainers to evaluate the validity of this pattern and consider:
- Automatically converting values passed to
hx_post, hx_get, hx_put, etc., to strings internally, so users no longer need to explicitly call str().
- Updating the type annotations for
hx_post, hx_get, hx_put, and related attributes to accept route functions directly.
Example code
from fasthtml.common import (
fast_app,
Div,
P,
serve,
Button,
Main,
H1,
A,
Form,
Input,
Title,
)
app, router = fast_app()
count = 0
@router("/")
def home():
return Title("Count Demo"), Main(
H1("Count Demo"),
P(f"Count is set to {count}", id="count"),
# NOTE: hx_post directly accepts the increment function and converts it to str internally
Button(
"Increment", hx_post=increment, hx_target="#count", hx_swap="innerHTML"
),
)
@router("/increment")
def increment():
print(increment, type(increment))
print("incrementing")
global count
count += 1
return f"Count is set to {count}"
serve()
Similar implementations
If available, provide links to similar features in other libraries:
- Library Name
- Another Library
Problem solved
This improvement eliminates the need to hardcode route strings throughout the codebase, enabling type‑safe, refactor‑friendly reverse routing. Users will benefit from fewer routing errors, easier path renaming, cleaner code, and better IDE support when referencing routes. It aligns FastHTML’s syntax with modern full‑stack framework conventions while leveraging existing internal behavior.
Additional context
This pattern already works today with explicit str() conversion, suggesting the underlying implementation is stable. Formalizing it would improve developer experience without breaking changes.
Confirmation
Please confirm the following:
If you'd like to discuss your feature idea first with the community (highly recommended!) please visit our Discord channel.
Is your feature request related to a problem? Please describe.
I believe hardcoding route strings directly in FastHTML's
hx_*attributes is poor practice, especially as projects grow larger and undergo early‑stage iteration. This creates significant friction when distinguishing view vs. action routes, refactoring paths, or maintaining consistent routing across the codebase.Most full‑stack frameworks provide a reverse‑routing mechanism to solve this problem, but I have not found an equivalent function in FastHTML.
Describe the solution you'd like
I initially planned to request a
url_for(name: str)utility function that returns the URL for a named route.However, I was pleasantly surprised to discover that
hx_*attributes already support passing route functions directly, as they are implicitly converted to strings. The following example works perfectly:In other words, FastHTML already supports reverse routing: simply convert a route function to a string with
str(), and the result is its corresponding path, which can then be passed tohx_postand similar attributes.Therefore, my proposal has evolved. I would like the maintainers to evaluate the validity of this pattern and consider:
hx_post,hx_get,hx_put, etc., to strings internally, so users no longer need to explicitly callstr().hx_post,hx_get,hx_put, and related attributes to accept route functions directly.Example code
# Your example code hereSimilar implementations
If available, provide links to similar features in other libraries:
Problem solved
This improvement eliminates the need to hardcode route strings throughout the codebase, enabling type‑safe, refactor‑friendly reverse routing. Users will benefit from fewer routing errors, easier path renaming, cleaner code, and better IDE support when referencing routes. It aligns FastHTML’s syntax with modern full‑stack framework conventions while leveraging existing internal behavior.
Additional context
This pattern already works today with explicit
str()conversion, suggesting the underlying implementation is stable. Formalizing it would improve developer experience without breaking changes.Confirmation
Please confirm the following: