BasicComponents should per default take all context

[nerdoc]

The purpose for basic components is to build the "Lego" blocks of a modern web page. nearly all of them need much of the available context, and could be very big, like e.g. UI elements like Bootstrap card elements, an easy Card component could look like:

@default.register
class Card(BasicComponent):
    template: django_html = """
{% load markdownify i18n %}
<div class="card mb-2"{% if tag == "form" %} method="post" action="."{% endif %}>
    {% if blocks.title %}
    <div class="card-header">
        <h3 class="card-title">
            {% block title %}{% endblock %}
        </h3>
        <div class="card-actions">
            {% block actions %}{% endblock %}
        </div>
    </div>
    {% endif %}
    <div class="card-body">
        {% block default %}
        {% endblock %}
    </div>
    {% if blocks.footer %}
      <div class="card-footer">
        {% block footer %}{% endblock %}
      </div>
    {% endif %}
</div>
    """

Now, when using that component, you have to add the context: **context to each and every card tag you write. If you forget it, this produces bugs you don't see at once, as django context vars that are referenced, but non-existent, are just empty, and worse, in if clauses, are always false.
So in your component usage, a

{% @ card %}
  {% if user.is_authenticated %}
    something to display!
  {% endif %}
{% /@ card %}

will just never display anything, because user is not in the context.

I agree that context is a burden for Alpine.js enabled (and stateful) components, but as BasicComponents are stateless, the burden is quite none.

So I think that adding all context to BasicComponents per default would be a good way, even if it is not consistent. But, BasicComponents and Components differ anyway, it's all about documentation. And coding is much better with components that help you to write less code.

Ideas?

[gsxdsm]

This would be excellent!

[nerdoc]

I think this could be extended further. There are types of components that need context, like containers, and others that don't by default (you can add it using {% @ foo context: x,y,z %} in the template).
So a possibility would be, adding a private __extra_context attribute to BasicComponent, where you can add context for this class. Because e.g. a component displaying the user's properties always needs the user in the context, so why not add it in the python code:

class UserName(BasicComponent):
    __extra_context = ["user"]
    template = """<div>{{ user.username }}</div>"""

There are many components that generally need the request object, the user, or, dependent on your needs, special vars in the template context.

This would ease working with it and is analogue to Django's extra_context in views. To mimick "context: **" in the template calling, a __extra_context = "__all__" would be good.

[nerdoc]

I wrote a patch that fixes that issue, should be included in v0.1.2. I also decided to change the tag syntax for all context to {% @ somecomponent context: __all__ %} instead of context: **context to be consistent with extra_context and Django's views' extra_context attr.

[gsxdsm]

Seems like a solid solution to me, thanks!