Is that possible?
I’m trying to have a repeatable group show all related items after a person selects a value in a drop down. The issue is that I have to traverse a few tables to get the correct relationship between the drop down value and the list items. I’ve gathered most of the data required, but now I’ve made it to a data type that is really a list and not sure if I can store a list in the Value field on a custom state.
Here’s an example of the list where the term_taxonomy_id 13 has many object_ids
Here’s my workflow so far.
Yes, you can, but our list operations there are a bit limited. So you can put a list in the state, but adding removing items isn’t currently possible.
[this is not related to the post but more so the follow-up]
@emmanuel is adding/removing items from a list-state in the features pipeline?
My workaround for adding is to use “state’s list:plus item(new item),” which seems quick + easy enough, but my workaround for removing (using list:filtered // unique ID <> item_to_be_removed’s unique ID) is running into performance issues (if I quickly add/remove a couple times the website crashes), presumably because “:filtered” is very operationally intensive?
It’s on our list, but not super early to be honest, as it’s not a very easy fix.
Appreciate it isn’t simple … But the whole “temporary list” pattern is pretty common .
You could do something like this as a workaround to add things
yeah, that’s what I’m using now – but removing is not so simple (see what I wrote above with “:filtered”) and crashes the website if done several times. Anyway, I understand it’s not a simple fix, but def. agree with @NigelG that this is common. Basically anytime we need to implement multi-select, I’m using this. Oh well, looking forward to when it does get implemented!
George confirmed to me 9 days ago that there was an issue with this that caused the website crash if you clicked multiple times.
The “list:filtered // unique ID <> item_to_be_removed’s unique ID” method of removal isn’t ideal but it works … if you don’t stress it.
I use it a lot.
And I still get this …
When using it too quickly.
@NigelG oh cool, glad someone else has also raised this and good to know that George is already aware of this problem. thanks for letting me know!
with “list:filtered … etc.” yup, same. I have users clicking around a data viz – all it takes is some quick, carefree toggling and then … X__X
And now I have this issue as well:( I am using filter on a displayed list, since I can’t remove one item from the list. Too many times and down goes the site.
Yikes, I’m likely to get this problem when our volumes go up … can you give some indication of how many items in a list and how frequently on a page the filtering is happening when it crashes?
I’d like to try some workarounds, one I can think of is keeping an “ignore” list. This would only suit some applications.
For removing items from a state’s list, I don’t see unique ID as an option… Was this feature removed?
If your “selected” list has items like text that are not database objects, there won’t be a unique_id. So you can use “This text” and compare it to the value to be removed.
Thanks, this worked perfectly.
Is it possible to remove a list of items from a state using filter?
I tried to remove a list of texts from the state, but I get an error. Instead I have to remove each individual item.
Are you trying to clear the list?
I don’t want to completely clear the list. I just want to remove a group of items from it and keep everything else in it.
The state holds a list of texts. I want to remove all texts from the list that are in a repeating group. In my second screenshot, I can remove each text individually with item#. But it would be easier to simply remove all of them.
I can’t seem to remove a smaller list from a big list. I can only remove one item from a list.
Try swapping the terms around on the constraint, [list] doesn’t contain [item being constrained]:
Is everyone still having the issue with the page crash? I am trying to test my site by going toggle tags like crazy, but it seems to hold up fine. Definitely a bit nervous about pushing live, based on what others are saying.
No, that was fixed a long time ago.