Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"only-entities" feature? #38

Closed
matthiasbeyer opened this issue Dec 29, 2022 · 5 comments · Fixed by #39 or #44
Closed

"only-entities" feature? #38

matthiasbeyer opened this issue Dec 29, 2022 · 5 comments · Fixed by #39 or #44

Comments

@matthiasbeyer
Copy link
Contributor

I have a problem in my project... I need to pass data from mastodon-async to my frontend, which is compiled to WASM. For example mastodon_async::entities::status::Status.
Compiling mastodon-async to WASM is not possible, because of tokio, which cannot be compiled to WASM with the features mastodon-async needs.

I could, theoretically, copy all entity-types and add conversion from mastodon-async entity types to my own.

Another way would be to add a feature to mastodon-async for disabling everything except the entity types (which is the only thing I need to be able to pass them to the frontend). This way I could use the crate in my frontend only for the entity types.

I know this is a niche issue, but I figured that asking would be better than copying about 500 LOC into my codebase.

Any thoughts on this?

@dscottboggs
Copy link
Owner

ah. oh dear. I have two thoughts on this.

  1. could we make tokio an optional dependency and add a feature-gate to switch between tokio and some async runtime which does compile to WASM? There are only two uses for tokio in the library: a future timeout and a stream that yields lines as they come in asynchronously. I'm not too aware of the current state of the WASM target so I understand if (especially the latter use-case isn't supported)
  2. Another option (which we could opt to do regardless of that change) is to make the entities a separate crate (mastodon-entities or something) rather than a feature gate and then depending on that here in this crate.

@matthiasbeyer
Copy link
Contributor Author

There are only two uses for tokio in the library

aaah, damnit. And these can (to my best knowledge) not be generalized easily so that we do not depend on tokio directly.

could we make tokio an optional dependency and add a feature-gate to switch between tokio and some async runtime

I think not. Well, maybe. The actual error on my side is

compile_error!("Only features sync,macros,io-util,rt,time are supported on wasm.")

when compiling my frontend code and pulling in tokio. I am not sure whether making tokio an optional dependency / making the crate general over executors would solve the issue in a nice way. Maybe that's even a bit orthogonal to my issue at hand.

I have no strong feelings about that, but I think that it would be a better fix to do what you proposed in 2.

Another option is to make the entities a separate crate rather than a feature gate and then depending on that here in this crate.

Yes, this is exactly what I had in mind, too. We could even make that change backwards-compatible by pub useing the entities crate.

I will file a PR for that shortly.

matthiasbeyer added a commit to matthiasbeyer/mastodon-async that referenced this issue Dec 30, 2022
This patch move the entities module to a helper-crate.

With this, we give the user the opportunity to use only the entities
types in their codebase, if need be.
One scenario where this is required came up in

    dscottboggs#38

TL;DR is: A user needed to be able to pass types like `Status` from a
backend part of an application to a frontend which was compiled to WASM.
Because mastodon_async depends on tokio, which does not compile to WASM
(at least not with the features required by mastodon_async).

One option would have been to provide types in the application code
which can be constructed from mastodon_asyncs entity types. This would
lead to _a lot_ of code duplication (over several projects still,... but
that's rather undesireable anyways).

The solution mastodon_async offers with this patch is a helper-crate
which only contains the entity types: mastodon_async_entities.

mastodon_async publicly exports the whole mastodon_async_entities crate,
so users do not have to depend on the latter directly.

In addition to the `entities` module from mastodon_async, also the
`Visibility` type had to be moved.

`mastodon_async_entities` also got an own `Error` type, which
`mastodon_async::Error` can of course wrap.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: D. Scott Boggs <scott@tams.tech>
matthiasbeyer added a commit to matthiasbeyer/mastodon-async that referenced this issue Dec 30, 2022
This patch move the entities module to a helper-crate.

With this, we give the user the opportunity to use only the entities
types in their codebase, if need be.
One scenario where this is required came up in

    dscottboggs#38

TL;DR is: A user needed to be able to pass types like `Status` from a
backend part of an application to a frontend which was compiled to WASM.
Because mastodon_async depends on tokio, which does not compile to WASM
(at least not with the features required by mastodon_async).

One option would have been to provide types in the application code
which can be constructed from mastodon_asyncs entity types. This would
lead to _a lot_ of code duplication (over several projects still,... but
that's rather undesireable anyways).

The solution mastodon_async offers with this patch is a helper-crate
which only contains the entity types: mastodon_async_entities.

mastodon_async publicly exports the whole mastodon_async_entities crate,
so users do not have to depend on the latter directly.

In addition to the `entities` module from mastodon_async, also the
`Visibility` type had to be moved.

`mastodon_async_entities` also got an own `Error` type, which
`mastodon_async::Error` can of course wrap.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: D. Scott Boggs <scott@tams.tech>
matthiasbeyer added a commit to matthiasbeyer/mastodon-async that referenced this issue Dec 30, 2022
This patch move the entities module to a helper-crate.

With this, we give the user the opportunity to use only the entities
types in their codebase, if need be.
One scenario where this is required came up in

    dscottboggs#38

TL;DR is: A user needed to be able to pass types like `Status` from a
backend part of an application to a frontend which was compiled to WASM.
Because mastodon_async depends on tokio, which does not compile to WASM
(at least not with the features required by mastodon_async).

One option would have been to provide types in the application code
which can be constructed from mastodon_asyncs entity types. This would
lead to _a lot_ of code duplication (over several projects still,... but
that's rather undesireable anyways).

The solution mastodon_async offers with this patch is a helper-crate
which only contains the entity types: mastodon_async_entities.

mastodon_async publicly exports the whole mastodon_async_entities crate,
so users do not have to depend on the latter directly.

In addition to the `entities` module from mastodon_async, also the
`Visibility` type had to be moved.

`mastodon_async_entities` also got an own `Error` type, which
`mastodon_async::Error` can of course wrap.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: D. Scott Boggs <scott@tams.tech>
@dscottboggs
Copy link
Owner

is this

 compile_error!("Only features sync,macros,io-util,rt,time are supported on wasm.")

referring to tokio features? it sounds like it. I think we can get away with just features = ["macros", "io-util"] let me try that.

@matthiasbeyer
Copy link
Contributor Author

referring to tokio features?

Yes, sorry for not being specific enough.

matthiasbeyer added a commit to matthiasbeyer/mastodon-async that referenced this issue Dec 30, 2022
This patch move the entities module to a helper-crate.

With this, we give the user the opportunity to use only the entities
types in their codebase, if need be.
One scenario where this is required came up in

    dscottboggs#38

TL;DR is: A user needed to be able to pass types like `Status` from a
backend part of an application to a frontend which was compiled to WASM.
Because mastodon_async depends on tokio, which does not compile to WASM
(at least not with the features required by mastodon_async).

One option would have been to provide types in the application code
which can be constructed from mastodon_asyncs entity types. This would
lead to _a lot_ of code duplication (over several projects still,... but
that's rather undesireable anyways).

The solution mastodon_async offers with this patch is a helper-crate
which only contains the entity types: mastodon_async_entities.

mastodon_async publicly exports the whole mastodon_async_entities crate,
so users do not have to depend on the latter directly.

In addition to the `entities` module from mastodon_async, also the
`Visibility` type had to be moved.

`mastodon_async_entities` also got an own `Error` type, which
`mastodon_async::Error` can of course wrap.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: D. Scott Boggs <scott@tams.tech>
@dscottboggs
Copy link
Owner

Yeah, the looks like the problem is the rt-multi-thread feature was enabled, I have no idea why it would be. I've dropped it to just ["macros"].

matthiasbeyer added a commit to matthiasbeyer/mastodon-async that referenced this issue Jan 3, 2023
This patch move the entities module to a helper-crate.

With this, we give the user the opportunity to use only the entities
types in their codebase, if need be.
One scenario where this is required came up in

    dscottboggs#38

TL;DR is: A user needed to be able to pass types like `Status` from a
backend part of an application to a frontend which was compiled to WASM.
Because mastodon_async depends on tokio, which does not compile to WASM
(at least not with the features required by mastodon_async).

One option would have been to provide types in the application code
which can be constructed from mastodon_asyncs entity types. This would
lead to _a lot_ of code duplication (over several projects still,... but
that's rather undesireable anyways).

The solution mastodon_async offers with this patch is a helper-crate
which only contains the entity types: mastodon_async_entities.

mastodon_async publicly exports the whole mastodon_async_entities crate,
so users do not have to depend on the latter directly.

In addition to the `entities` module from mastodon_async, also the
`Visibility` type had to be moved.

`mastodon_async_entities` also got an own `Error` type, which
`mastodon_async::Error` can of course wrap.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: D. Scott Boggs <scott@tams.tech>
dscottboggs pushed a commit that referenced this issue Jan 4, 2023
This patch move the entities module to a helper-crate.

With this, we give the user the opportunity to use only the entities
types in their codebase, if need be.
One scenario where this is required came up in

    #38

TL;DR is: A user needed to be able to pass types like `Status` from a
backend part of an application to a frontend which was compiled to WASM.
Because mastodon_async depends on tokio, which does not compile to WASM
(at least not with the features required by mastodon_async).

One option would have been to provide types in the application code
which can be constructed from mastodon_asyncs entity types. This would
lead to _a lot_ of code duplication (over several projects still,... but
that's rather undesireable anyways).

The solution mastodon_async offers with this patch is a helper-crate
which only contains the entity types: mastodon_async_entities.

mastodon_async publicly exports the whole mastodon_async_entities crate,
so users do not have to depend on the latter directly.

In addition to the `entities` module from mastodon_async, also the
`Visibility` type had to be moved.

`mastodon_async_entities` also got an own `Error` type, which
`mastodon_async::Error` can of course wrap.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: D. Scott Boggs <scott@tams.tech>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants