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

Can remove a line #48

Closed
david-mark opened this issue Jan 14, 2022 · 1 comment
Closed

Can remove a line #48

david-mark opened this issue Jan 14, 2022 · 1 comment

Comments

@david-mark
Copy link

Inside _onerror:

this._eventSource.close();

...appears to do nothing, as the first line of the eventSource._close() method just returns immediately (and silently) if readyState is 2 (CLOSED). There's definitely some lousy code in the original module; I remember tearing my hair out trying to follow what it was doing with the error events (to solve the same problem you are dealing with here).

From the original:

EventSource.prototype.close = function () {
this._close()
}

this._close = function () {
if (readyState === EventSource.CLOSED) return
readyState = EventSource.CLOSED
if (req.abort) req.abort()
if (req.xhr && req.xhr.abort) req.xhr.abort()
}

@harmony7
Copy link
Contributor

Hi there,

Yes, it does appear that close() would effectively result in a no-op by the way EventSource/eventsource implements it.

Keep in mind however that reconnecting-eventsource is a wrapper around EventSource as provided by the DOM (native code). EventSource/eventsource is a polyfill, and the behavior that you are describing is just how that polyfill happens to implement close().

I believe we are doing the right thing by calling close() on the old object before creating a new one in response to an error. Closing for now, but feel free to reopen if you have further comments/thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants