Server Sent Event support

[Th3-M4jor]

Describe the feature you'd like
Adding a yew::service for Server Sent Events, I imagine this one wouldn't be too difficult to add as it would behave similar to a one-way Websocket, and web_sys has support for the EventSource object.

Describe alternatives you've considered (Optional)
While this can handled with Websockets as an alternative, the use cases are somewhat different, owing to communication being uni-directional.

Questionnaire

• I'm interested in implementing this myself but don't know where to start
• I would like to add this feature
• I don't have time to add this right now, but maybe later

[liquidnya]

I was in need of server send events as well. Therefore i created this little library: https://github.com/liquidblock/yew-sse
Unfortunately i did not test nor document it (and i did not create an example), but used it like this:

match self.sse.open(
    &url,
    self.link.callback(move |(id, message): (String, String)| {
        Message::SendEventMessage(id, message)
    }),
    self.link.callback(move |value: EventSourceUpdate| {
        match value {
            EventSourceUpdate::Open => Message::SendEventOpen,
            EventSourceUpdate::Error => Message::SendEventError,
        }
    }),
) {
    Ok(task) => {
        self.task = Some(task);
    }
    Err(e) => {
        // error handling
    }
}

self.sse is of type yew_sse::services::sse::EventSourceService and initialized with EventSourceService::new().
self.task is of type Option<yew_sse::services::sse::EventSourceTask> and when dropped it will close the server send event handling.
The onopen, onerror and onmessage events are handled and also the last event ID together with the message is passed to the callback. But i did not implement named events since i did not need them, but was thinking about using a HashMap with the name of the event as a key and the event handler task as a value. With that it would be possible to add and remove named events.
I wrote this library to be used by myself, but also intended to be used with yew and was planning on creating a PR after adding an example, documentation and tests, but never got the time for it.

The library works with stdweb and web-sys, but it was written for yew version 0.16.2.

[thedanvail]

I'm going to start taking a look at this

[madmaxio]

@LiquidBlock , do you plan to merge your crate as a service?

[thedanvail]

I've returned after a hard fall/winter to look at what @LiquidBlock has and to try to merge it into the code base. As this is my first foray into open source development, if anyone could offer up some time to walk me through a few things, I'd be REALLY grateful. I've gone through and read the yew/CONTRIBUTING.md file along with the external links listed in said file. For now, I'll get myself acquainted with his code base, clean up anything that may need cleaning up, and start with adding documentation.

[liquidnya]

For now, I'll get myself acquainted with his code base, clean up anything that may need cleaning up, and start with adding documentation.

I prefer to be referred to by they/them pronouns.

---

@LiquidBlock , do you plan to merge your crate as a service?

The reason as to why I did not create a PR of my crate as a service in yew is because of my missing documentation, tests and examples.
For the tests (and maybe also the example) there probably needs to be some kind of server that has an Server Send Event interface that can be tested against.
Could that SSE testing server be started from the test case or would it be required to be already running for that specific test case?
This is a question I got stuck on and then did not ask here nor in Discord yet.

---

I would be interested in helping out moving the code into yew.
@thedanvail if you want some help moving the library into yew, extending it's implementation, answering some questions you might have, or writing tests/examples, let me know.

---

Also looking back at my code, there are some suggestions for further implementing SSE as a yew specific service:

• The callback argument in open (and open_with_credentials) uses (String, String) as type argument.

  • Creating a separate type e.g. EventMessage instead of using (String, String) would make it more clear that the message contains the last event ID together with the message.
  • It would probably be nice to also use OUT: From<Text> as in yews WebSocketService::connect_text and then use (String, OUT) as Callback type argument. (or EventMessage<OUT> where the OUT type is used for the message and String is still used for the last event ID)

• Named events are not yet implemented.

  • I suggest adding something like this to EventSourceTask:

  fn set_named_listener<OUT: From<Text>>(
      &mut self,
      name: String,
      callback: yew::Callback<EventMessage<OUT>>,
  ) {
  }
  fn remove_named_listener<Q>(&mut self, name: Q)
  where
      String: Borrow<Q>,
      Q: Hash + Eq,
  {
  }

  and then inserting/removing EventListener in a HashMap that has been initialized with HashMap::with_capacity(0).

[madmaxio]

@LiquidBlock Good idea is to use warp as a server - it does have SSE support https://github.com/seanmonstar/warp/blob/master/examples/sse_chat.rs, https://github.com/seanmonstar/warp/blob/master/examples/sse.rs.
As for output types, IMHO it should be similar to WS service.

[thedanvail]

@LiquidBlock I’m sorry - I shouldn’t have assumed. I’ll remember to use inclusive language in the future.

[thedanvail]

@LiquidBlock id love some help if you have the time to offer it. I’m with my partner this weekend, so I’ll be very sparse with communications, but on Monday, I’ll be back to it and maybe we can work together 😀

[liquidnya]

@thedanvail do you have a Discord account? There is a yew Discord server (the link is in yews readme).
Discord might be better suited for synchronous communication. I have some time on Monday, probably somewhere between 3pm-7pm UTC.

[thedanvail]

@LiquidBlock I do - I'll hop into that one. Unfortunately, I'm in CST time, so that's coincided with my work day, but I'll still do my best to knock out what I can! If I have problems/questions, would you mind if I messaged you?

[astraw]

In case it is useful, I have this little library which I have extracted from some of my other code: https://github.com/strawlab/yew-event-source . You are welcome to incorporate as much or as little as you like directly into yew.

[thedanvail]

Hello everyone,

Regrettably, I think this is just beyond my skill level right now. I'd rather say this outright than just disappear into the ether. It'd be to the point where I was just riding off the coattails of whomever I would ask for help. So, I have to drop this from my plate; if anyone else can pick it up, please feel free! Thanks to @LiquidBlock for their help this far, and hopefully, when my JS/Rust skills are stronger, I can come and contribute in another way :)

[astraw]

@thedanvail thanks for the update. Please come back anytime!

Since there are two crates that implement SSE mentioned above (liquidblock's https://github.com/liquidblock/yew-sse and my https://github.com/strawlab/yew-event-source), it seems the most substantial hurdle for inclusion directly into yew is writing an example. (And possibly a test case, although the websocket service does not have that. Perhaps our standards are higher now and we should include tests for SSE and, while we are at it, for websockets.)

Since this is tagged with "good first issue", I will point out that the dashboard example uses the websocket service and hopefully could serve as a basis for new example for event source. I would say that for a "first issue", I would not require the initial implementation to include the test infrastructure to start a server.

[ranile]

yew::service doesn't exist anymore. This functionality should be part of gloo (rustwasm/gloo#8) /reqwasm. This issue should probably be closed now.