adding x-for sort as default

[excitedbox]

I was just running some tests on x-for and since having a list of items like letters: [a:'' , a:'' , a:'' , b:'' , a:'' , a:'' , a:''] would only run through the first 3 items wouldn't it be a good idea to have x-for sort the objects by default. That way it will run through all of them which is the expected behavior of an array iterator.

using objects for x-data and therefore x-for brings lots of downsides with it and I wonder if there is a need for some real looping and arrays as well. As someone who has not been with Alpine for a long time it seems like every time I want to do something I run into a brick wall. Usually related to limitations of what should be Alpine's best features. I find myself reaching for regular JS over and over in which case it is easier to just not use Alpine at all because using a touchy x-for / x-data system is just tying a weight to ones leg when you are calling a JS function anyway. It is just as easy to use a Html/CSS event to call that function without the overhead and reliability risk.

My suggestion would be to create some solid, versatile and easy to use looping and data access functions and a easier event system. Those would be the KILLER FEATURES for Alpine JS. Calling a JS function in a html document is not a problem but simple on events need too much JS because of the verbose syntax. The direction Alpine is heading right now is Simplicity which is good but simplicity shouldn't come at the cost of functionality, ease of use or getting things done.

[SimoTod]

Can you post an example in a codepen? [a:'' , a:'' , a:'' , b:'' , a:'' , a:'' , a:''] is syntactically invalid in js. Array don't have keys, only numeric indexes. As object, it would be invalid as well since you can't have 2 keys with the same name.

[excitedbox]

I meant something like this. If you were making a navigation bar or something and only wanted to print section1 items.

      <div x-data="{itms:
        [ { section1: [{name:'tab1',value:'tab1'},{name:'tab2',value:'tab2'}]},
        { section2: [{name:'tab1',value:'tab1'},{name:'tab2',value:'tab2'}]},
        { section1: [{name:'tab1',value:'tab1'},{name:'tab2',value:'tab2'}]}">

If you run an x-for to print section1: items it will only print the first 1 because once it hits section2 it thinks there are no more. If you order them ie. putting section1 first and then section2 you can use x-for to print out all the section1 tabs. Otherwise you need to add a JS function to filter non section1 items.

[SimoTod]

That would be tailored to your specific use case and cause a lot of bugs for people that doesn't want that since it would always shuffle the array and change the original order.
Calling a js function in x-for is perfectly legit and the way alpine is meant to be used.
I hope it makes sense.

P.s. I'm not sure about the example again. Have you tried the change you suggested? x-for="item in items.section1" is not valid syntax. Either you loop on items or on items[0].section1.
Can you post a full component please including both x-data and the x-for you would expect to use please? Thanks

[KevinBatdorf]

I find myself reaching for regular JS over and over

Just my opinion, but to me this is a feature.

[excitedbox]

If you are just gonna use regular JS anyway though it is easier to use ONLY JS and it causes less issues and wasted time.

First you try and do something and it doesn't work.
Then you look for bugs.
Realize it doesn't work or isn't possible.
Then you use JS.

Seems like a bad way of doing it. There is a difference between removing complexity and removing features. When you read Alpines "sales pitch" it seems like it is trying to make it easy to modify styles and pull in data without having to use JS. In reality it just adds another layer of abstraction with very little gained.

When you look at the things asked about most in the issues and discussions on git and stack overflow it is always about manipulating CSS and looping. The answer is always no that isn't possible you have to use JS. But that is obviously not what people are looking for when they choose Alpine. They want to reduce the use of JS. If the answer is always use JS then why even use Alpine at all?

I understand Alpine is still in early phases and there will be kinks to work out so I am just trying to bring attention to those things that could be improved. Alpine needs to offer a clear path on what it can or can't do and what it can do shouldn't make the work harder.

[KevinBatdorf]

Alpine just exposes a new API on the dom for you to interact with elements using JS. You're always using vanilla JS, with the exception of a few helpers like $refs, $dispatch() and others that are just wrappers JS functionality. 99% of what you will use is regular ol' JS.

If the answer is always use JS then why even use Alpine at all?

Alpine abstracts the hard parts like setting up mutation observers and keeping track of events, transitions, etc.

Hope that helps. I'm happy to answer more questions and dissect any examples you'd like to share.