Juro Oravec

Use django-components as a vehicle to introduce new features into Django's templating · Issue #91 · django/new-features Code of Conduct I agree to follow Django's Code of Conduct Package Information django-components (https://github.com/django-components/django-components) Problem TL;DR Use django-components as a ve...

1.5 year ago I joined Emil on django-components as I was frustrated with Django.
Now the project is much further and we're starting the discussion on how it could be merged to Django.
Please share your thoughts or concerns!
Getting django-components to Django 6.1 or 6.2 would be lit af.

Asking Chatty how to make black tea faster and it whips up pandas. 👌

In the end, the cleanest way is to forgo the bells and whistles, and require users to add the static types themselves.

Next I tried code generation with overloads. Similar to how Prisma works - A command generates the static types, inserts it into package (site-packages), and Mypy picks it up. After some trial and error I got it working. But... Mypy was always picking the first overload...

I had a good mileage with Generics. But subclassing classes with generics is crazy verbose - You have to re-define all generics, and use the `default` field as the values you actually want.

Well this is... something. Python, 2025. The best way for statically typing methods on subclasses? Generics? No. Overloads? No. Codegen? No. Instead? Give up and do it manually.

Can you recommend some tutorials with advanced setup for vibe coding / AI code assistants? I wanna know if my codebase is just too complex or I'm falling behind

@pypi.org Down?

djc-heroicons Icons from HeroIcons.com for django-components

Just published djc-heroicons - this is the first package with shareable components for django-components. So kind of a HelloWorld :)

pypi.org/project/djc-...

This weekend I've build 2 packages for django-components
- One for icons from HeroIcons.com
- The other for "ErrorBoundary" component

Still blocked by a few more PRs on django-components, but will ship it as soon as possible.

Hand-in-hand with the TagSpec, I also wrote a parser that takes Django template tag's input (the string between {% %} ), and sorts and parsers it into args, kwargs, flags, etc.

The parser converts the tag's input into AST that describes each arg / kwarg / flag, and even each filter separately

The tag spec makes it possible to programmatically manipulate with the Django template tag's definition - I used for the docs for django-components to automatically generate the template tag signature from the spec.

For django-components I wrote a utility for defining and parsing Django template tags - You define the spec ("TagSpec") with args, kwargs, and flags (and more) that the template tag uses. And the utility does the parsing for you.

Should I make it into a standalone package?

6/5 Create a mid-sized demo project that showcases how to use django-components

Recently we got startups and SMEs asking about django-components. Is there any unknowns? What's something that makes the decision / comparison either difficult or ambiguous? What can we improve?

This has been irking me too. My thoughts were to replace the ORM with prisma python client, but ofc that doesn't play well with current Django

django-components/src/django_components/templatetags/component_tags.py at 6813c9d7aa4acfb04df9665651a2864d04bbe8ba · EmilStenstrom/django-components Create simple reusable template components in Django. - EmilStenstrom/django-components

See I did that in django-components. Would it make sense to make that code into a standalone package?

github.com/EmilStenstro...

So if I was writing such LSP, the for custom template tags, I would ask users to define their template tags as these "TagSpecs", so the LSP would know how to handle their custom tags. And for built-in Django tags, the LSP would have their "specs" hard-coded.

For Django-components I wrote code for declaring template tag API - so one defines upfront which args, kwargs, and flags the template tag may take. And the parser uses this "spec" to know how to parse the template tag inputs. This way the template tag API is codified, e.g. to the generate docs.

For built-in tags, this is not an issue - you can use Django's documentation and hard-code that into the LSP. But for custom template tags, I can't imagine how you could use vanilla Django template tags with LSP for e.g. autocompletion.

One issue I expect is that Django doesn't define the API of the template tags very well. It just splits up the string inside {% %}, and leaves the rest up to the user. User could use Django to parse the template tag inputs as args and kwargs, but they might not.

Do I imagine right, that the user would define the path to the Django settings file, and then your spawned process would use that to set up Django? And that's how you could then figure out which template tags are available?

Love that! Lack of LSP for Django's been irking me too. In the end what I wanna try is to allow to write Vue files directly for Django. Because I want to write JS-heavy components, and Vue already has tooling for that. I would still need to fork their code to allow for extra python section.

I'm thinking of the same for django-vue. Barely working, but getting the idea out there sounds worth it. IMO do it!

Thoughts on Django features Django Topics Taken from https://docs.djangoproject.com/en/5.1/topics/ How to install Django Install Python Install Apache and mod_wsgi Get your database running Install the Django code Models and dat...

Best of luck! My there's a lot of room for improvement. I was thinking about that too, with FastAPI as the server, and Prisma as the ORM. Have a look here for more ideas:

docs.google.com/document/d/1...

Is this LSP for Django templates, or specifically django-bird? How do you define known tags? Would there be a way to add project-specific template tags?

I wrote a parser in Python that detects both HTML and Django syntax, you can use that if you want.

Replace BeautifulSoup4 with own lightweight HTML parser · Issue #831 · EmilStenstrom/django-components Currently we depend on BeautifulSoup4 to parse and modify the HTML to enable features like scoped CSS, JS / CSS vars, etc. As mentioned in #823, ideally we wouldn't have to depend on external packa...

5/5 If you want a bite-sized thing, you can help us write an HTML parser (~1 week)

github.com/EmilStenstro...

Improving time to load. Inspiration from McMaster-Carr · Issue #835 · EmilStenstrom/django-components This is based on the discussion in #717. I think it would be great to eventually implement these, so I'm making an issue for this, so we can track progress for this. Original video: https://youtu.b...

4/5 Or you could help us make Django apps fast by implementing various optimisations (~2-3 weeks)

github.com/EmilStenstro...

3/5 Help migrate Tetra to use django-components instead of their own implementation. This is the "LiveWire" part of the "Vue + LiveWire". (~3-6 weeks)

tetraframework.com

UI component library · EmilStenstrom django-components · Discussion #547 Intro This thread is meant to be the main place for discussing building component library / design system on top of Django + django-components (DC). When I refer to (UI) component library or a desi...

2/5 Build a UI component library that's first of it's kind (in terms of sophistication) for Django ecosystem. The library is a port of Vuetify. What remains is to convert ~100 JSX files to Django templates. This would be huge for everyone using Django for UI (~1-2 months)

github.com/EmilStenstro...