Double json encoding in SseConnection

[spkersten]

The type of SseConnection.sink is Stream<String>but then before sending (in _setUpListener) the message is JSON encoded. The interface I try to implement expects singly encoded JSON. Could the type of SseConnection.sink be relaxed to Stream<Object> so any JSON-encodable object can be sent?

[grouma]

The message is JSON encoded before sending over the wire. We decode it into a String here:

sse/lib/client/sse_client.dart

Line 126 in be426a2

jsonDecode((message as MessageEvent).data as String) as String;

Changing this behavior would be a breaking change. Note the resulting String should be singly encoded so I'm not sure what the issue is. Can you provide more details?

[spkersten]

It currently only allows Strings to be sent. I'd like to send json object (say, a list of strings). So I use json.encode to make it a String, but then _setUpListener encodes it as json again.

I'm not proposing to remove the json encoding (as it would be a break change) but to change the type of SseConnection.sink to Stream<Object> so that in addition to Strings it accepts any json-encodable object.

[grouma]

The incoming type will have to change which is a breaking change:

sse/lib/client/sse_client.dart

Line 94 in be426a2

Stream<String> get stream => _incomingController.stream;

The String you get on the otherside can be decoded once again to get the obj you want.

[ratzrattillo]

I would propose to introduce this breaking change. It makes using the library more difficult, especially for newcomers.
Also, you would not expect this behaviour according to the standard. Why not stick to https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events ?

I wondered also, why there are "Control Messages" like "close" to close the connection. Ideally, this is not done by the library, but by the user. Also, SSE is intended as a one way data transfer. I cannot follow these design decisions, even though they are stated in the Readme.

//Edit:
If the design decisions of this package cannot be followed, maybe it is better to use EventSource from dart:html directly instead.

[radzish]

Absolutely agree. With current implementation this package is unusable.