-
Notifications
You must be signed in to change notification settings - Fork 2
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
Proof of concept querySelector helpers #13
base: main
Are you sure you want to change the base?
Conversation
My 5c is that we should avoid reusing that trick. In my view it just makes the code more complicated and hard to follow for little gain. |
There are currently about 60 files that use |
Well, using What about just using functions? Some internal function that takes a classifier or similar for each use case. Then we can just partially apply that same function in all relevant places. If we worry about duplication. |
I don't think I mind duplication, but in this case, there is practical side.
Could you give an example maybe? |
Just so I understand correctly - you mean each of these 60 files get 60 variations of querySelector? So we have 3600 bindings to queryselector essentially? |
Yeah, so you have The way it is currently set up is that |
Somewhat related to #5
I'd like to experiment a bit with the same trick that was used in the original webapi bindings:
Some duplication in the methods, which currently exists, can be avoided by this.