Support compiling in projects that support web

[JacobSchantz]

A project that imports object-box should be able to compile on web. As is, if we'd like a project to run on web, stubs must be created to avoid importing the package. This should be done within the package, so it will just work out of the box.

[greenrobot-team]

Thanks for sharing this use case. However, I have not seen other Dart packages (like dart:io vs http) that do this or the docs recommending to do this. Can you maybe point at some?

The recommended solution I'm aware of is using conditional imports. Does that not work for your project?

Note: I labeled this issue with "more info required" so it will auto-close in a few days if there are no follow-up comments.

[JacobSchantz]

Appreciate your response! I think it would work, but it would require more configuration. I wouldn't need any formal web support, just the ability to compile for web. The path_provider package does this without formally supporting web. Adding path_provider to a project doesn't break web support, but calling any path_provider functions on web, will throw an error. This way, functionality is added and nothing is lost. Here is an article I found mentioning this issue: https://docs.bluebubbles.app/client/dev/flutter/objectbox.

[JacobSchantz]

Any update on this? Would this be difficult to implement?

[greenrobot-team]

Thanks for the pointer. But after a quick look I'm confused: how would what works for the path_provider package not work for the objectbox packages? They also do not declare web support?

Any update on this? Would this be difficult to implement?

If you need features for your use case and added faster, look into signing a support contract with us.

Note: I labeled this issue with "more info required" so it will auto-close in a few days if there are no follow-up comments.

[JacobSchantz]

They don't declare support and yet it compiles with no issues. Importing objectbox In any file, will not compile for web. Path_Provider can be included in any file without problems. It will just throw if you try to use any of its functions. The same is true of the in_app_purchase package. It is not supported on web and yet doesn't break compilation. When using code generation this means we have to conditionally import every class that uses objectbox if we'd like to compile for web. We'll consider supporting you, I love the work you all have done!

[greenrobot-team]

Got it. I don't have time to look into this for now, but can you maybe share the compiler error that you see? I'm curious, maybe it's an easy fix.

[JacobSchantz]

../../../../../../../.pub-cache/hosted/pub.dev/ffi-2.1.3/lib/src/allocation.dart:21:15: Error: Only JS interop members may be 'external'.
Try removing the 'external' keyword or adding a JS interop annotation.
external void posixFree(Pointer ptr);

There are a ton of errors like this. I think it's just importing packages that don't compile on web, like ffi.

[JacobSchantz]

I think this commit basically solved it, #189. However, some imports were added back in to break it again.

[greenrobot-team]

Thanks again! Looks like this was discussed in #283 and then decided to intentionally break web support by exporting native/store.dart instead of an empty file.

Also reported in that same issue, it appears the empty file export currently done for the files in lib/src is as you said more problematic than adding stubs. So there is no quick-fix here (just exporting an empty store.dart for web).

That same user provided an example of how to use conditional imports.

In that issue it was also suggested to put all code related to ObjectBox in a separate package. But I don't see how that would help. It would likely still be required to use conditional imports.

In any case, we will think about this. Maybe true web support will even be available before then (#185).

[JacobSchantz]

You should support this out of the box. That thread you mentioned shows someone who did this. It's not as simple as forking the repo and commenting out one line. They had to conditionally import every single model that used object-box.

[JacobSchantz]

That means anyone who would like to support code generation and have web and mobile code in one place (a pretty common scenario for flutter) will need to do that.