Return the index of stringToSearch inside stringToScan, where stringToScan is a list of unique strings (e.g. RowId) separated by a char (e.g. a semicolon not findable inside every single string).

stringToScan: a;b;c;d
separatorChar: ;
stringToSearch: c

Return value: 2

The first string in the list return 0.
If a string is not found return -1.


Practical use
I use this function to explode all the rows of an order that are contained in a single cell (a variation of the Trebuchet method).

To fork: stringIndex - Replit


Can’t wait to see more from you and others on this category! Thanks for sharing.


Omg! I need to try this. Nowadays I have a custom action setting 5 columns at once to get something like this… damn

Thanks for sharing :pray:t3:

1 Like

Thanks to you!
You are the one who inspired me!

maybe i’m tired and drunk… but if string to search is “c”… then return value should be 1 ??? not 2.

a=0, b=1, c=2, d=3

oh… position not count… with count from zero… ok… sorry… i do need sleep… lol

1 Like

In the function the string is split into an array, then the indexOf function returns the index of the element if it is found.
The first element has an index of 0, the others progressively follow.

Somewhere in this forum I read that nocoding was just an excuse to make us all, sooner or later, Coders.
Nothing more true was said!


you gonna get suck in and become a coder… unless you just wanna have an App to show some pictures to your family :wink:

I’m afraid that Glide might become too advance for new customers to come… I remember, like 15 years ago there was a cool game “Kingdoms of Camelot” on facebook … it was really a fun to play… until we showed up and start making scripts on FireFox to automatically play that game … and the game just died… creators start coming up with new gadgets to buy… new rules to play just to compensate these who did not know how to script… Game become way too advanced … and just ends after few years of great prosperity

I think and hope not because a good part of the scenarios are feasible without writing a line of code, so if I’m not a coder I can make them; new Glide customers may arrive. On the other hand, if I am a coder, I will always prefer to have a nocode tool that simplifies my work and makes it faster; consequently I will be more competitive and new Glide customers will be able to arrive in this target too.
In my opinion, Code columns cannot be the determining factor, it only has the task of enriching the range of tools as the rich text component already does.
I wish this Glide platform a long life!


I am neither a new or advanced user. I do see some risk if Glide is perceived as complex by new users.

We all embrace a useful tool that is both simple and powerful. However, when a powerful tool becomes hard to use then we have to personally decide if the extra load on our brains (complexity) is worth the added feature(s).

Is there an easy way to keep new users focused on the simple and powerful features while not scaring away the new users with what power-users are doing?

Personally I’m not happy with glide going in this direction. I would rather have them built those abilities within the system than send us to learn coding (that’s why I started using glide to begin with - no code required).

I think a good example of the perception will be bubble which is considered a no code tool for coders as the learning curve is heavy and code was always part.

I agree that turning to this approach will drive glide farther away from the drain of millions glide developers

I love advanced Glide functions, but i think it should come with warnings, and special colors, so new users don’t get stack on them or even ruin their Apps, i always advise them to open testing app first and play with it until they have full understanding…
Like yes colum have worning… that is a good approach… also some link for tutorials to click inside editor… maybe

  • One big goal with the Code column for us is to find out what the most important missing features in Glide’s data story are, so we can, in time, build them as first-class features in Glide.
  • The reason we have made the Code column easily sharable is precisely so that it’s possible to use it without writing code - by using Code columns built by others.
  • There will always be things that are either impossible or very hard to express in Glide’s data model. It was always part of the plan to eventually allow extending Glide with code. We’re only now starting to explore this, very carefully.
  • We are well aware that Glide has become quite complex and is at risk of becoming too hard for novices. We’re working on not letting this happen.

I’m so happy to read everything you just wrote :blush:.

This is one the things a live about glide. You guys, the team. You listen and take into consideration.

Thank you


As a non coder, on the one hand, I think that too much Yes-code may confuse Glide positioning, implying a risk with regard to the “1 billion” target; in particular if:

  • some basic features (from the Glide no-coder point of view) are missing, ex. native multiselect vs Trebucheting
  • and if the forum has too many threads on yes-code; it may appear as a detail, but, for new users, this may ultimately give the feeling of a no-code platform… for coders.

Nevertheless, I also think that combining no-code with low-code can be powerful for Glide and its advanced user, but also for the non-coders: I don’t know how it could materialize, but we may imagine that the yes-code column integrate natively a validated-templates-library of coded features that a non-coder has just to click to activate
(nb: all in Glide, because, typically, while I’d like to test some of the first yes-code functions, using an external tool is another step).

I was thinking, that Glide should create another Yes Colum, this time based on google sheets formulas, this will be much more understandable for users.

Personally, I am discovering the world of No-Code and I am a little surprised by the reaction of some to Yes-Code.

I thought having the ability to create special or personal functions would be welcome and increase the power of Glide.

If the YC is a problem then you should remove the RichText, because CSS is the same thing, it is also code, except a lot of advanced users use CSS. And I don’t see a difference between a CSS and a YC script. It may still be too early to judge the YC, it may be necessary to give it time to make progress as some users do for CSS.
It’s super easy these days to find snippets of code and learn new things.

I’ve posted a few YCs that suit my personal needs and once or twice user requests. 100% of the codes are super simple and boil down to a few lines of code.
I like the idea that the Glide team can experience a certain function and that’s why I participate in YC as well.

I’ve also made the effort to provide the source or an image of the code each time so that everyone can learn or find out how it works. This may be a mistake, because obviously in the no-code world you like using external services but not knowing what’s inside!

But the greatest strength of Glide is its community, there are always friends to help others and share their tips and tricks just like CSS. And I’m glad to see some comments from less experienced users saying that they’ve learned something.

I think it’s a good thing that Glide leaves an open door to YC and CSS, free for everyone to use or not.