Implement "in" expression

[ryanhamley]

Launch Checklist

• briefly describe the changes in this PR
  • implement an in expression operator to check for a value in an array
  • fixes An expression to check if an array contains a given value #4698
  • fixes Add expression operator testing whether a string contains a substring #4113
  • supersedes a stale PR Implement in expression #7197
  • h/t to @brncsk
• write tests for all new functionality
• document any changes to public APIs
• manually test the debug page
• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port
  • will need to be ported to native

TODO:

• Limit types which the value can take
• Add more tests
  See Implement in expression #7197 (review)

[mourner]

Should we overload the operator for strings to also cover #4113? Or would we have a different name for such an operator? It would be essentially the same operation (haystack.indexOf(needle) >= 0) but with different types.

[ryanhamley]

Hmm that's a great question. I hadn't considered the possibility of expanding this to work on strings as well, but I definitely think that's doable. I'm not sure what would be a better operator name for finding a substring. in makes sense for both arrays and strings.

@chloekraw do you have thoughts on this? I'm going to try to make it cover #4113 unless there's strong objections to it.

[chloekraw]

@ryanhamley I think extending this to cover strings makes sense!

[vakila]

One question below but at first glance LGTM @ryanhamley! I'm just trying to try it out in a debug page style I tried out the expression just to get a feel for it and 💯 this is awesome! 🙌

[vakila]

I just... I just love this needle haystack naming so much ❤️ 😁

[jliebrand]

Thanks for this! Silly question - but how can i see here in github which release this will end up in (once it's in a release obviously ;-))

[ryanhamley]

@jliebrand We don't have a release schedule on Github but we do monthly releases which include anything that makes it into master since the last release. This feature will be included in v1.6.0 which will come out in the next few weeks (the schedule is somewhat in flux because of US holidays).

[matthieugouel]

Hello,
I tested this feature a little bit from the master branch and I think It might be a problem with imbricated filters like that :

["all", ["==", "something", something_variable], ["in", else_variable, ["get", "else"]]]

When I use the ["get", "else"] notation in a standalone filter it works well but when I use in in an imbricated filter I get the error :

Error: layers.mylayer.filter[2][1][1][2]: string, number, or boolean expected, array found

P.S : My use case is more complicated than that so the error could be slightly different for the specific example above.

[ryanhamley]

@matthieugouel Can you create a standalone example of the issue you're seeing as a JSFiddle and open a new issue with it?

I tried this expression and it worked fine

"text-size": ["*", ["to-number", ["all", ["has", "title"], ["in", ["get", "needle"], ["get", "haystack"]]]], 50]

[stdmn]

@ryanhamley Quick question on this: is it possible for "needle" to be an array of values or does it need to be a single value? I'm specifically thinking of using this for a string "in" expression.

[ryanhamley]

@stdmn needle has to be a single value, specifically a boolean, string or number. It's checked in the isComparableRuntimeValue function. This constraint is because the operator uses Array.prototype.indexOf so

const myComplexNeedle = ['a', 'b'];
const myHaystack = [1, 2, true, ['a', 'b']];
myHaystack.indexOf(myComplexNeedle) // -1

Do you have a pseudocode example in mind of what you'd like to do with a more complex needle argument?

[stdmn]

Because I'm using Tippecanoe, I'm limited to strings so I am looking to do something like this:

['in', ['~a~', '~b~'], [get, attribute]] where attribute has a value like '~a~b~c~d~e~f~g~',

where currently to do this I have to do:
['all', ['in', '~a~', [get, string]], ['in', '~b~', [get, string]]]

It works. It's just verbose, especially for more complex expressions.

[ryanhamley]

@stdmn I think that approach could complicate the expression and make it somewhat unclear. ['in', ['a', 'b'], [get, attribute]] could be equivalent to an all statement or it could be something like a coalesce or any statement and it's not obvious what most users would expect. I'm not sure it would be worth it to overload the operator in this potentially confusing way when there's a straightforward way to accomplish the goal.

Would adding the to-array and/or to-object expressions help your use case instead?

[stdmn]

Would adding the to-array and/or to-object expressions help your use case instead?

Yes. Definitely. These are all workarounds for array management

[fc]

@ryanhamley to-array, to-object as well as this new in operator would have been profoundly helpful for me and my team many months ago. We created the most godawful hack to achieve what we wanted to do which affected both the expressions needed and the properties we put on the geojson/tilesets that was uploaded to the mapbox servers.

[awulkan]

Just logging this here for future reference. I had the same error as @matthieugouel.
Turns out that our custom built version of Mapbox had not been built correctly, and we were still running an older version which didn't have this new expression.

Hope it helps someone.