Idea 1: Do we need to maintain a full copy, or is it possible to monkey-patch just parts of it?

I think whole Template.compile_nodelist(). Alternative I could replace Lexer.tokenize() and DebugLexer.tokenize(), but I'd have to check if Django is using the Lexers anywhere else.

Idea 2: <hello> could be a django component, but it could also be a web component

The way I'm thinking about it, the HTML-compatible format would have to be:

1. Opt-in.
2. Be all or nothing - Either ALL Django template tags (not just our components, but all) would use that <> syntax, or none. Mixing the two would definitely be bad.
3. It'd have to be clear. That's why I was thinking of prefix <d-, (e.g. <d-include "path/to/file.html"> instead of {% include "path/to/file.html" %}). No HTML elements start with d-, plus the "d" would indicate that it stands for Django. And if user defined custom web components whose names start with d-, that'd be on them.

But since the HTML-compatible syntax would have to be a bit different from Django's in more ways than just the bracket tokens {% %}, I again think it makes sense to keep it as a separate plugin.

About Idea 2: Yeah, I see how that could be interesting for some. I just don't think it's worth a lot of effort to implement. Because even though they could, SHOULD they? :) Are you a strong fan of this syntax?

Idea 4: Sounds like a nice addition to the library! I think people might expect all the tags to behave like that, and get really strange errors, but I think that's likely worth it anyways for the added convenience. ✅

Idea 5: ✅ - With the addition that we should probably keep it backwards compatible not to break people's code for no reason.

Idea 6: This is a worthy effort, but I think that if merged into Django, this is something that would have to be merged separately. Likely also prefixed with a DEP (Django Enhancement Proposal) before anything else being merged. I think the most likely candidate for merge into Django is just the Component base class, and a simplified version of the component tag (without many of the bells and whistles). Anything else would have to lead to separate discussions. So I would suggest only doing this if you think it's worth it because it simplified the maintenance of this library.

Idea 4: Sounds like a nice addition to the library! I think people might expect all the tags to behave like that, and get really strange errors, but I think that's likely worth it anyways for the added convenience. ✅

Good point. Initially I implemented a proof of concept such that it works only with OUR template tags (by it being a feature of the tag parser). Buuut, I think we should be able to implement it such that it would work also for template tags that are not ours, by moving the implementation to the template parser.

Idea 5: ✅ - With the addition that we should probably keep it backwards compatible not to break people's code for no reason.

Agreed

Idea 6: [...] So I would suggest only doing this if you think it's worth it because it simplified the maintenance of this library.

Ah, alright, I'm not familiar with how Django proposals work, so thanks for clearing that up.

But yeah, on the idea, I had a stab at it yesterday evening, and it removes a subtantial chunk of boilerplate for our template tags. And it also simplifies where the plugin hooks will go, because before I had to define a hook for every template tag separately, but now it can be embedded within the base Node class.

Idea 4: To be clear, I don't think we should mess with template tags that are not ours, that's just a mess when debugging problems stemming from our code breaking their code.

Idea 6: Happy to hear it works, then I'm on board! :)

Idea 7: Not that fond of this one. The pattern for finding what a tag does is to look in two places: either at the top of the template you're in, or in the builtins setting. If the import is not in any of those places, where is it? I'm like automatically allowing people to inherit from Component in their python files, artificially adding from django_components import Component so they wouldn't need to add it. Might be more confusing than it helps.

For tests, I would suggest using the override_settings var in the BaseTestCase and include it in the builtins.

That's great point, haven't thought of the load tag as equivalent to an import statement 👀

I'd go with the **kwargs approach.

Because if we allow data-id, then we also allow e.g. colons or dots in the key name, e.g. like AlpineJS syntax @click.once="onOnce" or :href="item.url". And then there would be ambiguity if there were 2 inputs that originally used different keys , but would be corced to the same python identifier.

Basically we technically don't limit what characters can or cannot be part of the key.

Also the coercsion of data-id to data_id raises question of what to do if I wanted to render that kwargs as an HTML attribute. Because I would assume that if I access data-id by data_id, then that key would NOT be available in kwargs anymore.

And then if I wanted to do something like the Vue's fallthough attributes:

class Table(Component):
    def get_context_data(self, **kwargs):
        return {
            "attrs": kwargs

    template = """
      <div {% html_attrs attrs %}>
      </div>
    """

Then would that render <div data_id="123"> or <div data-id="123">?

Yeah, you're right, I agree. And if you wanted input validation, you would do that with a dataclass instead, like we talked about in a separate thread? Then would that class enable us to validate data-id?

In theory yes, but in practice not sure.

Because for one, the class defined for validation, like TypedDict, its keys still must be only valid python identifiers.

But I also think that validation only makes sense for fields that can be valid python variables / identifiers. Because it feels strange if someone wanted to allow to pass in only e.g. data-id, but not other HTML attributes likes aria-..., etc.

Instead, the pattern is usually either to:

1. Have explicitly defined inputs ("props"), and allow any extra kwargs to be considered as HTML atributes (like Vue does it)
2. or explicitly define a dictionary which user can populate with HTML attributes.

So in case 1, there's no point in validation, because we allow anything, and in case 2 I'd at most validate only that I received a dictionary, but wouldn't inspect individual keys.

Good points. Thanks for clarifying. Then we go with **kwargs.

I implemented this in #910.

Btw, I realized there's one nuance that I ignored. But TL;DR, no further actions needed.

Throughout this thread, the examples I was showing we've were using Component.get_context_data(). But the implementation for #910 was actually for BaseNode.render().

There's difference, because the input that a Component accepts is built ON TOP of the input that a template tag (BaseNode) accepts.

And it's in BaseNode.render(), where I implemented this behaviour, that passing data-id, etc, is allowed.

So if user defined their own custom template tag on top of ours, then they'd be able to do:

class MyNode(BaseNode):
    start_tag = "my_tag"

    def render(self, context: Context, **kwargs):
        return ...

And we'd allow them to pass in kwargs like so:

{% component "table"
    class="pt-4"
    data-id="123"
%}

Because these would be collected onto **kwargs, and could be used in render() as:

def render(self, context: Context, **kwargs):
    attrs_str = " ".join(f'{k}="{v}"' for k, v in kwargs.items())
    child_content = self.nodelist.render(context)
    return f"""
      <div {attrs_str}>
        {child_content}
      </div>
    """

Now, the nuance comes that ComponentNode allows any extra args and kwargs (see source), because its defined as

class ComponentNode(BaseNode):
    def render(self, context: Context, *args: Any, **kwargs: Any) -> str:

It's only at the point when we take the inputs defined in a template tag call, e.g. {% component arg1 kwarg2=val2 %},
and we render the node, calling ComponentNode.render(), when we actually pass in the inputs in the original order (arg1 kwarg2=val2).

Inside ComponentNode.render(), we instantiate and render the corresponding Component class. But when rendering the component, we pass in the args and kwargs already separated (see source).

Thus, when get to get_context_data(), we don't try to pass the args and kwargs in strictly the same order as what the user provided. Instead, the args and kwargs are already grouped together (see source).

However, I think this is fine. If user passed in args after kwargs, or did some other shennanigans, this would be detected when calling ComponentNode.render(). Thus, by the time we get to calling get_context_data(), we know that there's no such shennanigans.