feat(share_plus)!: Migrate to package:web

[koji-1009]

Description

Migration to the web package and addition of override methods.

---

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share#browser_compatibility

Chrome desktop doesn't support Share API on macOS.If someone want to run on macOS, please use Safari.
First, flutter run and check the service's url (ex. http://localhost:55926/). Then, open the url by Safari.

---

https://koji-1009.github.io/plus_plugins/

I uploaded example app. The branch is share_plus_web_demo.
When I try to build on GitHub Actions, it fails at odd points. For this reason, we push the build on the local machine to the gh-pages branch.

Related Issues

• Closes [Request]: (share_plus) Migrate to package:web to support WASM #2603
• Closes [Request]: In share_plus for web, use navigator.canShare method to check if files are shareable #2663

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I titled the PR using Conventional Commits.
• I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
• All existing and new tests are passing.
• The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
• No, this is not a breaking change.

[miquelbeltran]

Looking forward to this! I tried to work on it but couldn't figure out many things. Let me know if you need any assistance testing.

[koji-1009]

Hi! Implementation is almost complete!

I was having trouble with an unexpected exception in chrome on macOS, but it may be a bug in dart.

dart-lang/web#211

If we try-catch the Object instead of DOMException, it seems to work as expected in all browsers. However, this is clearly not what was expected and I would like to know what the dart team thinks.

[koji-1009]

The Issue was due to my lack of confirmation.

If there are API differences between browsers, they should be checked with NoSuchMethodError; if the API exists, error handling can be done with DOMException.

If we try to handle API differences with DOMException, it succeeds in the debug build, but fails in the release build. Probably due to the minify process.

---

I will also check sensors_plus again with the releae build.

[miquelbeltran]

Tested on Chrome + Windows. Thanks for the effort and for providing a hosted working example!