Open sigmundch opened 8 months ago
I think the has
/hasProperty
should be enough. When I wrote my own helper was because I was "translating" the old way of doing it to the new.
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 has
is probably the way to go.
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.
Can you detail what about the package makes it hard to find?
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: "serviceWorker" in window
and things like that.
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 https://github.com/dart-lang/web/issues/118#issuecomment-1846218128, 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 hasX
. I just think it'll still be a lot of duplication.
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