| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
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. |
Sorry, something went wrong.
|
There are currently about 60 files that use querySelector. Adding a safe version for each element type could result in significant duplication. |
Sorry, something went wrong.
|
Well, using include creates that same duplication in the compiler anyway (include is a copy paste in the compiler). It's not in the ReScript source files, but it'll be the same duplication in the output. And the output will probably be worse and harder to follow. 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. |
Sorry, something went wrong.
|
I don't think I mind duplication, but in this case, there is practical side.
Could you give an example maybe? |
Sorry, something went wrong.
|
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? |
Sorry, something went wrong.
|
Yeah, so you have document.querySelector which returns an element. The way it is currently set up is that HTMLButtonElement for example, currently has a @send querySelector taking an htmlButtonElement as first argument. This is to avoid that the user would need to "downcast" the htmlButtonElement to an element before they can use querySelector. |
Sorry, something went wrong.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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.