$teleport helper

[MuzafferDede]

Discussion about $teleport helper

Purpose of $teleport helper is move an element from one point to another point on DOM. It will be useful for those cases where part of the component could be somewhere else and still does its reactive jobs. More like reactive remote partials of a component.

It feels like Alpine might gain some templating power with this helper.

Topics

• Name of the helper: $teleport | $portal | you tell me
• How to keep in-out reactivity after teleport. (Currently teleported element's properties are not updated if initial parent updated. But some part of the reactivities are still works from teleported element to initial parent)
• Should we keep it simple at first and extend its abilities later on? (What would be the minimal abilities?)
• Should it accept 'string' defined elements to be teleported? [Wip][Feature] Add teleport helper #42 (comment)

[KevinBatdorf]

1. Let's see how the functionality ends up first.

[KevinBatdorf]

2. Alpine components can be single elements and communication is possible already through events, Spruce, or $component already. This feels like something that would add unneeded complexity and well... headaches in Discord.

Besides that, I don't think this will even be possible given how Alpine watches and updates state. $refs, for example, wouldn't work since Alpine traverses the component directly as needed.

[SimoTod]

Yeah, I initially raised the question because I can't see it working easily without changing Alpine's core.
I'm not a big fan of portals either, I don't get them to be fair but I know many people love them. :D

[MuzafferDede]

    <div x-data="{text: 'Initial text'}" x-id="mainComponent" x-init="() => $teleport($refs.teleporter,'#teleportDestination')">
        <button x-on:click="text = 'changed text'">change</button>
        <div x-ref="teleporter">
            <div x-data x-text="$component('mainComponent').text"></div>
        </div>
    </div>
    <div id="teleportDestination"></div>

I think we don't need to implement anything. We can just let $teleport to move an element to destination. We can handle the connection between ex component using $component. I just tried this and it's working.

[MuzafferDede]

<div class="p-2 border border-red-500 mb-2" x-data="{count: 0}" x-id="mainComponent" x-init="() => $teleport($refs.teleporter,'#teleportDestination')">
   <button class="p-2 bg-red-500 text-white rounded" x-on:click="count++">+1 by intial</button>
   <p>Current parrent count: <span x-text="count"></span></p>
   <div x-ref="teleporter" class="p-2 border border-red-500">
      <button class="p-2 bg-red-500 text-white rounded" x-on:click="$component('mainComponent').count++">+1 by teleporter</button>
      <p>In teleported element but outside of x-data: <span x-text="$component('mainComponent').count"></span></p>
      <div x-data>
         Teleported element count:
         <span x-text="$component('mainComponent').count"></span>
      </div>
   </div>
</div>
<div id="teleportDestination"></div>

Another sample which shows that if some elements are not in the x-data component, they wont get updates from parent even they use $component helper

[KevinBatdorf]

Yeah I don't think it's going to work. And I don't really think it's a good pattern to split up components anyway.

I also don't think it would be good to have a dependency of another component helper either.

[MuzafferDede]

<div x-data="{count: 0}" x-init="() => $teleport($refs.teleporter, '#teleportDestination')">
    <button x-text="count" x-on:click="count++"></button>
    <button x-ref="teleporter" x-on:click="count++" x-text="count">test</div>
</div>
<div id="teleportDestination"></div>

//teleport.js

if (!element.__x) {
    updateOnMutation($el, () => {
        syncWithObservedComponent($el.__x.getUnobservedData(), $el, objectSetDeep)
        $el.__x.updateElements(element)
    })
}

No more dependency of another helper. How about now? :)

[KevinBatdorf]

It could be useful, however, to transport entire components. For example, imagine an a slideshow slider that when clicked on you transport it to a modal lightbox type component, with the state in tact. Currently you can do this easily enough by passing the state over manually, but a helper to make it intuitive would be good.

You'd have to consider whether the component can get back "home" as well. I think it should.

[KevinBatdorf]

Should it accept 'string' defined elements to be teleported?

Maybe this could be a second helper (think $template) that then works together seamlessly with $teleport

[MuzafferDede]

This is already fixed by:

   return function (from = $el, to = document.body, options = { prepend: false }) {
      // Figure out element that needs to be teleported
      const element = typeof from === 'string'
      ? document.createRange().createContextualFragment(from) << HERE
      : from
...

[MuzafferDede]

Name of the helper: $teleport | $portal | you tell me

If no one is against it, let's keep it teleport.

---

How to keep in-out reactivity after teleport. (Currently teleported element's properties are not updated if initial parent updated. But some part of the reactivities are still works from teleported element to initial parent)**

I think we got it working as expected now. Reactivity works both way even teleported element is not a component. It's still watches changes on initial component and updates itself if any updates.
#46 (reply in thread)

---

Should we keep it simple at first and extend its abilities later on? (What would be the minimal abilities?)

For now it teleports an element to target and it keeps reactivity which is minimal abilities imo. So if anything else, let me know.

---

Should it accept 'string' defined elements to be teleported? #42 (comment)

Now we can define string templates and teleport with no problems.
#46 (reply in thread)

@KevinBatdorf @HugoDF @SimoTod Any thoughts?

[KevinBatdorf]

I probably won't have time to take a look until Friday, but I'm probably not going to like it ;) I'll keep an open mind though.

Does it work with everything including $refs? events (event bubbling I'm guessing no)?

Does it feel native?

[MuzafferDede]

Well, maybe you are right. Teleport might be unnecessary for Alpine at this moment. It's fine. I might work on it more on my repo and let's see how it goes.

[SimoTod]

You can still publish your own helper if we decide not to include it for now but you want to use it/publish it. I didn't have time to check it out today so I don't have any feedback for now.

[KevinBatdorf]

I'm still not totally against it if we can get it working nicely.

I do like the template stuff a lot though. I wonder how we can expand on that.