Properly enable dart:html imports

Use case

Currently you are not "able" to import dart:html in Flutter applications, but it's needed for the web platform (e.g. localStorage).
In my package I import dart:html and it works, but the dart analyzer throws errors. Also pana gives a very low score for my package, which is not nice. Pana then thinks my code has a low quality and gives it an even worse score.

Proposal

The Dart SDK of Flutter should ship dart:html, because it's necessary for the web platform.

@zoechi

To get it to work these lines should also be included in the vm section:
https://github.com/dart-lang/sdk/blob/master/sdk/lib/libraries.yaml#L181
Is that possible or would that break anything?

The other way would be defining flutter projects as vm and dart2js projects. It would also help pana to identify the project type. I don't know how to do that.

@zoechi

@yjbanov

Flutter has two copies of the Dart SDK. One - used by flutter tools - has the dart:html library and the standard Dart web compilers. That allows the flutter tool to build flutter for web apps. That copy lives in //bin/cache/dart-sdk/

The other copy of the Dart SDK is used to analyze user code against. That copy lives in //bin/cache/pkg/sky_engine/lib/. The libraries there are defined in the flutter/engine repo in https://github.com/flutter/engine/blob/master/sky/packages/sky_engine/lib/_embedder.yaml.

I think it would be useful to allow user code to analyze against the dart:html library; @yjbanov, I assume that's something we'd want for flutter for web apps?

@hterkelsen

I think including the web libraries in the analyzer summaries we use is a bit premature, since we have not yet decided the role that it (dart:html) will play in the flutter for web ecosystem.

dart:html is not required to use the underlying platform, though dart:js or package:js is. The ergonomics of this probably depend on whatever the plugin model is. @hterkelsen .

I think we should actually go the other way, and remove dart:html, dart:svg, dart:web_audio,
dart:web_gl, dart:web_sq, and dart:indexed_db from our web SDK. These have numerous issues with code size, completeness, and maintenance. Fixing them would likely require large API redesigns or breaking changes that would not be possible via a migration.

EDIT: it -> (dart:html)

But how can I then use js in my web app? For example svg rendering doesn't work on web and I simple added a web "plugin" which modifies the DOM to replace the widget with the svg.
#37749 https://github.com/jld3103/ginko/tree/master/app/lib/utils/svg

I also have a web "plugin" for firebase messaging: https://github.com/jld3103/ginko/tree/master/app/lib/utils/firebase
And a web "plugin" for storage:
https://github.com/jld3103/ginko/tree/master/app/lib/utils/storage

@jonahwilliams

@jonahwilliams @hterkelsen Are there already plans for web plugins? As you can see I ported some plugins to the web and would really like to help the team with web plugins.

I'm working on adding web support in few plugins (parse and webrtc), and it's huge pain in the arse to work with dart:js without proper autocomplete in IDE

@rostopira

@rostopira YES YES YES

@rostopira

@rostopira @jld3103 have you tried package:js? It is supposed to provide better ergonomics than dart:js.

@devoncarew

For web plugins, we are generating a registrant which is called from the generated entrypoint. This way, no conditional imports are needed. This will be useful for when desktop plugins come and a dart:io import is insufficient to tell which platform you're on.

In the web implementation of a plugin, I had been assuming we would allow dart:html. When I implemented the url_launcher plugin, I just used Window.open. In a meeting with the analyzer folks today, @devoncarew suggested we include dart:html, dart:js and dart:js_util in the Flutter analyzer SDK, but we also ship a lint that warns if users import any of these libraries. They should only be available from Flutter web plugins.

In principle I agree with moving the "Dart for Web" world to a lighter-weight, JS-interop only based model, but I don't think we should force Flutter users into that model when dart:html and the other web libraries make the task of implementing a web plugin much simpler.

For web plugins, we are generating a registrant which is called from the generated entrypoint.

So, there is plugin system already for flutter web? Where can I found more info? Docs/source?

@yjbanov

@yjbanov According to this answer on StackOverflow

package:js provides a simpler Api that comes at the cost of an increase of the js size
So it's better to use dart:js in plugins (like using Objective-C instead of Swift), isn't it?

that could have the dart:html analyzer summary attached to it

We're not really set up to do that for the analyzer - to swap out sdk definitions based on imports.

I think including dart:html in the /bin/cache/pkg/sky_engine/lib/ works - users writing web plugins could then see the imports; users writing apps would see a lint warning a development time to warn them about the import - that it's not the recommended path for interop - and people also targeting flutter mobile would get immediate feedback the next time that ran their app that the library didn't work across all platforms.

This is not really different from the current dart:io imports - those will work on flutter for mobile, but not flutter for web.

@rostopira

@rostopira I'm not sure how accurate that information is. @vsmenon could you please confirm (or deny) what's said about package:js in #35588 (comment)?

@natebosch

fyi - @natebosch

That stack overflow comment is way out of date. Prefer package:js - we're working on updating docs to explicitly recommend that. It's no longer implemented over window.postMessage (that was a Dartium-based solution) - it's handled directly in the compilers and should be more efficient than dart:js.

I've added support for Flutter Web for flutter_parse_sdk package, and now it's score in pub dropped significantly https://pub.dev/packages/parse_server_sdk#-analysis-tab-

pana lowers the score extremly, because it throws some analyzer errors when importing dart:html etc.

An existing package, universal_html, could already solve this issue for a lot users.

// In Flutter web version, this gives you 'dart:html'.
// In normal Flutter, this gives you a library that is compatible with 'dart:html'.
import 'package:universal_html/prefer_sdk/html.dart';

void example() {
  // In Flutter web version, this is real window.localStorage.
  // In normal Flutter, the API works, but value is stored in the heap, not persistent memory.
  window.localStorage["key"] = "value";
}

An issue that's related to this issue: Dart SDK issue #37232 proposes that it would be possible to supply missing "dart:html" in Flutter by using "dependency_overrides" or a similar directive in Pubspec.yaml.

FYI: the issue about analysis and scoring on pub has been filed here: dart-lang/pub-dev#2763.

Any updates on this? As I also face issue after migrating from flutter_web to flutter and dart:html with dart:js stopped working.

We had a meeting with the Dart Analyzer team and are moving forward with adding dart:html and dart:js to the Flutter Analyzer SDK

Add gni files to the html, js, and js_util packages in support of add…

The bulk of this work has landed in the flutter master channel.

We'll still need to follow up with exposing one additional class from dart:js (JavaScriptObject), as well as creating a lint to better keep Flutter developers on the rails when they're using dart:html in a runtime context where that library will not be available.

Closing; the remaining work is in #41649.

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 -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Properly enable dart:html imports #35588

Use case

Proposal

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Properly enable dart:html imports #35588

Description

Use case

Proposal

Activity

provokateurin commented on Jul 12, 2019

devoncarew commented on Aug 14, 2019

jonahwilliams commented on Aug 14, 2019

provokateurin commented on Aug 14, 2019

provokateurin commented on Aug 14, 2019

provokateurin commented on Aug 14, 2019

rostopira commented on Aug 14, 2019

provokateurin commented on Aug 14, 2019

yjbanov commented on Aug 15, 2019

harryterkelsen commented on Aug 15, 2019

rostopira commented on Aug 16, 2019

rostopira commented on Aug 16, 2019

3 remaining items

devoncarew commented on Aug 16, 2019

yjbanov commented on Aug 16, 2019

vsmenon commented on Aug 16, 2019

rostopira commented on Aug 23, 2019

provokateurin commented on Aug 23, 2019

terrier989 commented on Sep 6, 2019

yjbanov commented on Sep 13, 2019

deimantasa commented on Sep 18, 2019

harryterkelsen commented on Sep 19, 2019

devoncarew commented on Sep 25, 2019

devoncarew commented on Sep 30, 2019

github-actions commented on Aug 13, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions