-
Notifications
You must be signed in to change notification settings - Fork 27
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
Exposing hasX properties: automatic or helper? #118
Comments
I think the I don't think we need a specifically generated helper for each thing that might come up that people want to feature-test on. In this case, it was that I didn't discover the pattern (and could work around the limitation writing my own override, which was nice!) With the version of package:web I have, it's sometimes hard to find what to use (as with any new API with a huge surface, I guess! Also this). |
Talked offline and +1 that Can you detail what about the package makes it hard to find? Is it just the number of APIs? One of my original intentions with making almost all of the members be 1-1 with their JS name is that you would just type out what it would look like in JS and you would get what you need. |
99% of the APIs are super easy to use, and exactly as you say: just go to MDN and read how they work. What's harder to find/do to me are some of the JS idioms that you might need, for example: I need more practice with package:web (and/or a "rosetta stone" type of document with those idioms translated into their corresponding js-interop idioms :P) |
Ah, yeah, I think there's a bit of "what are the suggested ways to do these common things with interop" we need to address in our docs for JS interop. Agreed that it's annoying to find right now! |
Could we auto-create an enum here? So we can easily auto-complete things?
…On Thu, Dec 7, 2023 at 2:39 PM Srujan Gaddam ***@***.***> wrote:
Ah, yeah, I think there's a bit of "what are the suggested ways to do
these common things with interop" we need to address in our docs for JS
interop. Agreed that it's annoying to find right now!
—
Reply to this email directly, view it on GitHub
<#118 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEFCXC3MTEGZ327P5E52TYIJATNAVCNFSM6AAAAABALNMYRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBWGIYTQMJSHA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Yeah that's a slight modification to the original suggestion of having |
We have
hasProperty
and recentlyhas
to check for whether a feature is available. These are still error prone because they take a string argument.Q: should we autogenerate hasX properties for features that are not always available? Or should we add these as helpers as we discover them?
Example from recent migration:
trustedTypes
(see https://github.com/flutter/packages/pull/5581/files#diff-fef182cc76f54d7074aee070ced4ddd44ad9233ebf438472221dc834f5f342d9)cc @ditman @srujzs
The text was updated successfully, but these errors were encountered: