Arguments passed to Alpine.data() are used to automatically call init()

[johndwells]

Related discussion: #1500

Being able to create reusable components with Alpine.data() is great, but the common pattern with reusable components is configurable options/flags when running them. Take for example a custom component that initializes a Flickity slideshow, where one instance page dots are visible, and in another they are hidden...

Also, when a component has an init() function defined, Alpine will automatically call that function when initializing the component. However because of this automatic call, we cannot define init() to accept parameters, and then call it via x-init="init(param1, param2)" because it will be called twice.

What I would propose is that passing any options to component() would be used when automatically calling init(). The resulting markup would look like:

<div x-data="component(param1, param2)"></div>

Thoughts?

[ryangjchandler]

@johndwells I believe one of the main reasons Alpine.data doesn't support arguments / options is that Alpine.data is good when working in a CSP safe environment. Passing arguments through inside of x-data would still require some sort of eval. For now, I'd stick to using global functions over Alpine.data if you're looking to have some customisation / configuration options.

[johndwells]

@ryangjchandler Thanks for the input! Interesting thoughts re: CSP. I still feel as though the combination of auto-calling init() and also not supporting params is sort of a two-steps-forward-one-step-back situation.

I can envision other ways to get around this - such as defining parameters as data- attributes and then inside init() writing some code that picks those attribute values up and applying them as needed. But all of that becomes duplicated boilerplate to pass around the codebase.

I really see Alpine.data as a huge improvement. But I still contend that reusable components often need to be configured on a per-instantiation basis, and Alpine would be wise to support that...

Maybe I need to dig into how plugins are written...

[ryangjchandler]

You could also call your init function something else and use x-init still.

[danddanddand]

You could also call your init function something else and use x-init still.

We're not using Alpine.data() but almost all of our components initialize with empty function which would be compatible with Alpine.data and we simply have a initData( ...params) called with x-init. We even define the empty init function just to make sure no one can accidentally overload it. Something like this:

type AlpineWatch = ( targetProperty: string, callback: ( ( value: any ) => void ) ) => void;

type AlpineMagicProperties<AlpineGlobalStore = {}> = {
    $el?: HTMLDivElement | HTMLInputElement;
    $component?: ( xId: string ) => any;
    $refs?: { [xRefId: string]: HTMLDivElement };
    $watch?: AlpineWatch;
    $nextTick?: ( functionToCall: ( () => void ) ) => void;
    $store?: AlpineGlobalStore;
};

type AlpineMandatoryProps = {
    init?: () => void,
}

declare type AlpineComponent<Props extends BaseAlpineProps, AlpineGlobalStore = {}> = {
    (): AlpineMandatoryProps & Props & AlpineMagicProperties<AlpineGlobalStore>;
};

interface BaseAlpineProps {
    init?: ( () => void ) | ( () => Promise<void> );
}  

[johndwells]

Yeah I know. It's just that, we have as convention been using init() in all of our V2 implementations, so we're used to it.

For the time being though, that's exactly what we're going to do - I'm going to name that function the same as the component itself, so that it appears like a "constructor".

<div x-data="flickity" x-init="flickity(options)"/>

[earthboundkid]

I have changed my components that used arguments to take dataset attributes instead. So, before:

<div x-data="myComponent({ foo: true, spam: 'world' })">

After:

<div x-data="myComponent" data-foo="true" data-spam="world">

function myComponent() {
  return {
    foo: null,
    spam: "",
    init() {
      this.foo = !! this.$el.dataset.foo;
      this.spam = this.$el.dataset.spam;
    }
  };
}

The only thing I don't like about this pattern is that passing a bool via an HTML string is a bit fraught, but otherwise it's cool.

[danddanddand]

This seems like a lot of work to avoid writing x-init="myInit(false, [8, 20], 'blah')" or x-init="myInit({optionA:'foo', optionB:false})"

[johndwells]

I'll admit I don't really grok the CSP implications... If Alpine could parse an attribute as a JSON object, string, number etc, how come it couldn't parse a component call with parameters? Is it because with your attribute way you're actually declaring the variable type?

And yeah I do agree with @danddanddand, this is too far removed from the elegance of Alpine.

But it's lame to have an init() lifecycle call that you can't use iff you want to pass some parameters to it. IMO using data- attributes is slightly less-lame, but it's not self-documenting that a data- attribute in the markup is used by the Alpine component.

[johndwells]

(BTW I am very grateful at the discussion here, thank you all)

[johndwells]

I've just read this page re: CSP: https://alpinejs.dev/advanced/csp

Which, if I'm understanding correctly, means that those who have to comply with CSP would use a separate build of Alpine. So couldn't the parameter functionality be a part of the non-CSP build?

[earthboundkid]

The issue CSP-wise is that it's fine to look at attributes or run JSON.parse, but not it's not okay to evaluate code. So, in x-data="myFunc(1)", the way that it knows that 1 is a Number is because it parses the text as JavaScript and turns the text 1 into a number 1.

I agree that losing the self-documenting nature of the arguments is a shame.

Here's a magic helper that I've just whipped up this morning:

  Alpine.magic("attrs", (el) => {
    let o = {};
    for (let [name, val] of Object.entries(el.dataset)) {
      if (name.startsWith("!")) {
        name = name.substring(1);
        val = val === "true" || val === "1" || val === name;
      } else if (name.startsWith("@")) {
        name = name.substring(1);
        val = val.split(",").map((s) => s.trim());
      } else if (name.startsWith("$")) {
        name = name.substring(1);
        val = JSON.parse(val);
      }
      o[name] = val;
    }
    return o;
  });

And usage:

export default function feed() {
  return {
    feedURL: "",

    init() {
      ({feedUrl: this.feedURL} = this.$attrs);
      // ...

[calebporzio]

Interesting points here. There's a lot of tradeoffs however. As far as the CSP stuff, I don't think that prevents us from offering an API like this: x-data="someComponent({ initData: ... })". That functionality just wouldn't be available for the CSP build (which is fine I think as there are other patterns that have been mentioned here).

Not an obvious answer here, so still interested to here more proposed APIs and thoughts on this.

[ryangjchandler]

I think that the Alpine.data() pattern should just act like a pseudo-function call. In your example, that's fine as you would just receive a second argument to the callback function, i.e. args which is just an array containing all of the things inside of the x-data. Otherwise there's really no benefit to using Alpine.data() outside of a CSP-safe build.

[johndwells]

@calebporzio So with that API you're describing, initData would be set to an object, and then the component's init() would always accept a single object parameter? Or could it be set to an array, and then the component's init() could accept multiple parameters? Sort of like the magic arguments object?

(I am not a JS pro here so apologies that I'm missing a beat here)

... If we consider the original API I had described, x-data="component(param1, param2)", could that be passed to the callback function used to define the component, rather than automatically passed when calling init()? So defining the component with Alpine.data() would look something like:

Alpine.data('component, (param1 = 'default', param2 = false) => {
  // do stuff with params
  return { ... };
});

If that is possible, maybe it's better? It's less magical and gives the author even more flexibility to design their component...

@ryangjchandler I'm afraid I don't understand your comment, so I can't offer thoughts or rebuttal. :(

I defo feel out of my depths discussing the details of this, but I still believe Alpine should provide some documented way for people to pass configurations/info into an Alpine.data() component - something other than resorting back to writing global functions. Because I thought that was exactly the kind of thing that Alpine.data() was conceived to replace?

Again I really appreciate the willingness to discuss!

[earthboundkid]

Apparently, Stimulus loads parameters like this :

<div data-controller="loader"
     data-loader-url-value="/messages">
</div>

// controllers/loader_controller.js
import { Controller } from "stimulus"

export default class extends Controller {
  static values = { url: String }

  connect() {
    fetch(this.urlValue).then(/* … */)
  }
}

We could just automatically pass data-x-whatever="1" as {whatever: "1"}. Something like that is what I would like to see.

[earthboundkid]

Incidentally someone should just rewrite all the Stimulus examples in Alpine to show how much better Alpine is. Sheez Louise.

[seangwright]

I have a scenario where I need to pull data off the window to determine what populates the component:

<div x-data="initialize(42)">
  <!-- ... -->
</div>
<div x-data="initialize(43)">
  <!-- ... -->
</div>

initialize(id) {
    return {
        ...window[id]
    };
}

It would be nice if Alpine.data() accepted params from x-data even when the x-data value isn't a global function:

<div x-data="component(42)">
  <!-- ... -->
</div>
<div x-data="initialize(43)">
  <!-- ... -->
</div>

Alpine.data('component', (id) => ({
    ...window[id]
}));

[earthboundkid]

If I understand what you’re asking for, this was added in #1660. Is that it?

[calebporzio]

yes