Components hidden by default, such as mobile navigation menus, get cached and cause flickering when navigating between pages. about alpine-turbo-drive-adapter

[SimoTod]

Gotcha. Yeah, it's not the traditional use of x-cloak but i can support it, no problem. It will likely be tonight or tomorrow.

[SimoTod]

Glad it solved it (again). It gets complicated when livewire is involved and I can't have unit testa for that. I still need to check how it behaves in ie11 and edge but I should be able to tag 0.2.1 tomorrow or Monday. 👍

[SimoTod]

@heyfadii tonight/tomorrow.

[jduff]

I'm using something like this in my project and can PR it if you think it's a good approach

document.addEventListener('turbolinks:before-render', (event) => {
  event.data.newBody.querySelectorAll('[x-cloak]').forEach((el) => {
    el.setAttribute('was-cloaked', '');
  });
});

// Cloak elements again before caching
document.addEventListener('turbolinks:before-cache', () => {
  document.body.querySelectorAll('[was-cloaked]').forEach((el) => {
    el.setAttribute('x-cloak', '');
    el.removeAttribute('was-cloaked');
  });
});

This depends on using the x-cloak attribute, but that seems to be common practice for cases like this.

[SimoTod]

@jduff It seems to be a sensible approach, thanks for sharing.
Does it work on the very first visit when the page is loaded by the browser or do we also need to cover that case as well?
Happy to accept a PR, we can build on that if we need to.
Can we prefix the custom attribute with data-alpine- please?

[jduff]

Does it work on the very first visit when the page is loaded by the browser or do we also need to cover that case as well?

It doesn't look like it's running on the first page load. I've been trying to get that to work from a turbolinks:load event but it looks like Alpine has already run at that point and removed the x-cloak attribute. I came across the deferLoadingAlpine function here which seems to get it to work.

So something like this:

window.deferLoadingAlpine = (startAlpine) => {
  document.addEventListener('turbolinks:load', () => {
    document.body.querySelectorAll('[x-cloak]').forEach((el) => {
      el.setAttribute('was-cloaked', '');
    });

    startAlpine();
  }, {once: true});
};

This sets up the turbolinks:load in the defer callback to only execute once, it then does the x-cloak magic and once that's done it starts Alpine.

Does that make sense or is there a better way to do this?

[SimoTod]

do we need to wait for a turbolinks:load event? I assume it could just run.

deferLoadingAlpine is used by other libraries so I don't think we should just override it. We need something like

const init = window.deferLoadingAlpine || ((callback) => callback())
window.deferLoadingAlpine = (callback) => {
    document.body.querySelectorAll('[x-cloak]').forEach((el) => {
      el.setAttribute('was-cloaked', '');
    });
    init(callback)
}

To be fair, since Alpine waits for the DOM ready events anyway and the javascript engine runs as a single thread, I suspect it could just go inside the init function (https://github.com/alpinejs/alpine-turbolinks-adapter/blob/master/src/bridge.js#L15) without involving events.

init() {
    document.body.querySelectorAll('[x-cloak]').forEach((el) => {
      el.setAttribute('was-cloaked', '');
    });

   //etc etc
}

Any thoughts?

[jduff]

That looks like it could work, I'll put together a PR tonight.

I was using the turbolinks:load event as an alternative to ready. I think we still want to have it happen after dom ready though, don't we? As far as I can tell init is called right away and it's possible the DOM isn't fully loaded yet, or am I missing something here?

I think either way I need to put together a PR and we can continue the discussion there :).

[SimoTod]

The idea is that the script is defered so init should run before domready but when all the html is there. I guess we can't force user to defer the script (expecially if they create a bundle by themselves).
I'm happy with the deferLoadinAlpine if it works.
Bonus point if we can write a test but it's not a blocker for this PR.

[SimoTod]

@jduff Unfortunately the change conflicts with the way Livewire work (Livewire is not deferred and the order of events is not correct).
I've got a new version at https://cdn.jsdelivr.net/gh/simotod/alpine-turbolinks-adapter@fc19881d2dae4c2b8b3fd790383d890f26aa14a8/dist/alpine-turbolinks-adapter.min.js
Do you have any use cases I can use to test it works correctly?
@zepfietje can you confirm it fixes your issue as well?

[jduff]

@SimoTod I just gave it a test in my project and it seems to be working correctly. I'm pretty sure the first test I added, https://github.com/SimoTod/alpine-turbolinks-adapter/blob/master/tests/integration/cloak.spec.js#L4, failed before I added the defer loading so if that's passing I think it covers the initial load case that I added the deferloading for.

I ran a quick test in my project with the script itself bother deferred and and not deferred and it worked in both cases for me.

[SimoTod]

Yeah, your PR works in normal cases but in a project using Livewire they both tries to defer alpine using an event but they don't work well together. Ready state interactive should trigger before domready (so Alpine starting) but after the whole dom has been downloaded. Hopefully it will serve our purposes. I need to do some cross browsing tests over the weekend but I'm glad it looks like it could work. The workaround for livewire user for now is to remove the defer attributes from the adapter library.

[zepfietje]

@zepfietje can you confirm it fixes your issue as well?

Seems to fix my issue!

[SimoTod]

Closing as it was fixed in 0.2.0

[heyfadii]

The merge #13 breaks the responsive x-cloak functionality. As I see it, the x-cloak="mobile" would be replaced by x-cloak="". Is there a way to opt out on this and write my own custom solution?

[SimoTod]

Thanks @heyfadii, can you send me an example please? X-cloak is a boolean attribute and it does not support the syntax you posted if i remember correctly so you cannot decide to apply it conditionally based on a value.

We can keep the value but I'm not sure about the benefits and it wouldn't be standard alpine.

[heyfadii]

Sure. What I want to do is hide something conditionally, depending on the resolution. I found this example: https://dev.to/hus_hmd/alpine-js-responsive-x-cloak-3blp

[SimoTod]

@heyfadii Can you confirm that https://cdn.jsdelivr.net/gh/simotod/alpine-turbolinks-adapter@feature/x-cloak-value/dist/alpine-turbo-drive-adapter.min.js does what you need? Thanks.

[heyfadii]

@SimoTod Sorry for the delay. Yes works! when can this be expected to be merged? Thank you for being fast as lightning!