Implement in expression

[brncsk]

This PR implements an in expression to check if an array contains a value. Fixes #4698.

E.g.:

["in", 3, ["literal", [1, 2, 3]]]

Launch Checklist

• briefly describe the changes in this PR
• write tests for all new functionality
• document any changes to public APIs
• post benchmark scores
• manually test the debug page
• tagged @mapbox/studio and/or @mapbox/maps-design if this PR includes style spec changes

[brncsk]

Anything I can do to get this merged?

[jfirebaugh]

Hey @brncsk, thanks for the contribution! This looks good to me. Some considerations:

• We were previously calling this operator "contains", but I like "in" too, for its brevity and continuity with the prior filter syntax. Also the argument order makes slightly more sense.
• We removed "contains" because we weren't certain about the typing rules, but we were leaning toward typing it as (value, array<value>) => boolean as you've done here. I still think that's the right call.
• However, since "in" is using the same equality semantics as "==" (i.e. JS ===), it should have the same constraints, so it can't be used with types where === doesn't make sense. Specifically the type of needle should be limited to these types. If the static type is not one of those five, it should be a parse error. Or, if the static type is value and the runtime type isn't one of the other four, it should be an evaluation error.
• Could you expand the tests here to cover more of the cases that were removed in Remove "contains" expression support #5412?
• Would you be able and willing to port this change to mapbox-gl-native as well?

Thanks again for the contribution and sorry it took us a while to get to!

[jfirebaugh]

I can imagine us adding a collator argument to "in". We introduced a bug when we we did that for string comparison operators. Let's future-proof this line by checking filter.length >= 3.

[jfirebaugh]

/cc @mapbox/studio and/or @mapbox/maps-design

[nickidlugash]

@jfirebaugh thanks for looping Carto in. I don't have experience styling with data fields containing arrays, so I don't feel like I have much insight here. I read through the issue trail though, and this seems okay.

[jonseppanen]

Is there anything holding up the merging of this? We have some pretty essential stuff relying on this and have been holding off using mapbox until this feature comes through.

[mollymerp]

@brncsk are you planning on continuing the implementation of this feature and taking John's suggestions above?

[andrey-hohlov]

Any updates?

[brncsk]

I'll probably have the time to do it by the end of the month, until then you might wanna look at https://www.mapbox.com/mapbox-gl-js/style-spec/#expressions-match and see if the "array of literal values" case fulfils your needs.

[stdmn]

@brncsk @jfirebaugh Any news on the implementation of this? This along with #7796 seem to be joined at the hip and are extremely valuable.

[mayteio]

Bump - any reason this hasn't been merged yet?

[mourner]

@mayteio yes — the PR feedback hasn't yet been addressed, and our team didn't have the bandwidth to take over the implementation yet. Any style spec changes affect the whole ecosystem (including native SDKs) and are almost permanent, so need great care and consideration of smallest details before potentially merging.

[NameFILIP]

It would be good to have this implemented. My workaround is the following:

[
  'match',
  ['get', 'id'],
  [
    'fake-value-to-make-the-match-validator-happy',
    ...arrayOfSelectedIds,
  ],
  2,
  1,
],

[ryanhamley]

I'm closing this as stale in favor of #8876. Thanks for getting it started @brncsk; I've added you as a co-author on the new PR.