@wxm try adding a condition to the page loaded event when ‘Find index a is visible’. What’s likely happening is that the action is running before the element has been drawn on the page.
1 Like
Great idea! I added the condition:
Unfortunately, the situation is the same. Stepping through with the debugger, there’s a list of blocks found via the search in the FindIndex A (sorted by value) and the block of the page is among them. It looks like it should work.
But after clicking next, the inspector closes. Reopening it and looking for the FindIndex A element, there’s an error and it’s not visible.
I tried one more thing, which was changing the FindIndex A to search for the (list of blocks, sorted by value)'s unique IDs and comparing that with the unique ID of the current page block. Here it’s apparent from the inspector that the current page block IS in the list. For some reason, it still leads to an error and the element being invisible.
So the ‘error’ state is simply a custom state on the plugin. The state will exist whether or not an error has occurred. If it’s empty then no error was returned from the plugin code. If it’s not empty an error occurred in the plugin code.
This screenshot looks like it ran properly as the index # returned was 1 and there is no error.
According to the list of things and the thing to find (from the screenshot with unique ids) the correct index should be 1.
This screenshot looks like it ran properly as the index # returned was 1 and there is no error.
As I said above, that element has an “oops something went wrong” error when I run it normally. It’s only when I step through manually with the debugger, that an index is found (and it still doesn’t display on screen, only in the inspector).
As you suggested, I suspect that there’s a timing issue, but adding a “when FindIndex A is visible” criteria to the workflow didn’t fix it.
Is there a way to do the equivalent of a DOMContentLoaded event callback and have that trigger the index calculation and subsequent update of the text element that displays it?
There are many other ways to do indexOf and maybe you should try one of those. (List Shifter, for example, has an indexof action that triggers an event when the find is complete… it also works on any type of list). Or just write that yourself.
I’ve put a crazy amount of time into this one issue already. Just giving up and not understanding how or why it’s breaking isn’t very appealing.
That said, if you have a specific recommendation and it’s a bit better documented, I’ll try it right away.
The problem with Eli’s plugin is that it will not work properly with long lists. (He should be loading the list on update, because Bubble may repeatedly attempt to load such lists until the page/data is fully loaded.) So, if you have a long list, his plugin will fail because he only tries to load the list when the action runs… and he doesn’t do this before trying .indexOf() on the array, he does it in a “try” clause.
@eli, like the docs say, load your data (do this in update) and THEN attempt your action.
Which is to say: Your update function should retrieve both of the fields provided in the main interface (the list and that scalar). Save them to instance.data.something (e.g., instance.data.list and instance.data.scalar)… and then your action should simply return instance.data.list.indexOf(instance.data.scalar).
1 Like
Thanks for your recommendations @keith. There is no reason the data needs to be loaded in the update function though. The docs makes no assertion to that point and actually note that Bubble will continue reloading the data in an action the same way it does in the update function on the element.
Now this 'Try’
‘Catches’ the crux of the issue as I have not been accounting for the ‘not ready’ special error from Bubble resulting in it being caught and
- Throwing an error that isn’t really an error
- Keeping Bubble from doing its background fetch magic.
@wxm I’ve moved the data loading outside the try… catch and pushed an update to the plugin. Very interested to see if this solves your issue.
There is probably a use case for the element itself to find an index anytime the value changes without running the action but that’s for another day.
In case anyone is wondering how I solved this, I used the Toolbox Plugin’s JavaScript to Bubble element and a Run JavaScript workflow. In that workflow, I saved the value of a search for IDs of blocks in the way I wanted them ordered in a variable and then used .indexOf(desiredId) to get its position.
tldr; I just used the Toolbox Plugin as an escape hatch to work around the problem
1 Like
Hi @Eli can you add Grouping as a data type?
I have a Grouping with my RG, and I want to find an index of a specific grouping.
Hey @george8, how would you see identifying the group? There’s no id associated with Bubble’s grouping so I’m not sure how this would work.
Ah good point!
I found a workaround, no biggie.
1 Like
Nice. How will this be any different than the index syntax found natively in bubbles repeating groups, and how is it better?
Hi, anyone else having trouble working with dates? While I am trying to find index of a date list, I am always getting “0” as the index. Could be a mistake in my end, but I am starting to wonder if this is error related to this particular datatype. @eli
Hi @roni.saroniemi, try formatting the dates as Simplified extended ISO and set the datatype to text.
Not currently. But you could run an each item: lowercase operator on the list to force everything into the same case.
Hi !
I don’t understand how the number display. It’s not working for me.
There is an other thing to do in addition to :
Thank you very much !
This is a fantastic tool concept, but unfortunately I’ve just added it and I’m not seeing any options?
Also tried JS Expression element and that’s not working either: Trouble finding index of a dropdown selection