-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align match behavior with case/== #6684
Conversation
It doesn't look like our documentation was specific enough to cover this nuance, so it technically doesn't require an update. Does anyone think we should make it more specific?
|
Yes, I think we should make the documentation more specific, assuming we don’t intend to revisit this decision anytime soon. Without additional documentation, I think some developers may still be initially surprised that I agree with this change, but the previous error message at least gave the developer a clue as to where the problem might lay. Without either the error message or documentation, the developer is left to guess that |
Agreed re: clarifying the docs. Draft:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
return new Match((inputType: any), (outputType: any), input, cases, outputs, otherwise); | ||
} | ||
|
||
evaluate(ctx: EvaluationContext) { | ||
const input = (this.input.evaluate(ctx): any); | ||
return (this.outputs[this.cases[input]] || this.otherwise).evaluate(ctx); | ||
const output = (typeOf(input) === this.inputType && this.outputs[this.cases[input]]) || this.otherwise; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too bad we can't just use Map
Makes `["match", ["get", k], label, match, otherwise]` equivalent to `["case", ["==", ["get", k], label], match, otherwise]`. This changes the behavior of match expressions where the runtime type of the input does not match the type of the labels: previously such expressions produced a runtime type error and then fell back to the property default value; now they produce the fallback value from the match expression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM too!
We can now take advantage of the relaxed typing for == and match, which allows full-fidelity conversion of categorical functions. Previously, we were relying on the default value being substituted at evaluation time if the input was not of the expected type. Now, case/match can handle that.
@anandthakker Want to review the conversion addition here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes
["match", ["get", k], label, match, otherwise]
equivalent to["case", ["==", ["get", k], label], match, otherwise]
. This changes the behavior of match expressions where the runtime type of the input does not match the type of the labels: previously such expressions produced a runtime type error and then fell back to the property default value; now they produce the fallback value from the match expression.Fixes #6680.
cc @mapbox/studio @mapbox/maps-design @mapbox/ios @mapbox/android
Launch Checklist
@mapbox/studio
and/or@mapbox/maps-design
if this PR includes style spec changes