Skip to content
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

Open
sigmundch opened this issue Dec 7, 2023 · 6 comments
Open

Exposing hasX properties: automatic or helper? #118

sigmundch opened this issue Dec 7, 2023 · 6 comments

Comments

@sigmundch
Copy link
Member

We have hasProperty and recently has 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

@ditman
Copy link
Member

ditman commented Dec 7, 2023

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).

@srujzs
Copy link
Contributor

srujzs commented Dec 7, 2023

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.

@ditman
Copy link
Member

ditman commented Dec 7, 2023

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)

@srujzs
Copy link
Contributor

srujzs commented Dec 7, 2023

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!

@kevmoo
Copy link
Member

kevmoo commented Dec 7, 2023 via email

@srujzs
Copy link
Contributor

srujzs commented Dec 7, 2023

Yeah that's a slight modification to the original suggestion of having hasX. I just think it'll still be a lot of duplication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants