WebAssembly Compilation about mqtt_client HOT 8 OPEN

Yes your right, the earlier we look at these things the better, I'll have to perform the same upgrade on some of my other packages so we might as well start here.

I've not looked into this area as yet, I'll familiarise myself with pkg:web but you seem to have done a lot of the legwork here already, thanks, happy to look at any pull requests from you.

As for sigv4 its only used in the AWS example. Its nice to have this but if we can't get the aws_signature_v4 package to work I can live without it, we can't let stuff like this stop us upgrading to newer packages.

from mqtt_client.

Hi @shamblett. I've recently raised an issue on the flutter github repo.

In the issue raised, I mentioned that the WebSocket factory method (from inside universal_html) was throwing an error. "mkustermann" Stated in his reply that the universal_html package needs to be migrated to use their static JS interop APIs and the conditional imports need to be updated.

Version 10.0.2 included the change from using dart:html to using the universal_html package.

from mqtt_client.

Hi @shamblett. I've recently raised an issue on the flutter github repo.

In the issue raised, I mentioned that the WebSocket factory method (from inside universal_html) was throwing an error. "mkustermann" Stated in his reply that the universal_html package needs to be migrated to use their static JS interop APIs and the conditional imports need to be updated.

Version 10.0.2 included the change from using dart:html to using the universal_html package.

It doesn't really make sense for universal_html to migrate to pkg:web as it is intentionally a drop-in for the html package. The patch I linked in the original comment should serve as a much better starting point for you in migrating to pkg:web for WebAssembly purposes. IMO, we should just migrate universal_html->pkg:web ourselves and skip that process. We were using html directly until last month. You'll see a conflict if you try to merge it over the main branch but just replace universal_html with web.

from mqtt_client.

Yep Ok, we need universal_html for now as it fixes some flutter apk and web bundling problems as stated in the implementing PR #509, we can work out what to do with this when we get to implement this issue.

from mqtt_client.

Yep Ok, we need universal_html for now as it fixes some flutter apk and web bundling problems as stated in the implementing PR #509, we can work out what to do with this when we get to implement this issue.

We don't need universal_html. We can prevent build errors with conditional imports: https://dart.dev/interop/js-interop/package-web#conditional-imports

from mqtt_client.

Yep OK, the original poster said this in the PR -

 it is currently not possible to bundle both browser and APK support within the same application.

Ok, I don't know enough about flutter to know if we can achieve the same thing using conditional imports, I would have though the OP would have looked at this though.

from mqtt_client.

Yep OK, the original poster said this in the PR -

 it is currently not possible to bundle both browser and APK support within the same application.

Ok, I don't know enough about flutter to know if we can achieve the same thing using conditional imports, I would have though the OP would have looked at this though.

In a production environment, I currently ship mqtt_client from a monorepo with windows + web targets, and I have zero issues when I use conditional imports. I would also like to think that OP has looked at this, but I do not believe this is the case. I also do not believe it is the responsibility of mqtt_client to handle non-browser targets within MqttBrowserClient.

In any case, I opened a draft PR that should support WebAssembly compilation with Flutter 3.19.x as well as Flutter master.

from mqtt_client.

Yes, the browser client should only do what it claims to do, i.e. work in the browser.

The more I think about this the more I think we should what we need to do here then see where we are and see what if any effect this has had on other users, we can fix any problems that arise on a case by case basis when we(I) have a better understanding of them.

from mqtt_client.