You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The spec says that server-sent events should have a lastEventId property, which is set to the value of the last id field that was sent through the stream (or the empty string if there was none). It doesn't necessarily have to belong to the current event; it's just the last event ID witnessed within that stream.
This library does something vaguely similar, but with some deviations:
The property is named id, not lastEventId
It's reset with each new event sent, rather than persisting
It's set to null by default, whereas lastEventId defaults to the empty string
lastEventId forbids null bytes; the id property allows them
I want to bring this in line with the spec, but I'm concerned about backwards compatibility with previous versions of the library. There are a few options:
Leave id as-is and document the differences.
Add lastEventId as a separate property, but keep id and its behavior. This would complicate the codebase, but would allow for better standards compatibility and backwards compatibility.
Do a major version bump, and fix this along with some other spec deviations (e.g. firing CustomEvents instead of MessageEvents; not setting the event's origin; lack of reconnection logic).
The text was updated successfully, but these errors were encountered:
I'm not sure I fully understand your analysis here, especially the id vs lastEventId part, since sse.js makes no attempt (so far) to implement lastEventId; the id field on events is something else entirely.
I'll send a PR with a drat proposal implementation.
The spec says that server-sent events should have a
lastEventId
property, which is set to the value of the lastid
field that was sent through the stream (or the empty string if there was none). It doesn't necessarily have to belong to the current event; it's just the last event ID witnessed within that stream.This library does something vaguely similar, but with some deviations:
id
, notlastEventId
null
by default, whereaslastEventId
defaults to the empty stringlastEventId
forbids null bytes; theid
property allows themI want to bring this in line with the spec, but I'm concerned about backwards compatibility with previous versions of the library. There are a few options:
id
as-is and document the differences.lastEventId
as a separate property, but keepid
and its behavior. This would complicate the codebase, but would allow for better standards compatibility and backwards compatibility.origin
; lack of reconnection logic).The text was updated successfully, but these errors were encountered: