Should components have access to data from other components?

[adamghill]

How useful would it be to be able to access a component's data from another component? Right now, the closest thing is https://www.django-unicorn.com/docs/actions#calling-methods, but that's a little different.

[nerdoc]

[nerdoc]

• The first solution (1 parent, 2 children) was also the first I thought of. Gave me the creeps, so I left it alone 😱
• Signals introduce a whole bunch of other problems including spaghetti code...
• Getting access to the data is trickier. Then you 'll have to setup a whole properties system like Vue does. I think keeping most of the data in the backend is perfectly ok. I think that bumping another component from the frontend side so that updates itself, would be enough.

In most cases I may think of, you set a trigger in one component, and want that something happens. In the websockets works, all components that have a link to that change, do a self-update. This is not possible with AJAX.

Your solution with call_component seems nice to me. Maybe it would make sense to introduce an easy trigger like an unicorn:after-reload-update="component-name-or-key.method-name" - but that's a bit awful too. Perhaps you got a bigger picture and a better idea.

[nerdoc]

Another use case for the call_component would be Django's messaging system. Cne could define a MessageView component as in the docs/examples, and instead of using Django's messaging, use a wrapper function (should I open another discussion topic ?):

class FooComponent(UnicornView):
    def message(text):
       unicorn.call_component("message-view","add_message", text)

as simple idea (with additions like info, warning etc tags). the MessageView then gets updated too at the client (is this possible, to update 2 components using morphdom?

[nerdoc]

I've seen another interesting "solution" for piggy-packing data in a call for another element. HTMX does this with hx-swap-oob. This could maybe be a solution in Unicorn too: If an element in the response has the u:oob (or any other word) directive and an id, the element would be not rendered in place, but the element with the same id on the page would be replaced with that element.
So e.g. a response in a search field component could be:

<input type="text" placeholder="Search".../>
<ul unicorn:oob id="results">
<li>foo</li>
<li>blah</li>
...
</ul>

and the #results could be anywhere in the page - e.g. options tags in a select element.

What do you think of that? It does not solve the problem of "accessing" data of other elements - but this would be a server side issue, regarding encapsulation topics too.

[nerdoc]

Is target-by-id something that could be used for that?

[nerdoc]

I came a bit further with this topic (and learned a bit more Unicorn...). I solved my problem with your parent/child component pattern (nice example!), and I think this is great.
Regarding accessing other component's data: I don't think this is really a good idea, as it weakens encapsulation.
Calling self.parent.update_foo() in a child component is a great feature.

But when I think of e.g. calling a completely different component's method - you 1) have to be sure that component's on loaded ATM ("on the page"), and 2) what if are more than one components of that kind loaded?

Signals are better used as few as possible (if you hear the Django devs).

So what remains, is calling other components' methods - in the backend - and that's IMHO enough. And even unicorn.call_component("message-view","add_message", text) has no real benefit over doing a messages.warning(text) anywhere - and finding a solution for the other (e.g. MessageView) component to update the screen. Polling, websockets etc.

[tanssinet]

Any further ideas on this? I am trying to use Unicorn in one new part of an existing app, and the communication issue came up.

The pattern I often see is that there are different kinds of components: one is more like a Django Field, and one is more like a Django View. One idea could be that View components could be nested, but Field components could not, or something like that.