x-for for CSP build

[MichaelMackus]

I've been running into a few issues with the CSP build, most recently the main issue is that the x-for directive isn't working at all from what I can tell. (Neither is x-model, there is an open PR for that to fix it.)

Is there any way to iterate data with the CSP build? I even tried x-for="items" which would be quite sufficient for my needs (maybe a default could be key and value for each item to start.. but I suppose that's not going to work well with nested for loops). I guess a bit more advanced syntax parser would be a huge help here, since there's no reason to use eval for a simple "item in items" string IMO.

If this is something that I could help with a PR I would definitely work on that, but I just want to get some direction first to make sure I start down the right path.

[MichaelMackus]

I figured out why this isn't working, but I am not quite sure how to fix.

The expression evaluator actually does work in the CSP build (so it is properly finding the key/value part of the expression, so that is not the issue at all here). However, the issue comes in when I try to assign x-text using a dot notation to access part of the value object inside the loop.

For example:

  <template x-for="title in item_titles">
      <h1 x-text="title"></h1>
  </template>

Works fine with CSP build. However, this does not:

  <template x-for="item in items">
      <h1 x-text="item.title"></h1>
  </template>

Is there anybody that can assist in figuring out how to evaluate the bottom x-text="item.title" expression? I'm looking into this, but my gut tells me that is just passed to the evaluator as-is without any parsing. @calebporzio is this something that we can fix easy enough? Just allowing dot syntax here would be nearly perfect.

Alternatively, we can also add directive(s) for adding arguments to a function. So you could do something like <h1 x-text="getItemTitle" x-argument="item"></h1> - a bit hacky, but does solve some related issues where I have to resort to using data-* attributes instead of function arguments. Perhaps having a more coherent "properties" concept (similar to vue) would help here.

[MichaelMackus]

I just found a workaround for anybody having this same issue. Hopefully the CSP plugin will be updated to fix these sorts of issues in the future, but here's the workaround:

  <template x-for="item in items">
      <h1 x-text="getItemTitle"></h1>
  </template>

Then in getItemTitle I just access the item object via this.$data.item.title.

[MichaelMackus]

Hmm ok. Thanks for the input on that, I understand it doesn't do any specific parsing of the expressions but for example I noticed the "item in items" syntax works because of some regex parsing in the evaluator. I'm wondering if we can do something similar with the CSP plugin (at least for minor stuff like dot notation). I also mentioned above some "properties" concept similar to how vue handles it would help a lot with things like this and function arguments.

I wish there was some more focus on CSP since that is pretty important IMO, but at least it is supported for now. I'd be willing to help but it doesn't appear that the devs are accepting PRs for it at this point?

[SimoTod]

You can definitely support it. Just split the string by . and create a for where you access the nested property. However, that will fix this specific use case but there will be others that won't be supported if you expect to use the same syntax as the standard build.

I don't know about the pr, I think the plugin is there as a guide for those who really need it but it's incomplete and it's not a priority.

Since you need to compile it locally anyway, you can just apply the patch to your fork and eventually replace it if the official plugin gets released.

[SimoTod]

The changes will be before this line: https://github.com/alpinejs/alpine/blob/main/packages/csp/src/index.js#L30

I can send you an example tomorrow if you need it.

[MichaelMackus]

Thanks @SimoTod ! I appreciate that, but was hoping to contribute something upstream. Understood about the fact it is more of a guideline... for now I think I'll wait and see how the CSP stuff develops. I'd definitely be willing to contribute more if it becomes more of a priority.

Anyway, for this particular case its no big deal since I can just define my own getters. If I eventually fork it for my own needs perhaps we can figure out a separate maintainer for the CSP plugin (I'd be willing to take that on in the time being at least if there's any interest).

[motdotenv]

came here to say thanks @MichaelMackus. this worked a charm.

[delete-all]

Hey @MichaelMackus, thanks for sharing your solution! Did you have any further progress on this issue since your last post? I am having the same issue...

[delete-all]

Now I managed to get this working. Thanks @MichaelMackus

I jut had to remove "$data" and define the getItemTerm function in my Alpine object:
getItemTerm() {
return this.item.term;
},

[sjoe77]

Thanks @MichaelMackus - This worked for me. Is this way of accessing the data context (this.$data.item.title) something that is stable/officially supported?

[ekwoka]

$data is stable.

[sjoe77]

Excellent! Thanks.

…

On Sun, Nov 3, 2024 at 8:29 AM Eric Kwoka ***@***.***> wrote: $data is stable. — Reply to this email directly, view it on GitHub <#2724 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALFTAJEDVFQID37SEQZLN7LZ6YQNDAVCNFSM6AAAAABQ4LNEBSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJTGQZTMNY> . You are receiving this because you commented.Message ID: ***@***.***>