You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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..
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.
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:
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.
The text was updated successfully, but these errors were encountered: