Comparision with django-cotton

[EmilStenstrom]

https://github.com/wrabit/django-cotton?tab=readme-ov-file#comparison-with-other-packages

[JuroOravec]

The ability to define Python objects like lists within the template is really nice! (See Passing Python data types)

[JuroOravec]

Btw, curiosity got the better of me, and I got a working algo for safely evaluating expressions, so theoretically we could have a similar feature to what django-cotton does python expressions within HTML.

E.g. in Cotton, they can pass a static list to a component like so:

<c-select name="q1" :options="['yes', 'no', 'maybe']" />

Django-cotton uses ast.literal_eval, which means that the expressions cannot contain variables. I took slightly different approach, by first searching the AST for variables and checking for permitted syntax.

The result is that our expressions can contain variables. (For context, unlike plain eval/exec, this forbids assignments or any other statements. And I also disabled function calls, to stick with the theme of Django templates).

So, we could have something like this (exaggarated example):

{% component "my_comp"
	:items="[a for a in [1, 2, *(list_a if 1 > 2 else list_b) ] ]"
	:bool_val="not is_active"
	:attrs="{**dict_1, **dict_2}"
%}
{% endcomponent %}

This would fit nicely with what I talked about in #539.

[EmilStenstrom]

Having expr separate is probably the right call. In a typical Django project, you would move that expression to the view, and have a ViewModel (the context dict) that has all the values you need in the template pre-populated.

Another API to consider is if we would allow {% component 'test' title="{{ person.first_name}} {{ person.last_name}}" / %}? Maybe overkill as well?

[JuroOravec]

Having expr separate is probably the right call. In a typical Django project, you would move that expression to the view, and have a ViewModel (the context dict) that has all the values you need in the template pre-populated.

Agree. I mean, it's a minor thing, but I initially wanted expressions inside templates, because, having experience from Vue, it allows to give a bit more meaning to the code. As in, if I expose a variable to the template, that's noteworthy. And when I need to negate that variable or slightly modify it, I know it's trivial, because that expression doesn't even get it's own variable. On the other hand, if I expose variable and notVariable and filteredVariable, it's harder to see what's really important.

But, after all, I can still achieve that distinction with the example in my previous message.

Another API to consider is if we would allow {% component 'test' title="{{ person.first_name}} {{ person.last_name}}" / %}? Maybe overkill as well?

I considered it too, but then IMO it would make sense to strictly render the inner template as string. On the other hand, if we allow only a single pair of {{ }}, then we can evaluate it without forcing the result to be stringified.

[EmilStenstrom]

Again in the Django world, they would argue that allowing expressions in templates means that people will misuse it and add business logic there. This is not a problem with a bunch of experienced developers, but with more junior developers it could lead to very messy code.

All in all, I think having expr as an external lib, and using the "as variable" convention, is a great way to navigate around this.

Avoiding stringification is a great point.

[oliverhaas]

@JuroOravec I really like your approach for the safe evaluation of the expression. I have been wondering for a while how one could do this, and using the ast looks pretty solid to me. Didn't actually occur to me....

[JuroOravec]

@oliverhaas If you're interested in that, have a look at https://github.com/JuroOravec/alpinui/blob/main/packages/django-expr/README.md :) By default it doesn't allow function calls, but that can be configured via EXPR_ALLOW_FUNC_CALLS

[oliverhaas]

For me personally, the syntax of django-cotton itself is a nice feature, which leads me to the following question:

@EmilStenstrom Would django-components be open to include an optional cotton-like html tag syntax? We've already started implemented something along those lines in one of our projects to try it out. It's mostly a matter of taste, of course. Upsides of custom html tags are mainly formatting and intellisense regarding css classes by default. I'm using vscode, and I'm also checking out whether (automatically generated!) code snippets and html data providers would help the DX.

[oliverhaas]

@EmilStenstrom

One goal of django_components is that projects that use it should feel natural to Django-developers from the first time they see the code. I think {% component "my_comp" abc=123 xx="{% expr '1 + 1' %}" / %}" / %} just makes sense, but I think <MyComp abc=123 xx="{% expr '1 + 1' %}" /> would generally confuse people, because HTML tags should not be handled by the template library at all so who's messing with the HTML?!

Looking at a typical button component in my projects (using django-components), it's basically an html button with some default styling and tiny extra features like optional icon, loading spinner, etc. So having it as <c-button/> still feels at least not wrong to me.

But I'm not sure what syntax I would prefer in the long run. I just thought html-tags was a neat idea and wanted to check it out with my actual (django-)components. I expect that quite a few people will feel similar about that. It would be a pretty simple addition to django-components (an optional template loader) and I saw this discussion I wanted to share my thoughts :).

[oliverhaas]

@JuroOravec
It's not much, but with html-tag syntax I at least get intellisense for css classes:

[EmilStenstrom]

@oliverhaas So the reasoning is "since my home-make components are very close to native HTML tags (your button component), seeing <c-button> looks natural"? The thing I think might trip people up is not understanding what's going on by looking at the code. What <c-button> does would then depend on which plugins are loaded, what JS libraries are loaded (it could be a normal web component), and many other things. So my reasoning is that this might feel right for someone that knows what they are doing, but is likely to confuse everyone else.

Intellisense and autoformatting for templates would be awesome :)

[JuroOravec]

Btw, @oliverhaas, you mentioned that

We've already started implemented something along those lines in one of our projects to try it out.

Does it mean that you are using django-cotton, or that you implemented your own script that converts the custom HTML-tags to django tags?

For context, I agree with @EmilStenstrom that this should not be in the core package. I was thinking about the plugins for django_components, and realized that they would have to operate on the level of Templates, not a raw string content.

So the options for you would be to:

1. Define a Django Loader that pre-processes the file content, converting the <component /> HTML tags to django_components tags {% component ... / %}, and returning a Template

2. Define a django_components plugin that would be given a Template, and would do the same pre-processing on the template's source content (Template.source), and then re-generate the Template.nodelist.

Of the two, the Loader would be probably a more complex one. Because I can imagine that, to make it work generally, one might have to use similar approach to the cached Loader, nesting other loaders in it:

 'loaders':[(
    'path.to.loaders.Html2DjangoLoader', [
		# Nested
       'django.template.loaders.filesystem.Loader',
       'django.template.loaders.app_directories.Loader',
		...
    ]
 )],

Whereas for the plugin, it would be just a matter of defining a function that modifies the Template in place.

So if you have the logic for converting HTML to django written down, then it should be easy to set things up once plugins are supported.

[oliverhaas]

@JuroOravec Here is our proof of concept, which is basically what you said: A custom template loader which does some parsing, and then just uses django-components like normal. It's heavily inspired by django-cotton. Maybe it leads to something useful...

I think that's it for now from my end.

Thanks for the discussion, and all the good work of you two.