htmy 0.5.0__tar.gz → 0.6.0__tar.gz

{htmy-0.5.0 → htmy-0.6.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: htmy
-Version: 0.5.0
+Version: 0.6.0
 Summary: Async, pure-Python rendering engine.
 License: MIT
 Author: Peter Volf
@@ -30,13 +30,15 @@ Description-Content-Type: text/markdown
 
 **Async**, **pure-Python** rendering engine.
 
+Unleash your creativity with the full power and Python, without the hassle of learning a new templating language or dealing with its limitations!
+
 ## Key features
 
 - **Async**-first, to let you make the best use of [modern async tools](https://github.com/timofurrer/awesome-asyncio).
 - **Powerful**, React-like **context support**, so you can avoid prop-drilling.
 - Sync and async **function components** with **decorator syntax**.
 - All baseline **HTML** tags built-in.
-- Support for **native HTML/XML** documents with dynamic formatting and **slot rendering**.
+- Support for **native HTML/XML** documents with dynamic formatting and **slot rendering**, **without custom syntax**.
 - **Markdown** support with tools for customization.
 - Async, JSON based **internationalization**.
 - Built-in, easy to use `ErrorBoundary` component for graceful error handling.
@@ -45,6 +47,10 @@ Description-Content-Type: text/markdown
 - Automatic and customizable **property-name conversion** from snake case to kebab case.
 - **Fully-typed**.
 
+## Support
+
+Consider supporting the development and maintenance of the project through [sponsoring](https://buymeacoffee.com/volfpeter), or reach out for [consulting](https://www.volfp.com/contact?subject=Consulting%20-%20HTMY) so you can get the most out of the library.
+
 ## Installation
 
 The package is available on PyPI and can be installed with:
@@ -61,9 +67,9 @@ Also, the library doesn't rely on advanced Python features such as metaclasses o
 
 ### Components
 
-Every class with a sync or async `htmy(context: Context) -> Component` method is an `htmy` component (technically an `HTMYComponentType`). Strings are also components, as well as lists or tuples of `HTMYComponentType` or string objects.
+Every object with a sync or async `htmy(context: Context) -> Component` method is an `htmy` component (technically an `HTMYComponentType`). Strings are also components, as well as lists or tuples of `HTMYComponentType` or string objects. In many cases though, you don't even need to create components, simple functions that return components will be sufficient -- you can find out more about this in the [Components guide](https://volfpeter.github.io/htmy/components-guide/) of the documentation.
 
-Using this method name enables the conversion of any of your business objects (from `TypedDicts`s or `pydantic` models to ORM classes) into components without the fear of name collision with other tools.
+Using the `htmy()` method name enables the conversion of any of your pre-existing business objects (from `TypedDicts`s or `pydantic` models to ORM classes) into components without the fear of name collision or compatibility issues with other tools.
 
 Async support makes it possible to load data or execute async business logic right in your components. This can reduce the amount of boilerplate you need to write in some cases, and also gives you the freedom to split the rendering and non-rendering logic in any way you see fit.
 
@@ -205,7 +211,7 @@ if __name__ == "__main__":
 
 As you could see from the code examples above, every component has a `context: Context` argument, which we haven't used so far. Context is a way to share data with the entire subtree of a component without "prop drilling".
 
-The context (technically a `Mapping`) is entirely managed by the renderer. Context provider components (any class with a sync or async `htmy_context() -> Context` method) add new data to the context to make it available to components in their subtree, and components can simply take what they need from the context.
+The context (technically a `Mapping`) is entirely managed by the renderer. Context provider components (any class with a sync or async `htmy_context() -> Context` method) add new data to the context to make it available to components in their subtree (including themselves), and components can simply take what they need from the context.
 
 There is no restriction on what can be in the context, it can be used for anything the application needs, for example making the current user, UI preferences, themes, or formatters available to components. In fact, built-in components get their `Formatter` from the context if it contains one, to make it possible to customize tag property name and value formatting.
 
@@ -306,13 +312,13 @@ FastAPI:
 
 At one end of the spectrum, there are the complete application frameworks that combine the server (Python) and client (JavaScript) applications with the entire state management and synchronization into a single Python (an in some cases an additional JavaScript) package. Some of the most popular examples are: [Reflex](https://github.com/reflex-dev/reflex), [NiceGUI](https://github.com/zauberzeug/nicegui/), [ReactPy](https://github.com/reactive-python/reactpy), and [FastUI](https://github.com/pydantic/FastUI).
 
-The main benefit of these frameworks is rapid application prototyping and a very convenient developer experience (at least as long as you stay within the built-in feature set of the framework). In exchange for that, they are very opinionated (from components to frontend tooling and state management), the underlying engineering is very complex, deployment and scaling can be hard or costly, and they can be hard to migrate away from. Even with these caveats, they can be a very good choice for internal tools and application prototyping.
+The main benefit of these frameworks is rapid application prototyping and a very convenient developer experience, at least as long as you stay within the built-in feature set of the framework. In exchange for that, they are very opinionated (from components to frontend tooling and state management), the underlying engineering is very complex, deployment and scaling can be hard or costly, and they can be hard to migrate away from. Even with these caveats, they can be a very good choice for internal tools and application prototyping.
 
-The other end of spectrum -- plain rendering engines -- is dominated by the [Jinja](https://jinja.palletsprojects.com) templating engine, which is a safe choice as it has been and will be around for a long time. The main drawbacks with Jinja are the lack of good IDE support, the complete lack of static code analysis support, and the (subjectively) ugly syntax.
+The other end of spectrum -- plain rendering engines -- is dominated by the [Jinja](https://jinja.palletsprojects.com) templating engine, which is a safe choice as it has been and will be around for a long time. The main drawbacks with Jinja are the lack of good IDE support, the complete lack of static code analysis support, and the (subjectively) ugly custom template syntax.
 
 Then there are tools that aim for the middleground, usually by providing most of the benefits and drawbacks of complete application frameworks while leaving state management, client-server communication, and dynamic UI updates for the user to solve, often with some level of [HTMX](https://htmx.org/) support. This group includes libraries like [FastHTML](https://github.com/answerdotai/fasthtml) and [Ludic](https://github.com/getludic/ludic).
 
-The primary aim of `htmy` is to be an **async**, pure-Python rendering engine, which is as **simple**, **maintainable**, and **customizable** as possible, while still providing all the building blocks for (conveniently) creating complex and maintainable applications.
+The primary aim of `htmy` is to be a `Jinja` alternative that is similarly powerful and flexible, while also providing the benefits of full IDE support, static code analysis, and native Python (and HTML, XML, markdown) syntax. Additionally, `htmy` is **async-first**, so it works great with modern async Python frameworks such as [FastAPI](https://fastapi.tiangolo.com). The library was designed to be as **simple**, **maintainable**, and **customizable** as possible, while still providing all the building blocks for creating complex web applications.
 
 ## Dependencies
 
@@ -330,7 +336,13 @@ The documentation is built with `mkdocs-material` and `mkdocstrings`.
 
 ## Contributing
 
-All contributions are welcome, including more documentation, examples, code, and tests. Even questions.
+We welcome contributions from the community to help improve the project! Whether you're an experienced developer or just starting out, there are many ways you can contribute:
+
+- **Discuss**: Join our [Discussion Board](https://github.com/volfpeter/htmy/discussions) to ask questions, share ideas, provide feedback, and engage with the community.
+- **Document**: Help improve the documentation by fixing typos, adding examples, and updating guides to make it easier for others to use the project.
+- **Develop**: Prototype requested features or pick up issues from the issue tracker.
+- **Share**: Share your own project by adding a link to it in the documentation, helping others discover and benefit from your work.
+- **Test**: Write tests to improve coverage and enhance reliability.
 
 ## License - MIT
 

{htmy-0.5.0 → htmy-0.6.0}/README.md

@@ -11,13 +11,15 @@
 
 **Async**, **pure-Python** rendering engine.
 
+Unleash your creativity with the full power and Python, without the hassle of learning a new templating language or dealing with its limitations!
+
 ## Key features
 
 - **Async**-first, to let you make the best use of [modern async tools](https://github.com/timofurrer/awesome-asyncio).
 - **Powerful**, React-like **context support**, so you can avoid prop-drilling.
 - Sync and async **function components** with **decorator syntax**.
 - All baseline **HTML** tags built-in.
-- Support for **native HTML/XML** documents with dynamic formatting and **slot rendering**.
+- Support for **native HTML/XML** documents with dynamic formatting and **slot rendering**, **without custom syntax**.
 - **Markdown** support with tools for customization.
 - Async, JSON based **internationalization**.
 - Built-in, easy to use `ErrorBoundary` component for graceful error handling.
@@ -26,6 +28,10 @@
 - Automatic and customizable **property-name conversion** from snake case to kebab case.
 - **Fully-typed**.
 
+## Support
+
+Consider supporting the development and maintenance of the project through [sponsoring](https://buymeacoffee.com/volfpeter), or reach out for [consulting](https://www.volfp.com/contact?subject=Consulting%20-%20HTMY) so you can get the most out of the library.
+
 ## Installation
 
 The package is available on PyPI and can be installed with:
@@ -42,9 +48,9 @@ Also, the library doesn't rely on advanced Python features such as metaclasses o
 
 ### Components
 
-Every class with a sync or async `htmy(context: Context) -> Component` method is an `htmy` component (technically an `HTMYComponentType`). Strings are also components, as well as lists or tuples of `HTMYComponentType` or string objects.
+Every object with a sync or async `htmy(context: Context) -> Component` method is an `htmy` component (technically an `HTMYComponentType`). Strings are also components, as well as lists or tuples of `HTMYComponentType` or string objects. In many cases though, you don't even need to create components, simple functions that return components will be sufficient -- you can find out more about this in the [Components guide](https://volfpeter.github.io/htmy/components-guide/) of the documentation.
 
-Using this method name enables the conversion of any of your business objects (from `TypedDicts`s or `pydantic` models to ORM classes) into components without the fear of name collision with other tools.
+Using the `htmy()` method name enables the conversion of any of your pre-existing business objects (from `TypedDicts`s or `pydantic` models to ORM classes) into components without the fear of name collision or compatibility issues with other tools.
 
 Async support makes it possible to load data or execute async business logic right in your components. This can reduce the amount of boilerplate you need to write in some cases, and also gives you the freedom to split the rendering and non-rendering logic in any way you see fit.
 
@@ -186,7 +192,7 @@ if __name__ == "__main__":
 
 As you could see from the code examples above, every component has a `context: Context` argument, which we haven't used so far. Context is a way to share data with the entire subtree of a component without "prop drilling".
 
-The context (technically a `Mapping`) is entirely managed by the renderer. Context provider components (any class with a sync or async `htmy_context() -> Context` method) add new data to the context to make it available to components in their subtree, and components can simply take what they need from the context.
+The context (technically a `Mapping`) is entirely managed by the renderer. Context provider components (any class with a sync or async `htmy_context() -> Context` method) add new data to the context to make it available to components in their subtree (including themselves), and components can simply take what they need from the context.
 
 There is no restriction on what can be in the context, it can be used for anything the application needs, for example making the current user, UI preferences, themes, or formatters available to components. In fact, built-in components get their `Formatter` from the context if it contains one, to make it possible to customize tag property name and value formatting.
 
@@ -287,13 +293,13 @@ FastAPI:
 
 At one end of the spectrum, there are the complete application frameworks that combine the server (Python) and client (JavaScript) applications with the entire state management and synchronization into a single Python (an in some cases an additional JavaScript) package. Some of the most popular examples are: [Reflex](https://github.com/reflex-dev/reflex), [NiceGUI](https://github.com/zauberzeug/nicegui/), [ReactPy](https://github.com/reactive-python/reactpy), and [FastUI](https://github.com/pydantic/FastUI).
 
-The main benefit of these frameworks is rapid application prototyping and a very convenient developer experience (at least as long as you stay within the built-in feature set of the framework). In exchange for that, they are very opinionated (from components to frontend tooling and state management), the underlying engineering is very complex, deployment and scaling can be hard or costly, and they can be hard to migrate away from. Even with these caveats, they can be a very good choice for internal tools and application prototyping.
+The main benefit of these frameworks is rapid application prototyping and a very convenient developer experience, at least as long as you stay within the built-in feature set of the framework. In exchange for that, they are very opinionated (from components to frontend tooling and state management), the underlying engineering is very complex, deployment and scaling can be hard or costly, and they can be hard to migrate away from. Even with these caveats, they can be a very good choice for internal tools and application prototyping.
 
-The other end of spectrum -- plain rendering engines -- is dominated by the [Jinja](https://jinja.palletsprojects.com) templating engine, which is a safe choice as it has been and will be around for a long time. The main drawbacks with Jinja are the lack of good IDE support, the complete lack of static code analysis support, and the (subjectively) ugly syntax.
+The other end of spectrum -- plain rendering engines -- is dominated by the [Jinja](https://jinja.palletsprojects.com) templating engine, which is a safe choice as it has been and will be around for a long time. The main drawbacks with Jinja are the lack of good IDE support, the complete lack of static code analysis support, and the (subjectively) ugly custom template syntax.
 
 Then there are tools that aim for the middleground, usually by providing most of the benefits and drawbacks of complete application frameworks while leaving state management, client-server communication, and dynamic UI updates for the user to solve, often with some level of [HTMX](https://htmx.org/) support. This group includes libraries like [FastHTML](https://github.com/answerdotai/fasthtml) and [Ludic](https://github.com/getludic/ludic).
 
-The primary aim of `htmy` is to be an **async**, pure-Python rendering engine, which is as **simple**, **maintainable**, and **customizable** as possible, while still providing all the building blocks for (conveniently) creating complex and maintainable applications.
+The primary aim of `htmy` is to be a `Jinja` alternative that is similarly powerful and flexible, while also providing the benefits of full IDE support, static code analysis, and native Python (and HTML, XML, markdown) syntax. Additionally, `htmy` is **async-first**, so it works great with modern async Python frameworks such as [FastAPI](https://fastapi.tiangolo.com). The library was designed to be as **simple**, **maintainable**, and **customizable** as possible, while still providing all the building blocks for creating complex web applications.
 
 ## Dependencies
 
@@ -311,7 +317,13 @@ The documentation is built with `mkdocs-material` and `mkdocstrings`.
 
 ## Contributing
 
-All contributions are welcome, including more documentation, examples, code, and tests. Even questions.
+We welcome contributions from the community to help improve the project! Whether you're an experienced developer or just starting out, there are many ways you can contribute:
+
+- **Discuss**: Join our [Discussion Board](https://github.com/volfpeter/htmy/discussions) to ask questions, share ideas, provide feedback, and engage with the community.
+- **Document**: Help improve the documentation by fixing typos, adding examples, and updating guides to make it easier for others to use the project.
+- **Develop**: Prototype requested features or pick up issues from the issue tracker.
+- **Share**: Share your own project by adding a link to it in the documentation, helping others discover and benefit from your work.
+- **Test**: Write tests to improve coverage and enhance reliability.
 
 ## License - MIT
 

{htmy-0.5.0 → htmy-0.6.0}/htmy/__init__.py

@@ -12,14 +12,13 @@ from .core import Text as Text
 from .core import WildcardTag as WildcardTag
 from .core import WithContext as WithContext
 from .core import XBool as XBool
-from .core import component as component
 from .core import xml_format_string as xml_format_string
+from .function_component import component as component
 from .renderer import Renderer as Renderer
 from .snippet import Slots as Slots
 from .snippet import Snippet as Snippet
 from .typing import AsyncComponent as AsyncComponent
 from .typing import AsyncContextProvider as AsyncContextProvider
-from .typing import AsyncFunctionComponent as AsyncFunctionComponent
 from .typing import Component as Component
 from .typing import ComponentSequence as ComponentSequence
 from .typing import ComponentType as ComponentType
@@ -27,14 +26,12 @@ from .typing import Context as Context
 from .typing import ContextKey as ContextKey
 from .typing import ContextProvider as ContextProvider
 from .typing import ContextValue as ContextValue
-from .typing import FunctionComponent as FunctionComponent
 from .typing import HTMYComponentType as HTMYComponentType
 from .typing import MutableContext as MutableContext
 from .typing import Properties as Properties
 from .typing import PropertyValue as PropertyValue
 from .typing import SyncComponent as SyncComponent
 from .typing import SyncContextProvider as SyncContextProvider
-from .typing import SyncFunctionComponent as SyncFunctionComponent
 from .utils import as_component_sequence as as_component_sequence
 from .utils import as_component_type as as_component_type
 from .utils import is_component_sequence as is_component_sequence

{htmy-0.5.0 → htmy-0.6.0}/htmy/core.py

@@ -1,25 +1,13 @@
 from __future__ import annotations
 
 import abc
-import asyncio
 import enum
 from collections.abc import Callable, Container
-from typing import TYPE_CHECKING, Any, ClassVar, Generic, TypedDict, cast, overload
+from typing import TYPE_CHECKING, Any, ClassVar, TypedDict, cast
 from xml.sax.saxutils import escape as xml_escape
 from xml.sax.saxutils import quoteattr as xml_quoteattr
 
-from .typing import (
-    AsyncFunctionComponent,
-    Component,
-    ComponentType,
-    Context,
-    ContextKey,
-    ContextValue,
-    FunctionComponent,
-    PropertyValue,
-    SyncFunctionComponent,
-    T,
-)
+from .typing import Component, ComponentType, Context, ContextKey, ContextValue, PropertyValue, T
 from .utils import as_component_type, join_components
 
 if TYPE_CHECKING:
@@ -201,85 +189,6 @@ class ContextAware:
         raise TypeError(f"Invalid context data type for {cls.__name__}.")
 
 
-# -- Function components
-
-
-class SyncFunctionComponentWrapper(Generic[T]):
-    """Base class `FunctionComponent` wrappers."""
-
-    __slots__ = ("_props",)
-
-    _wrapped_function: SyncFunctionComponent[T]
-
-    def __init__(self, props: T) -> None:
-        self._props = props
-
-    def __init_subclass__(cls, *, func: SyncFunctionComponent[T]) -> None:
-        cls._wrapped_function = func
-
-    def htmy(self, context: Context) -> Component:
-        """Renders the component."""
-        # type(self) is necessary, otherwise the wrapped function would be called
-        # with an extra self argument...
-        return type(self)._wrapped_function(self._props, context)
-
-
-class AsyncFunctionComponentWrapper(Generic[T]):
-    """Base class `FunctionComponent` wrappers."""
-
-    __slots__ = ("_props",)
-
-    _wrapped_function: AsyncFunctionComponent[T]
-
-    def __init__(self, props: T) -> None:
-        self._props = props
-
-    def __init_subclass__(cls, *, func: AsyncFunctionComponent[T]) -> None:
-        cls._wrapped_function = func
-
-    async def htmy(self, context: Context) -> Component:
-        """Renders the component."""
-        # type(self) is necessary, otherwise the wrapped function would be called
-        # with an extra self argument...
-        return await type(self)._wrapped_function(self._props, context)
-
-
-@overload
-def component(func: SyncFunctionComponent[T]) -> type[SyncFunctionComponentWrapper[T]]: ...
-
-
-@overload
-def component(func: AsyncFunctionComponent[T]) -> type[AsyncFunctionComponentWrapper[T]]: ...
-
-
-def component(
-    func: FunctionComponent[T],
-) -> type[SyncFunctionComponentWrapper[T]] | type[AsyncFunctionComponentWrapper[T]]:
-    """
-    Decorator that converts the given function into a component.
-
-    Internally this is achieved by wrapping the function in a pre-configured
-    `FunctionComponentWrapper` subclass.
-
-    Arguments:
-        func: The decorated function component.
-
-    Returns:
-        A pre-configured `FunctionComponentWrapper` subclass.
-    """
-
-    if asyncio.iscoroutinefunction(func):
-
-        class AsyncFCW(AsyncFunctionComponentWrapper[T], func=func): ...
-
-        return AsyncFCW
-    else:
-
-        class SyncFCW(SyncFunctionComponentWrapper[T], func=func): ...  # type: ignore[arg-type]
-
-        return SyncFCW
-
-
 # -- Formatting
 
 

htmy-0.6.0/htmy/function_component.py

@@ -0,0 +1,243 @@
+from __future__ import annotations
+
+import asyncio
+from collections.abc import Callable, Coroutine
+from typing import Any, Protocol, TypeAlias, overload
+
+from .typing import AsyncComponent, Component, Context, SyncComponent, T
+
+# -- Typing for "full" function components.
+
+_SyncFunctionComponent: TypeAlias = Callable[[T, Context], Component]
+"""
+Protocol definition for sync function components that have both a properties and a context argument.
+"""
+
+_AsyncFunctionComponent: TypeAlias = Callable[[T, Context], Coroutine[Any, Any, Component]]
+"""
+Protocol definition for async function components that have both a properties and a context argument.
+"""
+
+_FunctionComponent: TypeAlias = _SyncFunctionComponent[T] | _AsyncFunctionComponent[T]
+"""
+Function component type that has both a properties and a context argument.
+"""
+
+# -- Typing for context-only function components.
+
+_ContextOnlySyncFunctionComponent: TypeAlias = Callable[[Context], Component]
+"""
+Protocol definition for sync function components that only have a context argument.
+"""
+
+
+class _DecoratedContextOnlySyncFunctionComponent(SyncComponent, Protocol):
+    """
+    Protocol definition for sync components that are also callable, and return a sync
+    component when called.
+    """
+
+    def __call__(self) -> SyncComponent: ...
+
+
+_ContextOnlyAsyncFunctionComponent: TypeAlias = Callable[[Context], Coroutine[Any, Any, Component]]
+"""
+Protocol definition for async function components that only have a context argument.
+"""
+
+
+class _DecoratedContextOnlyAsyncFunctionComponent(SyncComponent, Protocol):
+    """
+    Protocol definition for async components that are also callable, and return an async
+    component when called.
+    """
+
+    def __call__(self) -> SyncComponent: ...
+
+
+_ContextOnlyFunctionComponent: TypeAlias = (
+    _ContextOnlySyncFunctionComponent | _ContextOnlyAsyncFunctionComponent
+)
+"""
+Function component type that only accepts a context argument.
+"""
+
+_DecoratedContextOnlyFunction: TypeAlias = (
+    _DecoratedContextOnlySyncFunctionComponent | _DecoratedContextOnlyAsyncFunctionComponent
+)
+"""
+Protocol definition for sync or async components that are also callable, and return a sync
+or async component when called.
+"""
+
+
+class ComponentDecorators:
+    """
+    Function component decorators.
+    """
+
+    __slots__ = ()
+
+    # -- FunctionComponent decorator.
+
+    @overload
+    def __call__(self, func: _SyncFunctionComponent[T]) -> Callable[[T], SyncComponent]: ...
+
+    @overload
+    def __call__(self, func: _AsyncFunctionComponent[T]) -> Callable[[T], AsyncComponent]: ...
+
+    def __call__(
+        self,
+        func: _FunctionComponent[T],
+    ) -> Callable[[T], SyncComponent] | Callable[[T], AsyncComponent]:
+        """
+        Decorator that converts the decorated function into one that must be called with
+        the function component's properties and returns a component instance.
+
+        If used on an async function, the resulting component will also be async;
+        otherwise it will be sync.
+
+        Example:
+
+        ```python
+        @component
+        def my_component(props: int, context: Context) -> Component:
+            return html.p(f"Value: {props}")
+
+        async def render():
+           return await Renderer().render(
+               my_component(42)
+           )
+        ```
+
+        Arguments:
+            func: The decorated function.
+
+        Returns:
+            A function that must be called with the function component's properties and
+            returns a component instance. (Or loosly speaking, an `HTMYComponentType` which
+            can be "instantiated" with the function component's properties.)
+        """
+
+        if asyncio.iscoroutinefunction(func):
+
+            def async_wrapper(props: T) -> AsyncComponent:
+                # This function must be async, in case the renderer inspects it to decide how to handle it.
+                async def component(context: Context) -> Component:
+                    return await func(props, context)  # type: ignore[no-any-return]
+
+                component.htmy = component  # type: ignore[attr-defined]
+                return component  # type: ignore[return-value]
+
+            return async_wrapper
+        else:
+
+            def sync_wrapper(props: T) -> SyncComponent:
+                def component(context: Context) -> Component:
+                    return func(props, context)  # type: ignore[return-value]
+
+                component.htmy = component  # type: ignore[attr-defined]
+                return component  # type: ignore[return-value]
+
+            return sync_wrapper
+
+    @overload
+    def function(self, func: _SyncFunctionComponent[T]) -> Callable[[T], SyncComponent]: ...
+
+    @overload
+    def function(self, func: _AsyncFunctionComponent[T]) -> Callable[[T], AsyncComponent]: ...
+
+    def function(
+        self,
+        func: _FunctionComponent[T],
+    ) -> Callable[[T], SyncComponent] | Callable[[T], AsyncComponent]:
+        """
+        Decorator that converts the decorated function into one that must be called with
+        the function component's properties and returns a component instance.
+
+        If used on an async function, the resulting component will also be async;
+        otherwise it will be sync.
+
+        This function is just an alias for `__call__()`.
+
+        Example:
+
+        ```python
+        @component.function
+        def my_component(props: int, context: Context) -> Component:
+            return html.p(f"Value: {props}")
+
+        async def render():
+           return await Renderer().render(
+               my_component(42)
+           )
+
+        Arguments:
+            func: The decorated function.
+
+        Returns:
+            A function that must be called with the function component's properties and
+            returns a component instance. (Or loosly speaking, an `HTMYComponentType` which
+            can be "instantiated" with the function component's properties.)
+        """
+        return self(func)
+
+    # -- ContextOnlyFunctionComponent decorator.
+
+    @overload
+    def context_only(
+        self, func: _ContextOnlySyncFunctionComponent
+    ) -> _DecoratedContextOnlySyncFunctionComponent: ...
+
+    @overload
+    def context_only(
+        self, func: _ContextOnlyAsyncFunctionComponent
+    ) -> _DecoratedContextOnlyAsyncFunctionComponent: ...
+
+    def context_only(
+        self,
+        func: _ContextOnlyFunctionComponent,
+    ) -> _DecoratedContextOnlySyncFunctionComponent | _DecoratedContextOnlyAsyncFunctionComponent:
+        """
+        Decorator that converts the decorated function into a component.
+
+        If used on an async function, the resulting component will also be async;
+        otherwise it will be sync.
+
+        The decorated function will be both a component object and a callable that returns a
+        component object, so it can be used in the component tree both with and without the
+        call signature:
+
+        ```python
+        @component.context_only
+        def my_component(ctx):
+            return "Context only function component."
+
+        async def render():
+           return await Renderer().render(
+               my_component(),  # With call signature.
+               my_component,  # Without call signature.
+           )
+        ```
+
+        Arguments:
+            func: The decorated function.
+
+        Returns:
+            The created component.
+        """
+
+        def wrapper() -> SyncComponent | AsyncComponent:
+            func.htmy = func  # type: ignore[union-attr]
+            return func  # type: ignore[return-value]
+
+        wrapper.htmy = func  # type: ignore[attr-defined]
+        return wrapper  # type: ignore[return-value]
+
+
+component = ComponentDecorators()
+"""
+Decorators for converting functions into components
+
+This is an instance of `ComponentDecorators`.
+"""

{htmy-0.5.0 → htmy-0.6.0}/htmy/typing.py

@@ -65,16 +65,6 @@ ComponentSequence: TypeAlias = list[ComponentType] | tuple[ComponentType, ...]
 Component: TypeAlias = ComponentType | ComponentSequence
 """Component type: a single component or a sequence of components."""
 
-
-SyncFunctionComponent: TypeAlias = Callable[[T, Context], Component]
-"""Protocol definition for sync function components."""
-
-AsyncFunctionComponent: TypeAlias = Callable[[T, Context], Coroutine[Any, Any, Component]]
-"""Protocol definition for async function components."""
-
-FunctionComponent: TypeAlias = SyncFunctionComponent[T] | AsyncFunctionComponent[T]
-"""Function component type."""
-
 # -- Context providers
 
 
@@ -97,7 +87,12 @@ class AsyncContextProvider(Protocol):
 
 
 ContextProvider: TypeAlias = SyncContextProvider | AsyncContextProvider
-"""Context provider type."""
+"""
+Sync or async context provider type.
+
+Components can implement this protocol to add extra data to the rendering context
+of their entire component subtree (including themselves).
+"""
 
 # -- Text processors
 

{htmy-0.5.0 → htmy-0.6.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "htmy"
-version = "0.5.0"
+version = "0.6.0"
 description = "Async, pure-Python rendering engine."
 authors = ["Peter Volf <do.volfp@gmail.com>"]
 license = "MIT"
@@ -15,14 +15,16 @@ markdown = "^3.7"
 [tool.poetry.group.dev.dependencies]
 mkdocs-material = "^9.5.39"
 mkdocstrings = {extras = ["python"], version = "^0.26.1"}
-mypy = "^1.14.1"
+mypy = "^1.15.0"
 poethepoet = "^0.29.0"
 pytest = "^8.3.3"
 pytest-asyncio = "^0.24.0"
 pytest-random-order = "^1.1.1"
-ruff = "^0.6.8"
+ruff = "^0.9.0"
 types-markdown = "^3.7.0.20240822"
 typing-extensions = "^4.12.2"
+fastapi = "^0.115.8"
+fasthx = "^2.2.1"
 
 [build-system]
 requires = ["poetry-core"]