First-party support for loading Partials

[turbo]

I like to extract components (or partials in general), to other files. At the moment, I'm using something like this to load them:

<div x-data="partial('nav')" x-init="mount()"></div>

function partial(path) {
  return {
    mount() {
      fetch('/' + path + '.html')
        .then(r => r.text())
        .then(h => { this.$el.innerHTML = h })
    },
  }
}

I'd suggest adding an easier way to do this, maybe something along the lines of <div x-html-ext="/nav.html"></div>

Another way I have used this is for simultaneous partial loading and component mounting:

<div x-data="{...partial('nav'), ...navbarComponent()}" x-init="mount()"></div>

[ryangjchandler]

@turbo Alpine was never intended to be used a complete templating framework, it is designed to work with existing markup on a page, so the chances of something like this being implemented in the core are highly unlikely. Especially since this can all be done in user-land or using another package alongside Alpine.

[turbo]

Fetching partial HTML is one of the primary examples in the README. This would simply add way to prevent the fetch boilerplate.

[SimoTod]

Is your example supposed to be async? Because if it's sync, you can already compose partials server side using your preferred technology.

[turbo]

That implies a server with templating capabilities. I often use alpine on sites that are simply served directly (like from S3), precisely because it doesn't require a (server-side) build or parsing step.

I think this is a distinct use case from templating engines (SSGs or SSA). Hence the existence of HTML Imports, which are not-quite-yet-but-soon replaced by HTML Modules. This is maybe best illustrated by the second mixing example. Have the HTML of a component be in a separate file and mount it with data when needed. Adding let's say a templating server, just to also make those components loadable, doesn't follow in my mind. After all, any such server tech is likely to come with functionality that replaces large parts of alpine anyway (<template>s being the most relevant example).

It isn't about just pasting HTML around, but extracting nodes at the component scope into re-usable components. The fact that this basically boils down to loading HTML and setting an attribute is a side-effect of alpine's simplicity. In fact, that second example (the mixin) is a pattern I commonly use, whether it's in the interactive-mockup phase or the final site. So adding a few lines to alpine seems like the better solution to me.

So

<div x-data="{...partial('nav'), ...navbarComponent()}" x-init="mount()"></div>

would become something like

<div x-data="navbarComponent()" x-html.fetch="/nav.html"></div>

(Feel free to think of a nicer syntax, maybe one that would also simplify the dropdown-fetch example in the README)

[HugoDF]

Hmm unfortunately that would mean that Alpine becomes "fetch-aware" which is something it's explicitly designed not to do, as much as possible it isn't opinionated about anything that's JS

[turbo]

@HugoDF OK, fair.

Is there a way then to hook into alpine's custom attribute handler to extend it? Say I have separate a JS file which adds that functionality, can I hook into alpine's handling of e.g. x-html or register a custom attribute handler (e.g. x-custom) to be handled by my code?

BTW I realize that I could do attribute parsing myself, but I'd like to prevent DIYing it because alpine is already doing it (and probably more robustly than I what would come up with).

[SimoTod]

at the minute, there's no easy way to extend or hook into existing directives as far as I know but the source code is not huge and it's not too complicate to understand so feel free so have a look and see if there's anything you can use.