Add Proxy and Reflect #1629
Add Proxy and Reflect #1629
Conversation
github-actions
bot
added
the
feature definition
| # baseline: high | ||
| # baseline_low_date: 2017-12-06 | ||
| # baseline_high_date: 2020-06-06 | ||
| # support: | ||
| # chrome: "63" | ||
| # chrome_android: "63" | ||
| # edge: "12" | ||
| # firefox: "34" | ||
| # firefox_android: "34" | ||
| # safari: "10" | ||
| # safari_ios: "10" | ||
| - javascript.builtins.Proxy.revocable | ||
|
|
||
| # baseline: high | ||
| # baseline_low_date: 2020-01-15 | ||
| # baseline_high_date: 2022-07-15 | ||
| # support: | ||
| # chrome: "49" | ||
| # chrome_android: "49" | ||
| # edge: "79" | ||
| # firefox: "49" | ||
| # firefox_android: "49" | ||
| # safari: "10" | ||
| # safari_ios: "10" | ||
| - javascript.builtins.Proxy.handler.getPrototypeOf |
There was a problem hiding this comment.
These last 2 BCD keys are largely responsible for the discrepency with caniuse.com (with the caveat that caniuse.com only knows about Proxy, not Reflect).
The revocable static method seems like it doesn't prevent using the API, and is a nice to have for some use cases, maybe?
Not sure about the handler.getPrototypeOf key. But without it, and without the revocable method, we get chrome 49, edge 12, safari 10, just like on caniuse.com.
Does Proxy have to be used with Reflect? Does the grouping make sense (genuinely asking as I've never used those APIs)?
There was a problem hiding this comment.
"Revocable Proxies" could be a separate feature if we like it to be. I thought it is old news by now so I lumped it together with the other Proxy features but it could be its own thing. No strong feelings here.
I also think Reflect and Proxy could be separate features but I always think about them together and both appeared at the same time roughly. I wrote docs about this ages ago at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Meta_programming
There was a problem hiding this comment.
You're right that this is a few years old and baseline high anyway, no matter how we group it. So maybe it doesn't matter that much, other than making it agree with caniuse.com.
I do remember using Proxies in a project in the past, but not Reflect. If my use case was representative of others, then splitting Proxy and Reflect might make sense. What do you think?
There was a problem hiding this comment.
About the status: this feature doesn't use the caniuse key so we're not as strongly obligated to align with caniuse. I think there's three ways to look at this:
-
Caniuse's feature doesn't represent the developer perspective (e.g., developers think of Proxy and Reflect as closely related or there are use-cases where Reflect without Proxy or Proxy without Reflect can't make sense), so we ignore caniuse's Proxy feature and move on. That's what the diff says to me now.
-
Caniuse's feature is close enough to our feature (e.g., developers have mixed views on this or makes for greater consistency with other things, like docs) but the difference is sufficiently historic or unimportant that it doesn't matter (i.e., we don't care whether this should be a 2020 or 2017 feature). To get this, we'd add theDon't do this. See https://github.com/web-platform-dx/web-features/pull/1629/files#r1731547072.caniusekey and make no other changes. -
Caniuse's feature is close enough to our feature but the headline status difference is meaningful (i.e., this should be a 2017 feature not a 2020 feature). To get this, we'd add the
caniusekey and acompute_from. -
Caniuse's feature is right and we should split out revocable and/or getPrototypeOf.
All of the above are mostly unrelated question of splitting Proxy and Reflect. I have no opinion on this, though I didn't know about Reflect until today.
Honestly, I think any of these options make sense—it's really hard for me to make an opinion without some evidence about developers' expectations. If pressed, I guess I'd say leave them together and go with option 2, leaving the door open to revise if we get negative feedback from consumers.
In any case, I think it'd be nice to have a comment explaining what we did though.
There was a problem hiding this comment.
Googling for proxies, I do find a few resources that talk about both Proxy and Reflect together, but also a lot of other resources that just talk about Proxy.
Google Trends also show magnitude more interest in Proxy than Reflect. I don't know if it's worth anything. But this resonates with my experience, that Proxy is sort of well known, and Reflect far less. Now, does that mean that they are used by developers as 2 separate features, I think so, but am not sure.
Should we bring in a JS implementation subject matter expert to share their perspective on this as well?
@codehag, your perspective on the matter would be awesome. We're trying to think about whether Proxy and Reflect are perceived by web developers as part of a single feature, or not.
There was a problem hiding this comment.
Following up on myself here. I spoke to Alexis today, so I have a clearer answer for the caniuse/no-caniuse key question:
- Superset features are OK as long as the headline status would make sense for the caniuse feature page (i.e., it's fine that this feature covers more than the corresponding caniuse feature).
- Alexis wants features with the caniuse field set to be "90% the same" in terms of release information. I've made this more concrete by saying that our headline computed release versions shouldn't differ from caniuse's by more than 1 year (which is close to 10% of the time between now and when Edge 12 was released). (I suspect this is something we can lint for.)
This means that my option 2 is not acceptable, so I struck it out.
See #1631 (comment) for more detail.
There was a problem hiding this comment.
I went with option 3 and added the caniuse reference and used compute_from.
I did not split the feature. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Reflect how it is used with proxies and how the spec has a chapter "Reflection" containing both objects. https://tc39.es/ecma262/multipage/reflection.html#sec-reflection
Probably, I guess, when people talk about JS proxies they mean everything that has to do with and so to me that means the Proxy object and the Reflect namespace. Reflect could be used outside of the context of proxies but I don't think that is a thing usually. You would rather use the Object object or do things directly without the indirection of Reflect.
There was a problem hiding this comment.
Those links convinced me that Proxy and Reflect need to stick together in the same feature file.
| # baseline: high | ||
| # baseline_low_date: 2017-12-06 | ||
| # baseline_high_date: 2020-06-06 | ||
| # support: | ||
| # chrome: "63" | ||
| # chrome_android: "63" | ||
| # edge: "12" | ||
| # firefox: "34" | ||
| # firefox_android: "34" | ||
| # safari: "10" | ||
| # safari_ios: "10" | ||
| - javascript.builtins.Proxy.revocable | ||
|
|
||
| # baseline: high | ||
| # baseline_low_date: 2020-01-15 | ||
| # baseline_high_date: 2022-07-15 | ||
| # support: | ||
| # chrome: "49" | ||
| # chrome_android: "49" | ||
| # edge: "79" | ||
| # firefox: "49" | ||
| # firefox_android: "49" | ||
| # safari: "10" | ||
| # safari_ios: "10" | ||
| - javascript.builtins.Proxy.handler.getPrototypeOf |
There was a problem hiding this comment.
About the status: this feature doesn't use the caniuse key so we're not as strongly obligated to align with caniuse. I think there's three ways to look at this:
-
Caniuse's feature doesn't represent the developer perspective (e.g., developers think of Proxy and Reflect as closely related or there are use-cases where Reflect without Proxy or Proxy without Reflect can't make sense), so we ignore caniuse's Proxy feature and move on. That's what the diff says to me now.
-
Caniuse's feature is close enough to our feature (e.g., developers have mixed views on this or makes for greater consistency with other things, like docs) but the difference is sufficiently historic or unimportant that it doesn't matter (i.e., we don't care whether this should be a 2020 or 2017 feature). To get this, we'd add theDon't do this. See https://github.com/web-platform-dx/web-features/pull/1629/files#r1731547072.caniusekey and make no other changes. -
Caniuse's feature is close enough to our feature but the headline status difference is meaningful (i.e., this should be a 2017 feature not a 2020 feature). To get this, we'd add the
caniusekey and acompute_from. -
Caniuse's feature is right and we should split out revocable and/or getPrototypeOf.
All of the above are mostly unrelated question of splitting Proxy and Reflect. I have no opinion on this, though I didn't know about Reflect until today.
Honestly, I think any of these options make sense—it's really hard for me to make an opinion without some evidence about developers' expectations. If pressed, I guess I'd say leave them together and go with option 2, leaving the door open to revise if we get negative feedback from consumers.
In any case, I think it'd be nice to have a comment explaining what we did though.
Co-authored-by: Daniel D. Beck <daniel@ddbeck.com>
3 participants
No description provided.