full support for flutter-web

[fischerscode]

I recently tried run my app in the browser.
Last time I tried this, it worked. This time it didn't.
The difference between success and failure is the login I added recently.

Unsupported operation: Platform._operatingSystem is printed in the log.

It seems like dart:io is causing the issue. firebase/flutterfire#1257

For live query we have two separated files. One for mobile/desktop and one for web.
We could do similar for all the files using dart:io.

Any ideas/suggestions? Or should we not support flutter-web?

Edit:
CoreStoreSembastImp would need an update, too. I think sembast has an extra package for web.

[phillwiggins]

Hey

I definitley think we should support flutter-web. I've been majorly tied up over the last few months so not had a chance to look into it. I was under the impression that Sembast would support flutter-web but I could be wrong. It would be great if we supported all platforms that Dart is able to run on?

[fischerscode]

It seems like universal_io should solve this problem.
Has anyone used universal_io yet?

[nstrelow]

Can we not just include universal_io? Seems it should do the trick.

[nstrelow]

I think this is just due to Platform.isAndroid etc. not being supported. At least that's were it breaks for me first.
I believe we can just use kIsWeb from foundations to check for web first.

I'll create a PR later, as we need this now, if we still want web to keep on working for us.

[nstrelow]

So my bad #392 did not fix web, but circumvented the first issue that arose.
Next one is:

Overflow on channel: uk.spiralarm.flutter/devicelocale.  Messages on this channel are being discarded in FIFO fashion.  The engine may not be running or you need to adjust the buffer size if of the channel.
╭-- Parse Response
Class: _User
Function: ParseApiRQ.loginAnonymous
Status Code: -1
Type: UnknownError
Exception: MissingPluginException(No implementation found for method currentLocale on channel uk.spiralarm.flutter/devicelocale)
╰-- 

Seems to be that devicelocale.currentLocale does not work on web.

Edit: Devicelocale does not support web: magnatronus/flutter-devicelocale#9

[nstrelow]

To get the current locale without the package devicelocale we can use: https://api.flutter.dev/flutter/dart-ui/Window/locale.html

Would look like this in parse_installation.dart:

//Locale
    if (!kIsWeb) {
      final String locale = await Devicelocale.currentLocale;
      if (locale != null && locale.isNotEmpty) {
        set<String>(keyLocaleIdentifier, locale);
      }
    } else {
      final String locale = ui.window.locale.languageCode;
      if (locale != null && locale.isNotEmpty) {
        set<String>(keyLocaleIdentifier, locale);
      }
    }

Next unsupported package is package_info: flutter/flutter#46609

This could also be just skipped by checking for kIsWeb:

//App info
    if (!kIsWeb) {
      final PackageInfo packageInfo = await PackageInfo.fromPlatform();
      set<String>(keyAppName, packageInfo.appName);
      set<String>(keyAppVersion, packageInfo.version);
      set<String>(keyAppIdentifier, packageInfo.packageName);
    }
    set<String>(keyParseVersion, keySdkVersion);

But now when creating a new user, I get this error:

╭-- Parse Response
Class: _User
Function: ParseApiRQ.signUp
Status Code: -1
Type: UnknownError
Exception: XMLHttpRequest error.
╰-- 



----
ParseException (Type: UnknownError) :
Code: -1
Message: XMLHttpRequest error.----

Not sure where to go from here, maybe @phillwiggins has an idea what is going wrong?

[nstrelow]

I think I traced the last one to the incompatibility of the http package.

http added support for web with this note:

In order to use or reference the IoClient directly, you will need to import the new package:http/io_client.dart import. This is typically only necessary if you are passing a custom HttpClient instance to the constructor, in which case you are already giving up support for web.

IOClient uses the dart:io package, which is not available on web. Will see if there is an alternative.

This line in ParseHttpClient uses IOClient if a security context is given:

        _client = securityContext != null
            ? IOClient(HttpClient(context: securityContext))
            : Client();

I'll try to find a way of not using IOClient, but not sure if possible.

EDIT: It seems to use BrowserClient instead of IOClient and still fail. So probably still a different issue.

[nstrelow]

Alright scratch the http package. In the end is a CORS error. I think that should be fixable.

Access to XMLHttpRequest at 'https://herokuapp.com/parse/users' from origin 'http://localhost:60240' has been blocked by CORS policy: Request header field x-parse-installation-id is not allowed by Access-Control-Allow-Headers in preflight response.

[fischerscode]

There is an option provided by the server to add custom headers.

Using env variables:
PARSE_SERVER_ALLOW_HEADERS=...

[nstrelow]

PARSE_SERVER_ALLOW_HEADERS is not working for my heroku setup sadly. Not sure what I am doing wrong: PARSE_SERVER_ALLOW_HEADERS=X-Parse-Installation-Id. Maybe because I am using express with parse-server

Is this normally required to set when using a the mobile SDKs?

Looking at parse-server there are default headers, which do not include the installation-id:

export const DEFAULT_ALLOWED_HEADERS =
  'X-Parse-Master-Key, X-Parse-REST-API-Key, X-Parse-Javascript-Key, X-Parse-Application-Id, X-Parse-Client-Version, X-Parse-Session-Token, X-Requested-With, X-Parse-Revocable-Session, Content-Type, Pragma, Cache-Control';

I guess mobile does not care about CORS and preflight. But for supporting web, we should either:

• Omit the installation-id when on web (change in flutter sdk)
• Make installation-id a default header (change in parse-server)
• Add to README, that setting custom headers via env in server is required for web to work. (change for the user)

EDIT: Was able to set allowHeaders in ParseServerOptions. The parsing of the heroku env vars does not work for some reason.

[fischerscode]

I think the best solution is to add a note to the REAMDE for bow. And once web is tested a bit more and seems to work with the additional header we should create a pr to parse-server.

I am using the env methode in a kubernetes enviroment. Maybe it is only supported when using the docker image.