Alpine: [Feature] init from data object

[shadoWalker89]

Hi,

Currently we can add an x-init to do something on init.
@calebporzio are ok with using a function named init in the data object as the hook for the init ?

function myComponent() {
    return {
        init() {
            // Some init stuff
        }
    ];
}

I could make a PR

[danfascia]

I think it's good to keep it versatile and allow a user defined function call in x-init rather than get too opinionated even though I nearly always call the function init() in the data object

[luizpvas]

I've used this pattern in a couple different components. For example:

<input class="field__input"
    placeholder="E-mail"
    name="new_users_emails[]"
    x-data="components.autocomplete()"
    x-init="init()"
/>

An automatic init function (maybe connect, similar to stimulus?) would make the HTML for reusable components a bit nicer and less error-prone.

[shadoWalker89]

I think it's good to keep it versatile and allow a user defined function call in x-init rather than get too opinionated even though I nearly always call the function init() in the data object

I never said that x-init should be removed, i'm talking about adding the init function hook. 😄

I've used this pattern in a couple different components. For example:

<input class="field__input"
    placeholder="E-mail"
    name="new_users_emails[]"
    x-data="components.autocomplete()"
    x-init="init()"
/>

An automatic init function (maybe connect, similar to stimulus?) would make the HTML for reusable components a bit nicer and less error-prone.

That is what i'm doing now, but i want to use the init() function without defining x-init. To me that feels a lot cleaner. I personally think that an init behavior should be coupled to the component and i shouldn't have to use an additional step x-init to tell the framework how to do it. But i'm cool with x-init as an option for the people who like it.

[gsempe]

From my user point of view, I do prefer the explicit usage of x-init over an implicit behavior.

I think that Alpine changes should follow a direction that keep as low as possible the learning curve. Implicit behaviors make the onboarding of new developers more difficult and so I would say that this idea is not good for Alpine itself.

One more time, that's only my personal vision of Alpine.

[gsempe]

I think as well to provide alternatives like proposed here, has the same effect to make more difficult the usage of the library for new users

[shadoWalker89]

I think as well to provide alternatives like proposed here, has the same effect to make more difficult the usage of the library for new users

Aside from this being accepted by caleb or not, adding a hook doesn't make it harder for any one. It's just adding another way of doing things.
Difficult is subjective in this context. I mean why do you think that x-init="someFunc()" is easier then having an init() hook.
Using hooks is a very well known pattern in the js world, it's not something new.
See vue for example.
IMHO what makes something easy or difficult is syntax and documentation. A framework should take into consideration beginners as well advanced users.

Hope we hear from @calebporzio soon 😄

[gsempe]

I mis-explained my point of view. I was opposing implicit vs explicit.

I find Alpine very interesting because it makes possible for developers like me who do web development sporadicaly to get the into it very quick without multiple steps of setup and learning. (like Tailwind CSS actually). I imagine advanced web developers would stick to Vue or React as they are used to them.

That's reason why I think adding alternatives and/or implicit behavior is not a good idea.

It's just an external point of view. I'll continue to use Alpine anyway.

[calebporzio]

Yeah, I envisioned automatically calling an init method if it exists in the data object. I'm down for it if the implementation is clean and doesn't add much overhead.

[ryangjchandler]

Hi guys, I'm going to close this issue since the pull request got closed. If you think it's a vital feature, please open another issue in the future but I believe Caleb has some plans to implement this in the future anyway! Thanks again for contributing :)