Revisit component invocation

[davepeck]

There's a lot of code around invocation that perhaps we can simplify.

Also, is there a compelling reason to call components with Node, or should we always prefer TNode?

[ianjosephwilson]

I guess I'm not sure I fully understand if the intention was to USE the nodes somehow other than to just turn around and include them inside. There is a LOT to shake out here still.

What are the use-cases for the children/embedded template?

I realized that in most cases the component is just syntactic sugar for calling a function that makes a template. Which is fine and could be easier to read but something we should consider: what is gained here?

def div_wrapper(children):
    return t'<div>{children}</div>'

assert div_wrapper(t'<button>Press</button>') == t'<{div_wrapper}><button>Press</button></{div_wrapper}>'

# Or even when childless:

def wrapped_button():
    return t'<div><button>Press</button></div>'

assert wrapped_button() == t'<{wrapped_button} />'

I was thinking later we could add a slotting mechanism of some sort but is that going to be easier than just churning out more templates? For example in cases where we know we are making the same thing:

def make_item_t(item):
    return t'<div>{item.name}</div>'
items = [Item(), Item()]
items_t = t'{make_item_t(item) for item in items}'

Here is almost a TNode use-case, something like this:

def ItemsList(items, children):
    return t'<div class="items-container">{make_tmap(children, items)}</div>'
items = [Item(), Item()]
from operator import attrgetter
items_t = t'<{ItemsList} items={items}><div>{attrgetter("name")}</div></{ItemsList}>'

Do we really want the the non-attrs mixed with the attrs?

How can a component know what it should stuff into a children element versus what is meant for a different purpose? Should we provide a "please put these on your root" workflow ? Maybe something along the lines of attrset or something in addition to other special attribute functionality? For example so that a build tool KNOWS that the component doesn't want that:

def ItemsList(items: list[Item], today: datetime.date, attrset: Annotated[HTMLAttrs, "div"], classmask: HTMLClassMask):
    return t'' # stub

items_t = t"<{ItemsList} class="special-on-sale" items={items} today={today} products={products} />"

It would be great if the tooling could say "hey this component doesn't know that attribute, it looks like a list of python model objects!". How can we make that happen without ruining everyday usage? A counter example might be something like:

<{ItemsList} items={items} today={today} item-count={len(items)} />

Maybe we want that attribute to be an int that is just cast to a string. And our frontend works with that. Do we want to be strict and make them cast it to a string here or pass it in as an int argument and then pass it onto the tdom machinery to be then implcitly cast to a str on rendering? That actually sounds better except without type checking on it just blunders along and I'm not sure what would happen.

def ItemsList(items: list[Item], today: datetime.date, item_count: int, attrset: Annotated[HTMLAttrs, "div"], classmask: HTMLClassMask):
    classlist = ['special-on-thursdays']
    if today == THE_DAY:
         classlist.append('special-on-sale')
    # we just cast everything to string here
    return t'<div item-count={item_count} classlist={classlist} classmask={classmask} attrset={attrset}>{make_item_t(item) for item in items}</div>'

[pauleveritt]

Minor note: I believe we consider a component to be something that returns aNode, not a template. Major reason: wrapping the template in an html() function has proven the simplest way to signal language injection for editors/linters/tooling.

[pauleveritt]

Slotting: in JSX you pass nodes into slots just as args on the component call. Just normal function arg stuff.

[davepeck]

what is gained here?

We start with "what is familiar to a user of JSX", and work from there. The idea that you can use HTML-like syntax to invoke a function is very familiar and it turns out to be a very nice way to express things in practice. Many of the reasons for this in javascript-land continue to be good reasons even in Python-land.

slotting mechanism
in JSX you pass nodes into slots just as args on the component call

Yup. Fine for now in tdom too I think.

How can a component know what it should stuff into a children element

children is, effectively, reserved. It has only one use in a component function definition: to take a collection of Node (or TNode, more likely).

Do we really want the the non-attrs mixed with the attrs?

Sure. Perfect, enemy of the good, and all that. :-)

pass it in as an int argument

Yes, that's the intent. Types are retained for attributes in component invocations. Some day, when we're in the promised land, we can type check with a fork of ty that knows that a specific t-string is invalid because <{Component} wants-a-str={42} /> is wrong.

I dunno. The more I mulled this over, the more component invocation as it stands in tdom today struck me as easy to write and use. At the moment, I'm not sure I want to radically alter it. I primarily want to revisit whether we should be using TNode here, and whether we should be more flexible in what components return (TNode or Template both seem fine; Node if we continue to have them).

[pauleveritt]

I'm also pretty happy with it. As a note, for the pluggable context discussion, I kinda hope we can pass in a custom component locator and factory so I can bring back my previous stuff. The current approach makes it pretty easy.