-
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
Less verbose function -> expression conversion #7337
Conversation
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.
Thanks for taking care of this so quickly – looks like exactly the change we need in Studio.
This looks right to me -- it's basically specifically string/boolean/number that we're allowing without the "literal" wrapper, right? Can we add a legacy expression test that uses @samanpwbb 's function from #7336 ? |
@ChrisLoer there are already legacy tests like this, e.g. this one, it's just that the tests don't test conversion output itself — only the output after creating a style expression object and serializing it, which somehow strips the unnecessary "literal" wrappers. Not sure how to go about this. |
@ChrisLoer tried adding comparison of raw-converted legacy function with serialized one, but there are many expressions which don't roundtrip like this — e.g. |
Ah right, that's happening from the serialize logic built into mapbox-gl-js/src/style-spec/expression/definitions/literal.js Lines 56 to 74 in c612e07
What about something similar to the "converts token strings into expressions" test in |
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.
I went ahead and added a simple test using @samanpwbb's expression to migrate.test.js
, along with another variant that requires the literal
syntax. The coverage in that unit test is pretty small and I think this issue highlights that maybe relying on test-expressions
to cover the migration isn't as robust as we'd hope. Would it make sense to check in an entire style sheet for use by this test in order to get better coverage? At any rate, I think what I added is enough coverage for this change.
Legacy function conversion is covered by the expression test suite, but the serialization code it uses for testing against fixtures hides extraneous `Literal` expressions.
0341713
to
087a661
Compare
Fixes #7336. Note that
typeof obj === 'object'
should be true for all non-primitive values in the spec (including arrays), so we don't need more exhaustive checks.Launch Checklist
write tests for all new functionalitycovered by existing testsdocument any changes to public APIspost benchmark scoresn/a