Support class-based components

[pauleveritt]

I added this case statement in my context to proceed:

        case _ if is_dataclass(value):
            # This is an instance of a dataclass, call __call__ and return
            return result()

If you'd like, I can make a branch with some tests and a proposed implementation. We don't have to force dataclasses, we can do regular classes.

We can also move the condition outside of the match. For example, when making result, do a second test like this:

# Is result a callable?
if callable(result):
    result = result()

...though this might open the door to false positives.

[davepeck]

I don't quite understand where this fits in? Is it a follow-on to already-opened #39

[pauleveritt]

It's mostly unrelated to context.

I believe we want to allow both function-based components and class-based components. Right now the implementation only supports function based components. Sorry, I should have made that clear.

[davepeck]

@pauleveritt We support any arbitrary callable. So a class that implements __call__() works already.

What do we think a class-based component look like?

[pauleveritt]

Actually it doesn't work. result winds up being the class instance, not the returned Node. And thus doesn't match any of the matchers.

Here's what one of my tdom-sphinx components look like:

@dataclass
class Header:
    """Header component for HTML document."""

    context: TdomContext

    def __call__(self) -> Node:
        pathto = self.context.page_context["pathto"]
        site_title = self.context.page_context["site_title"]
        root_url = pathto("/")
        return html(t'<div>Some stuff, omitted for brevity</div>')

You can see a bunch more in unfinished Goku theme

At first glance, you might say "that's ugly as shit, so much more typing than function components." And that's true. But they had two advantages for me, about replace-ability:

1. If you wanted to customize the HTML, you could subclass and keep the same props API.
2. You could replace based on type, not name (which was how svcs, Hopscotch, etc. worked.)

[davepeck]

Right. This doesn't work because component invocation is a single function invocation.

Assuming you're invoking the header with html(t"<{Header} />") then this won't work, because the function you're invoking is Header.__init__(), not Header.__call__().

Moreover, we don't currently support calling function values -- that is, we don't support this:

def some_function() -> str:
    return "hi"

result = html(t"<div>{some_function}</div>")
# <div><function some_function at 0x100f47320></div>

Since the value returned by a component callable invocation is treated like just another child content value, in the case of Header, you'll end up seeing the repr(Header.__call__) in there. :-)

---

Okay, having said this, I really like the idea that we should be able to do the following:

from dataclasses import dataclass, field
from typing import Any, Iterable
from tdom import Node, html

@dataclass
class Card:
    children: Iterable[Node]
    title: str
    subtitle: str | None = None

    def __call__(self) -> Node:
        return html(t"""
            <div class='card'>
                <h2>{self.title}</h2>
                {self.subtitle and t'<h3>{self.subtitle}</h3>'}
                <div class="content">{self.children}</div>
            </div>
        """)

result = html(t"<{Card} title='My Card' subtitle='A subtitle'><p>Card content</p></{Card}>")
# <div class='card'>
#     <h2>My Card</h2>
#     <h3>A subtitle</h3>
#     <div class="content"><p>Card content</p></div>
# </div>

In order to make this work, we're going to change two things:

1. The expected signature of component functions. They will only be invoked with keyword arguments. One of those arguments will be children: Iterable[Node] rather than the current var positional *children: Node. This allows dataclass constructors like Card.__init__() to accept children and all other desired parameters.

2. How we handle callable values in child content positions. Right now, we just turn around and call str(value) if it's a callable, which makes sense in the old world. In the new world, we'll actually invoke those callables if we see them. Importantly, we'll invoke them with no arguments -- if they require any arguments, html() will (correctly!) blow up. This means that Card.__init__() gets invoked when html() sees <{Card} ... /> syntax, and Card.__call__() is invoked because __init__ returns a callable value.

That's it. After that, the Card example will work as you sort of intuitively thought it might!