-
Notifications
You must be signed in to change notification settings - Fork 1.7k
dart:html should be split-up #3108
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
Comments
Removed Type-Defect label. |
Issue #3949 has been merged into this issue. |
Concerns from Issue #3949 which has been merged into this issue: """ It would be great if you group some classes and extract them to separate files. Comment 1 by rbeeger, Yesterday (25 hours ago) But there is one more reason for splitting up this file. Separating it into several files based on the topic would help exploration of this part of dart's SDK. So if I were interested in WebGL I would look into webgl.dart. For SVG I would look into svg.dart. I don't think we will be able to achieve much tool speedup by partitioning the library. Consider this is valid code fragment: createAString() could contain almost anything, including an SVGRectElement, e.g. The compiler needs to know that .height could be returning an SVGAnimatedLength (SVGRectElement.height) as well as a number (ImageElement.height) or String (TableCellElement.height). In order for this to happen, all the SVG* names need to be available to the compiler, otherwise the compiler could make the incorrect inference that only strings and numbers could be returned and generate 'optimized' code that does not work. Since we don't want the editor to be inconsistent with the library, it consumes the same version of the library as the compiler, so would still need to parse all 500+ interfaces. The in-editor experience would still be better since the editor can choose suggestions on the basis of names reachable from the imports rather than available on all instances reaching that point in the code. |
This comment was originally written by [email protected] In my case it take a few seconds to find all implementations for each class in that file. I will fix it but the main reason for me as a developer is impossibility to work with such file even in text editor. For example I can't look at both WebGL and geometry at the same time. Or simple navigation becomes uncomfortable. |
cc @rakudrama. |
Removed this from the M1 milestone. |
SVG, Audio and Indexed DB have all been broken out. I'm hesitant to break CSS apart from HTML as the scenarios seem inseparable. I'd like to treat breaking out anything else as separate issues. Note that breaking out WebGL is under consideration, but right now none of the others are. Note that another one which we should consider is RTC as well. Added Fixed label. |
This issue was originally filed by @seaneagan
The dart:html library is huge. This leads to some issues:
* makes the documentation extremely difficult to navigate
conflicts with other parts of the library
It should be split up into smaller libraries. The challenge of course
is where to draw the boundaries for the smaller libraries. Here are
some approximate subsets which should probably be their own library:
SVG* (154 names!)
Audio* (21 names)
CSS* (18 names)
IDB* (18 names)
WebGL* (17 names)
Worker (13 names)
Speech* (12 names)
typed arrays (11 names)
see https://developer.mozilla.org/en/JavaScript_typed_arrays
Canvas* (5 names)
geometry
see issue #3107
The text was updated successfully, but these errors were encountered: