Add integration with dj-angles for custom HTML-like tags

[joshuadavidthomas]

Okay, I've decided to go ahead with what I talked about downthread and abandon the idea of doing the custom HTML elements in this library in favor of leveraging dj-angles.

• Add a angles extra to the package, for installing dj-angles alongside the library

• Add some common tag prefixes, either to the library in the form of string literal constants or in the docs.

  Given dj-angles flexibility around how the tags are defined, we could even accomplish my original goal of copying Flux's syntax of <bird:button> (presumably, pending actual testing)

• Update docs to point to dj-angles

• Update roadmap to reflect this change

Previously:

I really like the approach of django-cotton and dj-angles, where they take what looks like a custom HTML element and do some compilation in a template loader and swap the custom elements out for plain ole django templatetags.

I also prefer Flux's approach of namespacing the element with the library name and a colon, as opposed to the approach taken by the other two libraries where it looks like it could be a custom Web Component:

<!-- dj-angles -->
<dj-block 'content'>
</dj-block 'content'>

<!-- django-cotton -->
<c-button>
    Button
</c-product>

<!-- flux -->
<flux:button>
	Button
</flux:button>

This could just be a personal preference thing, but the first two throw me off and make me think they are custom Web Components, where the bottom I know can't be because of the colon.

In the end, it should be no harder to parse and compile with the colon vs with the dash.

[joshuadavidthomas]

So I complained about dj-angles and django-cotton and their custom components syntax looking like Web Components, and preferring flux's use of the : colon -- but after some digging and research, I think that's just how Laravel defines their version of templatetags.

So.. while I think I visually prefer the colon, not doing this would save the time and effort to creating a whole custom compiler just to achieve that same API. Whereas right now, we could recommend dj-angles to achieve similar results as django-cotton, while keeping everything in this library as vanilla Django templatetags as possible. Something to think about..

[joshuadavidthomas]

On the other hand, I've got a half working compiler over in https://github.com/joshuadavidthomas/django-template-ast -- maybe it's worth it to finish it up and pull it over here. Though I do worry about the long term maintenance of it all.

[carltongibson]

"Do less" a wise person once told me.

[joshuadavidthomas]

Well, I don't know when @adamghill did this -- but there's a dedicated section in the dj-angles docs for integration with django-bird. 🤩

I think instead of pursuing the <bird:component_name> syntax, we should double down on the integration with dj-angles for now. I may eventually circle back to this, but if dj-angles gets us away from my main complaint of components using templatetags (mainly that if you use them heavily, your templates become borderline unreadable and harder to visually parse at a glance) -- let's go with it for now.

Should probably update our own documentation to note this integration, as well as add some sanity test cases. Could also add it as an optional extra, e.g., uv add 'django-bird[angles]'.