Reactive parent to child communication

[loomchild]

Hi,

I am trying to build a few simple reusable components for my site, and I am running into difficulties. I need to communicate some state bi-directionally between the parent and the child. This is needed for example when implementing an accordion question component, a spinner controlling number of input rows, etc.

It's easy to pass the value from child to parent via a custom event (e.g.: @update="children[id] = $event.detail"). However, I am struggling to pass the value from parent to child in a reactive manner. I know that this problem could be solved using the store, but I'd like to avoid that to keep the child components fully independent of the parent, to make them reusable in different contexts. In this video video there's a cool suggestion about using getters and setters, but it still requires the child component to access the parent state directly.

Coming from Vue.js world, I'd love to have a x-model directive for custom components (more info, including syntax updated in Vue.js 3). In Alpine.js docs, I found information about dispatching to x-model, but it seems to only pass the @input event to the parent.

Not being particularly bothered having to declare value and event separately instead of using a single x-model directive, I came up with the following solution using the x-effect directive and partially inpired by Vue.js @update:field event syntax (see this codepen for a complete live version):

document.addEventListener('alpine:init', () => {
  Alpine.data('question', () => ({
    expanded: false,

    toggle () {
      this.$dispatch('update:expanded', !this.expanded)
    }
  }))
})

<div x-data="{ current: null }">
  <div x-data="question" x-effect="expanded = (current === 1)" @update:expanded="$event.detail ? current = 1 : current = null">
    <h2>
      <button @click="toggle">
        Question 1
      </button>
    </h2>
    <div x-show="expanded">
      Lorem ipsum bla bla bla...
    </div>
  </div>

  <div x-data="question" x-effect="expanded = (current === 2)" @update:expanded="$event.detail ? current = 2 : current = null">
  ...
  </div>
</div>

Could you tell me whether it makes sense in your opinion and if there are any better alternatives?

Thank you in advance!

[SimoTod]

I believe that tutorial was for v2. In v3, child components can read/write parent properties

[danddanddand]

Because you children always inherit parent scope, it’s pretty trivial to “register” the children by pushing element to a child array as in your example in x-init. It’s not super clean but doable. The important part is that the parent has to manage the state so it’s less about accessing child state and more about managing it.

[SimoTod]

Do you mean that your child doesn't have any knowledge of the parent state? In that case even your original example wouldn't work because you were mentioning current in xeffect.
you can use events in a v2 way. Technically you don't even need cuatom: toggle will trigger a custom event, and each component can listen using the window modifier and updating their state accordingly.
If you need current for other reason, you can just listen for the same event on the parent component and even trigger a new event if you prefer.
This kind of comunication goes only upwards but children can set up listener on window to intercept messages from a parent object (you'll need to send a suitable payload on the event so a child can understand if the message is for them or not).

[loomchild]

I mean that I can implement a child component (question in above example), without any knowledge about how it will be used - kind of a generic component, like Alpine.js components. Sorry for still not being clear.

This way I can share it between projects or package it in a library. The x-effect trick works since I don't have to modify the question component code to integrate it with a parent. It might be even used without a parent.

I could use window events as a way of communicating between parent and children, but it would be harder to manage if there are multiple child components on a page, since they would likely all have to listen to the same window event (IMHO window events are sort of global, like a global state).

I personally think the x-effect is more elegant since it affects only a specific child. On the other hand ot would be even nicer to have a x-model working in Alpine.js in similar way as in Vue.js (I know, I am biased and Alpine.js has different goals than Vue.js:).

[SimoTod]

Well, if you just share the js part and not the html yeah. Personally i find it a bit verbose but if it works for you, it's the right solution for your projects. There are many ways to achieve it and you have already decided anyway. :)

[loomchild]

You are right it's not ideal!

In fact I know I am partially missing the point of Alpine.js, since I should combine Alpine with a different components/encapsulation/templating mechanism instead of relying only on Alpine.data(). However, I am sometimes working in a an environment with relatively limited component support (Webflow) or even pure HTML. In such cases sharing functionality via reusable Alpine.js 'data components' is sometimes useful.

Thanks very much for sharing your thoughts, it got me thinking about the problem on a deeper level...