I've tried this and, honestly, I don't like it. Reason number one is how verbose it becomes on the templates when you have to pass a "body", it's at least 4 tags... when you have many nested tags it becomes messy. And then the worst offender to me is that it doesn't isolate the context from the parent template (you have to add the 'only' keyword like with includes), etc. I mean, it was my first option until I found Slippers which for my taste, makes the right trade offs and design decisions.
Slippers does look interesting - not sure I like the idea of declaring components in a YAML file but otherwise it seems to address the pain points of components. Would be interesting to see how well it integrates with Django forms.
I guess Jinja macros are also pretty good as a basis for building components as well, but I've always found switching to Jinja 2 in a Django project to be too much hassle to be worth it.
Agree. I've also tried Jinja macros and despite I was satisfied with that, it feels a lot like you're moving away from the core of dj ago. Suddenly translations don't work.and you need other solutions, templatetags don't work, and most third party libraries are built for Django templates, not Jinja. Definitely not worth it.
Imagine you have a dropdown, or a list of items, etc which is composed of more than one single markup element, such as a couple divs, an ul and a li for each element. Wrapping all of this into a component helps reusing this parameterized component in as many places as you need. You might think why not just use "includes"? Well, includes are great for very simple use cases, but for example, you cannot pass a "body" of html to them (imagine you want a "ListWrapper" component, etc) among other shortcomings. Thinking in components makes things a lot easier in my opinion.