-
Notifications
You must be signed in to change notification settings - Fork 28.8k
[web] Only create one <style> for SelectableRegion #161682
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM, I left some comments but I don't think they're blocking.
// Create css style for _kClassName. | ||
final web.HTMLStyleElement styleElement = | ||
web.document.createElement('style') as web.HTMLStyleElement; | ||
web.document.head!.append(styleElement as JSAny); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to give a uniqueID to this styleElement
, so it can be re-accessed without caching it in the element (it's supposedly a stateless widget?)
I'm not sure what the "guarantees" are that the stateless widget won't be re-created at any time (causing the code to attempt to re-register the view?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The registration methods and variables are all static, so there's only a single registration call across all widgets.
sheet.insertRule(_kClassRule, 0); | ||
sheet.insertRule(_kClassSelectionRule, 1); | ||
|
||
_registerViewFactory(_viewType, (int viewId, {Object? params}) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be reimplemented with the fromTag
constructor, instead of having to register the view? That way we wouldn't need to keep a flag for the factory being registered or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it could, and I would like that of course :)
But I'll keep this PR focused on fixing the issue at hand. Refactors can come in a follow up PR.
if (view == null) { | ||
throw PlatformException( | ||
code: 'error', | ||
message: 'Trying to dispose a platform view with unknown id: $id', | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe replace these comparisons with null by asserts? The code of this helper would be simplified quite a bit!
assert(view != null, 'Trying to dispose a platform view with unknowin id: $id');
?
(Or are we expecting a PlatformException
elsewhere in these tests?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we are "expecting" a PlatformException
in tests, but the real platform channel throws a PlatformException
when an error occurs. So this "fake" registry should throw the same type of exception as the real registry.
We used to create and insert a new
<style>
element for eachSelectableRegion
widget. That's unnecessary. All we need is one<style>
element that contains the style sheets that we want to apply.Most of this PR is re-working the tests to be able to check that the issue is actually fixed.
Fixes #161519