async-alpine: Doesn't support dynamic content

If content is loaded with ax-load present, it won’t be handled as an asynchronous component.

This may be tricky to implement, we’d have to use a mutation observer and ensure the DOM is changed before Alpine’s mutation observer can be triggered.

This would prevent Async Alpine from working with client-side routers and similar, which is a fairly major area that Alpine works well in.

Needs more research.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 22 (22 by maintainers)

Most upvoted comments

As for the architecture of 0.4 of Async Alpine, I think I’m going to go for continuing to use x-ignore and telling developers to add it to all components.

In actual fact we’ll add it to any components that don’t have it on load, so technically it would be optional for non-dynamic content but strictly necessary for dynamic content.

I’m considering just saying that it’s required in the documentation though for simplicity.

I’ve implemented a 0.4.0 version in the 0.4-rebuild branch using this method and it works really well!

  • Allows for dynamic content with Mutation Observer;
  • Uses x-ignore so doesn’t need to rename attributes—resolves #18;
  • Simplified structure and improved performance significantly;
  • Adds alternative way of registering components with AsyncAlpine.data('name', callback)—resolves #7;
  • Breaking: Changes API to be more similar to Alpine;
  • Breaking: removes ‘parent’ strategy—now nested components can only load when their ancestors have;
  • Breaking: In order to support dynamic content, the names of inline components need to declared in advance with .inline('name')

Overall I’m really happy with this rebuild and with how this improves the project. I need to test it further with some larger projects, and would like to test it to see how it works with other build systems—particularly Vite. Merging and the 0.4 release will come after this testing and updating documentation.

Thank you @iniznet for your fantastic contribution to this issue, you’ve helped sort every issue I was having in one fell swoop!

@iniznet Your approach is really interesting and looks like it could be a great solution. I’ll need to give this a try for Async Alpine, unless you want to implement and PR it yourself? I’d be open to that.

I attempted something similar when I was first prototyping Async Alpine, but ran into the issue of undefined properties with the dummy component. I didn’t think of using x-ignore at the time, I really like how that cleans things up. I’ve been preferring a rename pattern to allow for independent loading of nested components but if I have to sacrifice that to have a nice dynamic loading API I will.

I couldn’t find a way of jumping on Alpine.mutateDom unfortunately, that didn’t seem like a realistic solution.