What is the reason of implementing a Clone trait for the EventSource?

[xeho91]

Hi gloo maintainers!

Thank you for providing this awesome library, which helps me during development of app for WASM target.

---

Background

In order to understand where my question comes from, I believe giving a more background could help, so here it goes:

The project I work on heavily relies on using SSE, so we're using the EventSource from your net crate.

I have coded a global state using yewdux (we currently use yew UI framework) which stores an instance of EventSource. The reason is that we have several components (sections) which uses different subscriptions (subscribing to different event types) from the same SSE route (a single instance of EventSource with the same URL set).

I've noticed that while attempting to call .clone() on stored EventSource instance in the global state, it produced an unwanted behaviour! (code reference)

Please mind my beginner knowledge of the Rust, hence I created this question.

What I understood (with the help of @vpochapuis) that is happening, that once we're cloning an EventSource, then we're immediate losing any preciously set the connection (if any subscription was invoked). This is because of implemented Drop trait for it. So, when it goes out of scope, it loses any existing Stream from the subscriptions. By the way, as far I could tell, it doesn't remove the existing streams, as we could understand from the implementation of Drop trait in the code.

This caused me a trouble, because I couldn't figure out why I kept getting the ConnectionError, even when I confirmed that this route is working properly.

I may be wrong, but this could be prevented by removing the Clone trait implementation for EventSource. Hence I would like to ask and understand better why the decision was made to implement this trait. We would love to contribute on improving the API, but we need some understanding firstly. @vpochapuis has some great ideas on how to improve.

---

Please let me know if you need more information on my use case and thank you in advance for taking a time to respond to my - hopefully not too complicated - question.

[vpochapuis]

Hi gloo maintainers!

Thank you for providing this awesome library, which helps me during development of app for WASM target.

Background

In order to understand where my question comes from, I believe giving a more background could help, so here it goes:

The project I work on heavily relies on using SSE, so we're using the EventSource from your net crate.

I have coded a global state using yewdux (we currently use yew UI framework) which stores an instance of EventSource. The reason is that we have several components (sections) which uses different subscriptions (subscribing to different event types) from the same SSE route (a single instance of EventSource with the same URL set).

I've noticed that while attempting to call .clone() on stored EventSource instance in the global state, it produced an unwanted behaviour!

Please mind my beginneer knowledge of the Rust, hence I created this question.

What I understood (with the help of @vpochapuis) that is happening, that once we're cloning an EventSource, then we're immediate losing any preciously set the connection (if any subscription was invoked). This is because of implemented Drop trait for it. so, when it goes out of scope, it loses any existing Stream from the subscriptions. By the way, as far I could tell, it doesn't remove the existing streams, as we could understand from the implementation of Drop trait in the code.

This caused me a trouble, because I couldn't figure out why I kept getting the ConnectionError, even when I confirmed that this route is working properly.

I may be wrong, but this could be prevented by removing the Clone trait implementation for EventSource. Hence I would like to ask and understand better why the decision was made to implement this trait. We would love to contribute on improving the API, but we need some understanding firstly. @vpochapuis has some great ideas on how to improve.

Please let me know if you need more information on my use case and thank you in advance for taking a time to respond to my - hopefully not too complicated - question.

Hello,
To add a bit to this explanation of the issue.
The issue was that, when going out of scope, any clone of the EventSource would trigger the disconnection mechanism present in the Drop implementation.
Hence, to maintain a connection, one need to be very careful of the lifetime of every clone of the EventSource, leading to undesired behavior when not making sure all clones stay in scope.
There is no clear way to tell whether this mechanism has been triggered (unless manually tracking the lifetime of each clone), and its not very explicit for the user.
Two possible solutions for this seem to be:

• Remove the Clone trait implementation if its deemed unnecessary, as it is introducing a behavior that could mislead users
• Use another Rust mechanism to make it more explicit to the user about the underlying behavior

I might miss information on this and would be very happy to have further explanations to learn more about the design decision and the ecosystem.
I am sorry in advance if my understanding is wrong.

There would also be other details of the implementation I would like to discuss based on my understanding of the specification if the opportunity arise.

Thank you for your time and attention!

[vpochapuis]

I would like to add a specific use case example of the related issue:

When using yewdux a global state manager for the yew web Frontend framework, a global state must implement Clone (if the state has to be mutated).
In this case, simply inserting an Option<EventSource> as a field of this state will compile and "seem to work" in the current design.
However, internally, and to be honest, I don't know how the global state manager works, yewdux seems to clone and drop the whole state, and consequently disconnect the EventSource without any other clue for the user to know about this other than the fact that the yewdux state requires the state to be Clone.
In that case, using a Option<Arc<RwLock<EventSource>>> solves this issue (this is the quick solution i found, if its incorrect or there is better designs please let me know).

Having the Clone trait removed from the EventSource would let the user know in that case that he needs to find other solutions (like an Arc<RwLock<EventSource>> instead of trying to clone the EventSource directly, hence avoiding the undesired behavior.

Or would there be another solution that would make it so that the Drop trait only disconnects when there is no other reference to some internal counted reference? I don't know if it would be feasible.

[ranile]

This seems to be a bug to me. I would be happy to look at any PRs removing the Clone implementation. We can tell users to use Rc if the instance is to be passed around without borrowing it

[vpochapuis]

I have made something quick here #417 .
If you would like me to add some kind of documentation or comments please let me know!