Integrating Django-unicorn with Alpine.js

[mands]

Thanks for the great library! Does Django-Unicorn provide any way to integrate with Alpine.js in a similar way to how LiveWire does (e.g. https://laravel-livewire.com/docs/2.x/alpine-js) with $wire and entangle? It would be great to have support for performing the occasional client-only interaction that doesn't require a full-server roundtrip.

[adamghill]

Currently no, not really. The closest thing Unicorn has support for calling JavaScript methods from the component view: https://www.django-unicorn.com/docs/advanced/#javascript-integration (which, I guess is sort of the opposite of what you are asking about).

I've looked at the documentation a few times and tried to figure out how I could provide something similar, but I'm not sure how easy it is going to be -- Livewire and Alpine.js are both made by the same person, so there are integration points he has created for the two projects to co-exist easily. Unicorn might be able to leverage those same hooks, but not sure if it's possible.

[adamghill]

If you have a demo PR which demonstrates how you'd want this to work I could try to figure out how this could work in the future.

[dancaron]

I'm interested in exploring this vector as well.

[imankulov]

I'd like to bring up this old topic again because I encountered the same issue. We use Alpine for client-side changes like opening popups, and so on. We started using django-unicorn, but we quickly realized that updated HTML fragments lose the Alpine state and event handlers.

HTMX solves this problem with their extensions. They have support for morphdom and Alpine morph plugins. The code for both is very simple. You can check out the alpine-morph and morphdom-swap files.

I think it would be great to have a similar mechanism for django-unicorn.

As an experiment, I implemented a proof of concept pull request that adds Alpine morph: #597

Please note that the PR is not ready to be merged. Specifically:

• It doesn't support unicorn:key attributes as node identifiers.
• It doesn't support code execution when updating a node (which the current implementation does).
• It lacks documentation.
• It breaks tests.
• The plugin implementation is not ideal: the plugin choice is hardcoded in the morpher.js file.

That being said, it could be a good starting point.

What do you think, @adamghill?

[imankulov]

By the way, I created a demo project and recorded a video to show how it works with Alpine morph

• Video
• Sample project. Branch experiment/alpine-morph

[adamghill]

I think it's a great idea and am fully onboard. I do wonder if there are other approaches to update the DOM similar to livewire or lit that don't require complete DOM morphing. It could potentially save network bandwidth, but I haven't spent a lot of time working through how exactly that would work so being able to use different morphing strategies still probably makes sense.

Do you think Unicorn should switch to alpine morph altogether or is it useful to have multiple options? Another option would be a phased approach where Alpine.js morph is an option for a few releases and then it becomes the default and morphdom becomes opt-in?

[imankulov]

I am happy to see that you are open to these changes.

@adamghill, in response to your questions:

• I am not sure what else can be used in this context. However, when it comes to DOM morphing, there are alternatives such as idiomorph or diffHTML.
• With this in mind, I would prefer to make it possible to swap morphing libraries and keep morphdom as the default implementation. The reason for using morphdom is that Alpine morph requires adding Alpine to the stack, and I am not sure if it's suitable for everyone.

Another thing to discuss is whether Alpine morph should be vendored in, as morphdom currently is, or end-users should be asked to add Alpine and Alpine morph separately. I am leaning towards the current solution: if you want Alpine morph, add extra script tags loading Alpine and Alpine morph to your head and change the settings. Vendoring morphdome is OK, but vendoring Alpine may backfire, if someone is already using Alpine of a different version. However, I am not 100% sure and open to other alternatives.

If you don't mind, I will continue working on #597 by extending the documentation to get a sense of the final state of the feature. If you like it, I will proceed with the actual and cleaner implementation. However, I may need your help with tests.

[adamghill]

when it comes to DOM morphing

Yep, I have looked at both idiomorph and diffHTML in the past, but never investigated them fully in-depth. I had to vendor morphdom previously because I ended up having to do some tweaks (based on livewire) that deviated from the original. I would prefer not vendoring other libraries if at all possible, especially for "non-core" functionality. Whether using Alpine.js with Unicorn is non-core or not might be debatable 😆, but I tend to think of it more as an enhancement.

Another idea to pursue is a "minimal" build of Unicorn without morphdom included at all for those who want a different morphing algorithm. Not sure how easy that will be with my current rollup config.

If you don't mind, I will continue working on #597 by extending the documentation to get a sense of the final state of the feature.

Sounds great to me!

However, I may need your help with tests.

For sure. I tried to have decent coverage with the ava tests, but they can be pretty finicky.

[gsxdsm]

Just want to bring this back up, would love to see this supported