Repository navigation
Web-only pieces of dart:ui cause analysis errors #52899
Description
Activity
There is a
3, which is to only allow access to these members through JS-interop:engine setup
html.window['debugEmulateFlutterTesterEnvironment']= allowInterop(...)framework setup
html.window['debugEmulateFlutterTesterEnvironment'](true);- Isn't great, since many of the APIs seem transitional and dart:ui is very difficult to change.
- is a worse version of 1. IMO
@jonahwilliams ' solution actually looks pretty good. Let's go with that.
- added this to the milestone
on Mar 26, 2020 SGTM! Thanks @yjbanov and @jonahwilliams . Are clients using these functions? Does this require a breaking change announcement?
No one should be using this functionality besides the SDK and possibly some google3 generated code. If they are doing so with an
ignore: missingyou have my permission to break them.At any rate, to shakes these dependencies out I would recommend a 3 stage process:
-
Add the JS-interop based APIs with a fallback to the existing functionality if they are not set.
-
Update flutter/flutter and google3 code to use the new APIs after the engine rolls.
-
Remove the old apis from flutter/engine
-
22 remaining items
The failing analyzer is also giving me the issue that pub.dev doesn't indicate the CachedNetworkImage as migrated to null safety. So every week I get somebody asking for a null safety migration. I am really considering dropping web support for CachedNetworkImage because of this issue.
@renefloor Please, don't consider it. :-))
Where is the problem actually? Only for you in development? Because I use 3.0.0 in my app, both on mobile and web, without problems. Actually, I still use an extra parameter marked FIXME and I don't know whether it's still needed but this is probably unrelated. Apart from that, I can't see any problems.
provider = CachedNetworkImageProvider( info.thumbnail!, imageRenderMethodForWeb: ImageRenderMethodForWeb.HttpGet, //FIXME remove imageRenderMethodForWeb );@deakjahn don't be afraid, I'll try some other alternatives first. I don't really have any issues with it, but the fact that pub.dev marks the package as unidentified gives me more and more questions. Some think the package is not maintained, some think it is not null safe (I'm not sure if it breaks sound null safety actually).
But let's not discuss CachedNetworkImage specifically here, this topic is about the fact that the use of very valid Flutter API's cause analysis errors and break the pub.dev listing.
I'm willing to help with solving this issue, but I don't have the feeling that there is an agreement in the direction of the solution.
OK, I'm starting to see the whole picture. Just to the general side of the question then. I think you're not yet a federated plugin, are you? Because if you're not, I have a strong suspicion that this is part of the problem (if not the problem itself). I have a few federated ones myself, using very web-specific parts in the web plugin and I don't remember any similar issues. (Actually, federated plugins are so much a solution to such issues that I even have local ones. In that very app I have a local federated plugin inside the app, to clearly separate internal support for different platforms and it works flawlessly).
@deakjahn that's correct. That is something I'm looking at at the moment (at least putting the web version in a separate package). Federated is made for plugins that have platform specific code (for example kotlin for Android, swift for iOS or dart/js for web), but in this case it is slightly different as all code is Flutter code. I should just be able to do a platform dependent import like this: https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/painting/image_provider.dart#L14-L15.
Federation makes it possible for third parties to write their own platform implementation for not supported platforms, but written code (in this case dart code) should not throw analyzer issues. When I separate the plugin in a new package the cached_network_image will be fine in pub.dev, but the cached_network_image_web will have the same analyzer error.
Yes, federated does make it possible for others to co-operate but you can still write all subplugins yourself. :-) What I would say it does in this situation is to provide drop-in support for more than one plugin. Simply that on the web, you actually get a different plugin than on mobile, while you don't have to modify your references in the pubspec where you call it.
The point is that I do have conditional imports in my app, just like this, without errors. I can't really tell whether this would perfectly apply to you, of course. Still, my usage is somewhat different, I do the full stub approach. If we could follow this in your issue queue, I could point you to some code I have up here. Maybe this is something you already tried and dismissed but maybe not.
Looking into your code, I think this approach might help. I'll, go on pro-actively and open an issue with you. :-)
- added a commit that references this issue
on Aug 29, 2023 This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Sep 12, 2023
There are some memebers in the web-only "version" of dart:ui that are not found in the mobile version of dart:ui:
webOnlyInstantiateImageCodecFromUrlwebOnlySetPluginHandlerdebugEmulateFlutterTesterEnvironmentThese cause the following static analysis errors:
To satisfy CI, these errors are ignored inline, e.g.
flutter/packages/flutter_web_plugins/test/plugin_event_channel_test.dart
Line 16 in 9391e48
The Dart Analyzer will stop allowing issues with severity error to be ignore (see dart-lang/sdk#27218).
To me it seems that, aside from static analysis, this is awkward code that exists in one version of a library but not another. I spoke to @yjbanov at length about this and we thought of a few solutions:
throw UnsupportedError, and don't document them.dart:web_ui.