Prepopulate x-model with value of input

[motine]

Hi,

alpinejs is great! it is exactly what the frantic javascript world needs, just enough to get away with and be productive as hell. Thanks for that!

I want to use alpinejs in a Rails project. There the input fields are rendered by the server and may contain a value. Now, when I want to implement a simple show/hide logic for a dependent field, I would like to use x-model (I explored other options, but this seemed the most elegant one). The only trouble is that since I defined the x-data attribute on the parent, the server-given value is ignored. I would have to write dedicated logic to add the server value to the parent's x-data. This seems exhausting. Here an example:

<div x-data="{myval: ''}">
  <input type="text" placeholder="simple" x-model="myval" value="xxx"> <!-- the value is ignored and the input comes up empty (as advised by the parent) -->
  <input type="text" placeholder="only show if simple is filled" x-show="myval != ''">
</div>

Now, I have three ideas, but would be happy if there are more:

1. add a modifier to x-model which allows to force the the copying from the value initially (e.g. x-model.attain)
2. always use the value of the input if the x-data declaration of the variable was undefined, null or another dedicated value
3. add a new directive which only sets the reactive value but does not read from it (e.g. x-set="myinput")

What do you think?

[SimoTod]

3 kinda exists already x-on:input="myval = $el.target.value"
2 could be a breaking change for some user
1 could work but if you are not interested in 2 way binding i would stick to the input listener (remember to use change for select and checkboxes)

[motine]

Mmm, I played with input/change handlers and it does not seem as elegant as just using a directive.

what ideas do you have to make this elegant?

[SimoTod]

It depends on your concept of elegant. It reads nicely, it's clear and any alpine developers will understand it at first glance.

x-on is a directive by the way (https://alpinejs.dev/directives/on) and it achieves what you proposed at point 3, you probably also need x-init to set the value the first time though.

Alpine v3 is easily extendable so you can create a new directive x-set (https://alpinejs.dev/advanced/extending#custom-directives) for your projects that does the same (x-on + init) but I don't think it would make into the core since it's already possible with the current directives.

[motine]

cool. thanks for the feedback. I took the ideas and implemented a very basic framework. this now fits my use case a little better: https://github.com/motine/waft.js

[JeremyJaydan]

I like the idea of the .attain modifier on x-model.

Makes sense to treat the initial value attribute as an input event, though .dispatch might be better to signify the input event being dispatched if so, not sure.

[glaszig]

i like the idea of the .attain modifier on x-model.

we have a winner.

[motine]

hey @calebporzio, if there were a merge request for the attain modifier, how would you estimate the chances to be merged? (provided the implementation is fine)

[marcandre]

Completely agree. Personally, I like option 2 the best, i.e. values of null get overriden automatically by x-model (and it was the behavior I was expecting)

[f-liva]

Any news here?

[motine]

unfortunately, nothing from my side.

[nandastone]

Would also love this functionality as my use case is sprinkling interactivity into legacy Perl-driven templates.

Currently I'm using x-init="" and setting the initial value based on template variables, but I'd much prefer to just simply pick up the initially rendered template value.

<div x-data="{ optoutType: '' }">
  <select x-model="optoutType" id="id__optout_type" name="sms_optouts">
    <option value="" <TMPL_IF EXPR="!sms_optouts">selected</TMPL_IF>>Email Addresses</option>
    <option value="1" <TMPL_IF EXPR="sms_optouts">selected</TMPL_IF>>Phone Numbers</option>
  </select>
</div>

Suppose "Phone Numbers" is selected on page load, optoutType should be "1".

[ekwoka]

Why not just put the template tag directly into the x-data to set the initial value?

[nandastone]

That's what I ended up doing, but it's not ideal because the template tag could in fact be conditional tags, logic, etc.

Yes, a good app should refactor that stuff into a single template variable but we don't always have that luxury in legacy apps, which is where Alpine.js shines imo.

[msurdi]

I'm trying out this as a workaround:

<form x-data="{
    username: $refs.username.value,
}">
  <input x-ref="username" x-model="username" value="something">
</form>

I haven't tested it much yet, but so far seems to be working well.

[Restartz]

If I understand correctly, the idea is to force the value bound by x-model to initially be set to the input's value only if the bound x-model value is either null or an empty string?

So this?

<div x-data="{ myValue: null }">
  <input x-model="myValue" 
         x-init="myValue = (myValue === null || myValue === '') ? $el.value : myValue" 
         value="123456" 
  />
</div>

But then using a modifier like for instance something like so?

<div x-data="{ myValue: null }">
  <input x-model.fill="myValue" value="123456" />
</div>

[joshhanley]

@motine all I can do is send this discussion to Caleb, but there's no guarantee he will look at it. And yeah Caleb is the person who makes the final decision regarding new features. If it were me, I would just submit the PR, as he does review them 🙂

[motine]

cool @joshhanley, i would like to take your offer. i am currently quite busy, so this move would be very useful to determine if it is worth putting the time in. thanks again for the offer and let’s see how @calebporzio likes the proposal.

[Restartz]

It’s actually a pretty tiny change.
I’ve had it ready for 3 days now (as a modifier, not as default behavior), but then it turned out the modifier name and the actual behavior was still up for discussion so I haven’t send in the PR yet.
I’m still not sure what we’ve settled on now?

[ekwoka]

Just make the PR and any implementation discussions can happen in there :D

I was going to do it this morning, but I'm having all sorts of tests failing locally on a fresh clone :(

[Restartz]

I also really gotta get a better setup for testing locally. Here's the PR #3423

[calebporzio]

Of all the APIs I like yours the best @Restartz

Here is my low-effort scratch pad of ideas:

I'm still not totally convinced we should add anything to core to address this. It would be nice to gauge demand on a broader scale. Like I'm sure more people want this than are represented in this discussion, but how many more?

I'd hate to add a bespoke API that we have to document and maintain forever and very few people ever use it or no about it.

Another reason I'm super hesitant with this stuff is every little feature adds to the amount of JS that has to be shipped to browsers (as opposed to adding APIs to a backend framework).

That said, it seems like it would have a fairly simple, few line, implementation.

So maybe just put the PR up and we can decide a little further down the road.

Thanks for the input everyone.

Oh also, I DO see the use case for this in a rails-esque environment where you want to use Alpine to augment form inputs.

But I just wonder if a developer encountering this hurdle will make their way to this API and be satisfied. Of course it's ideal to make this the default behavior. But alas, as mentioned, my gut says that 's a breaking change (and not a bug, but I'd love to be convinced otherwise)

[Restartz]

Great! It's indeed a fairly simple change.
There's already a PR #3423 :)