Component life cycle

[mikko-ahonen]

What kind of life cycle do the component instances have? Could I do something like this (does not appear to work)? In this case, this is a queryset, and I am passing two very different querysets from different places.

  @component.register("organizers_editor")
  class OrganizersEditor(component.Component):
    template_name = "organizers_editor/organizers_editor.html"
    organizers = None

    def get_context_data(self, request, organizers):
        assert organizers, "Organizers required"
        self.organizers = organizers
        return {
            'request': request,
            'organizers': organizers,
        }

    def get(self, request, *args, **kwargs):
        context = self.get_context_data(request, self.organizers)
        return self.render_to_response(context, {})

[JuroOravec]

@mikko-ahonen Help me understand this better, how are you passing the querysets? From the example I cannot tell if you pass the organizers querysets via get_context_data (from inside Django template via {% component %} tag); or via get.

[JuroOravec]

Ok and how does it get assigned to self.organizers then?

But to answer your original questions, when you render a template, e.g.:

template = Template("""
	<div>
		1. 
		{% component "organizers_editor" %}
		{% endcomponent %}
		
		2. 
		{% component "organizers_editor" %}
		{% endcomponent %}
	</div>
""")

template.render(Context({}))

Then for each time you use {% component %} tag, a new instance of a class is created. And that instance exists until the component and it's contents/children are rendered.

[mikko-ahonen]

It is initialized {% component organizers_editor request organizers_qs %} where organizers_qs is the queryset.

Many other component libraries allow setting the arguments for the instance for example in __init__ and they are shared by subsequent calls to the instance.

I am suspecting calling the view through URL creates another instance. I don't see any examples or tests where instance created via {% component %} tag and view URLs would share data. In all examples, all data appear to be passed to the view through POST data or URLs.

[JuroOravec]

It is initialized {% component organizers_editor request organizers_qs %} where organizers_qs is the queryset.

Ah ok, so you do pass it via the {% component %} tag.

I am suspecting calling the view through URL creates another instance. I don't see any examples or tests where instance created via {% component %} tag and view URLs would share data. In all examples, all data appear to be passed to the view through POST data or URLs.

Yes, I think so too, that they are different instances. I'm not familiar with using component as views (I prefer to treat components as purely frontend-rendering), but I was just looking at the code this weekend where we make a component behave like a View, and what I know is that:

1. When you call {% component %}, then you create a new class instance
2. When you use a component as a View with Component.as_view(), that Django creates a view function that creates class instance here.

So I'm convinced that these two are different instances, hence do not share the organizers attribute.

---

It would really help to see the whole template you're trying to render. But I'm wondering - since you first trigger the component as a View, and then you want to access organizers on a different instance of the same component, then does that mean that you are nesting the same component within the template?

E.g. that "organizers_editor/organizers_editor.html" looks like this?

...
{% component "organizers_editor" %}
{% endcomponent %}
...

If so, then instead of assigning self.organizers, you should pass the data through the context, e.g.:

...
{% component "organizers_editor" organizers=organizers %}
{% endcomponent %}
...

A useful way to think about this is that components are stateless, and all state is passed through the Context.

---

Alternatively, we've just added support for dependency injection with which you can achieve the same:

@component.register("organizers_editor")
class OrganizersEditor(component.Component):
    template_name = "organizers_editor/organizers_editor.html"

    def get_context_data(self, request, organizers):
		####### CHANGED ##########
		if organizers is None:
			# raises error if "organizers" not provided
			organizers = self.inject("organizers").data
		####### CHANGED ##########
        return {
            'request': request,
            'organizers': organizers,
        }

    def get(self, request, *args, **kwargs):
        context = self.get_context_data(request, self.organizers)
        return self.render_to_response(context, {})

Whereas, in "organizers_editor/organizers_editor.html", you would have wrap all content in the {% provide %} tag:

{% provide "organizers" data=organizers %}

	Now we don't need to pass "organizers=organizers" to "organizers_editor" because
    "organizers_editor" will try to access the data via self.inject instead:
	{% component "organizers_editor" %}
	{% endcomponent %}

{% endprovide %}

So what you would achieve above is that:

1. When organizers is given as input to OrganizersEditor, we use that and ignore the self.inject branch
2. Inside the template of OrganizersEditor we use {% provide %}, so that any nested organizers_editor components can access the same data via self.inject
3. In the nested component (the one called via template as {% component "organizers_editor" %}) the get_context_data doesn't receive the organizers input. So instead we try to "retrieve" it using organizers = self.inject("organizers").data

[mikko-ahonen]

That is exactly what I needed.

I am not sure whether dependency injection is the right word for it, though. I view that logically I am providing data from component initialization (get_context_data, but it probably should really be named the init function) to other methods of the function.

In my view the problem (without such feature you call "dependency injection) is not that I need to "pass data through context" but that I had to pass the data through HTML -> browser -> HTTP post data, causing lots of boilerplate encoding, decoding and cleaning data.

[JuroOravec]

Yeah, dependency injection is something else, what I had in mind was provide/inject. This provide/inject is still stateless in a sense that once the rendering is done, no state is persisted. So I think it's something different from what you mentioned.

Reading your last paragraph, I think what you have in mind is server-side state? (If that's the right term?) That there'd be some state persisted and available to the view in subsequent calls?

[mikko-ahonen]

Not really. With server-side state I would understand that some entity would keep the state even without me saving it.

What I would expect is that the parameters I pass to the component in the initialization could be also accessed when it is implicitly initialized through a view.

So instead of get_context_data(), the parameter foo would be passed to init function (with double underscores) which could then set self.foo r that would be passes as the self.foo to the get function and get_context_data()

[JuroOravec]

Aha, I think I understand now! But before I write more, which version of django_components are you currently on?

[mikko-ahonen]

0.77.

[mikko-ahonen]

I guess in a way you could say Iam expecting component to keep state.

[JuroOravec]

Thanks! I was wondering about the version, to get a sense of how it could be implemented. Because in v0.81 we reworked the render/render_to_component methods, and get_context_data is now called internally when one calls render/render_to_component (See https://github.com/EmilStenstrom/django-components/blob/master/src/django_components/component.py#L381).

What we already do in the newer version is that we set the private self._context on the component instance that is being rendered (See https://github.com/EmilStenstrom/django-components/blob/master/src/django_components/component.py#L380). Currently self._context is set only for the duration of self.get_context_data, but to support hooks I would need it to be set for the full duration of self.render.

For the UI component library, I would also need to access the slots from within self.get_context_data.

So given these, I think what we could do is set all the render inputs (args, kwargs, slots, context) to the component instance for the duration of the full render, so we could access them as self.args, self.kwargs, self.slots, self.context.

This is also similar to e.g. Vue, where one can access the inputs via $props, and slots via $slots.

One thing to note, we would have to also handle the case of when I would try to call self.render from within render. Because the inner render would overwrite the self.args, self.kwargs, ...

@EmilStenstrom What do you think?

[JuroOravec]

I gave it a go, it was pretty quick to implement, tho there's a few more MRs before I get to this one.

[mikko-ahonen]

Excellent stuff i will take a look

[EmilStenstrom]

I don't currently use the library so I haven't seen the use-case for this. But you both seem to see the use-cases clearly, so go ahead! :)

[mikko-ahonen]

@JuroOravec did you have a chance to work on this? I was desperately needing it again today.

The latest use case:
I am making a generic AlpineJS/HTMX component for inline editing of data element (i.e. click to edit). Because it is generic, I need to pass it the entity and the field I am editing (the value communication happens through x-model/x-modalable though).

When I need to pass the data through the form and requests, it would mean that I need to serialize and deserialize class name, id, field name. It would be way too unsafe -- I trust the template calling the component, but I don't trust the client. Also way too much boilerplate.

[JuroOravec]

Hey @mikko-ahonen, I got the code ready, I plan to make an MR for it after we merge #572. I'm out this weekend, so I reckon sometime next week :)

Btw, would you share the generic component? I'm curious how it looks

[JuroOravec]

@mikko-ahonen This has now been released in 0.92! :)