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

fromEvent on node.js events #65

Closed
jfedyczak opened this issue Jul 3, 2016 · 6 comments · Fixed by #73
Closed

fromEvent on node.js events #65

jfedyczak opened this issue Jul 3, 2016 · 6 comments · Fixed by #73

Comments

@jfedyczak
Copy link

I'm trying to migrate from most.js. Is it possible to use fromEvent on node.js events? I'm trying to pass EventEmitter as a source but with no luck...

@Hypnosphi
Copy link
Contributor

As stated in docs, fromEvent is suited for DOM events. It uses .addEventListener internally. fromNodeEvent could be implemented like this:

function fromNodeEvent(emitter, event) {
  let callback;
  return xs.create({
    start(listener) {
      callback = value => listener.next(value);
      emitter.addListener(event, callback);
    },
    stop() {
      emitter.removeListener(event, callback);
    }
  });
}

@jfedyczak
Copy link
Author

jfedyczak commented Jul 4, 2016

Maybe such method should be added? It is present in most.js and in RxJS. I would provide a PR, but my TypeScript is not that fluent...

@staltz
Copy link
Owner

staltz commented Jul 5, 2016

I think we could do this, since fromEvent is an extra, and size is not a concern, but parity with RxJS and most.js is a benefit.

xtianjohns pushed a commit to xtianjohns/xstream that referenced this issue Jul 9, 2016
Add support for stream generation from EventEmitters.

fromEvent will accept as a first argument either a DOMElement or an
EventEmitter. When providing fromEvent with an EventEmitter, the
third argument is always ignored.

Internally, include an additional Producer type within fromEvent to
support type checking.

Related to staltz#65.
staltz pushed a commit that referenced this issue Jul 11, 2016
PR #73.

* Support EventEmitters in fromEvent extra

Add support for stream generation from EventEmitters.

fromEvent will accept as a first argument either a DOMElement or an
EventEmitter. When providing fromEvent with an EventEmitter, the
third argument is always ignored.

Internally, include an additional Producer type within fromEvent to
support type checking.

Related to #65.

* Revert indent change

Revert indentation change to remain consistent with project style.

* Refactor guards; Conform test and source style

Introduce style changes to enforce project source consistency. Adjust
type checking within the fromEvent function. Specifically, duck type the
first argument rather than rely on `instanceof` or `typeof` guards when
deciding which producer type to instantiate.

* Remove whitespace to align with project style requirements.
* Remove destructuring assignment in producer class methods.
* Update documentation to include both uses of the extra.
* Remove whitespaces and semicolons from example markdown.
* Refactor producer instantiation guards to implement duck-typing rather
  than `instanceof`/`typeof` checking.
* Remove unused import from tests
* Reorder assertion equality arguments.
* Rename parameter in fromEvent documentation (`eventType`>`eventName`)

* Expand emitter guard

Check for both `addListener` and `emit` methods on an element supplied
to fromEvent. This ensures that the function will not attempt to invoke
the `addListener` method on an xstream stream instance with incorrect
arguments. Instead, this scenario will throw a TypeError:

'this.node.addEventListener is not a function'
@jfedyczak
Copy link
Author

Thank you for the fix, but I'm trying to test this and I believe there's a problem with emitting events with more than one argument as in:

var fromEvent = require('xstream/extra/fromEvent').default
var http = require('http')

var srv = http.createServer()

fromEvent(srv, 'request')
.addListener({
  next: function(req, res) { // <-- problem here
      // res is undefined
      res.end(req.url)
  },
  error: function(err) { console.error(err) },
  complete: function() { console.log('completed') },
})

srv.listen(3002)

Possible solution would be emitting an array with all the args or passing all the args...

@staltz
Copy link
Owner

staltz commented Jul 11, 2016

Yeah, it would have to be an array or an object.

@xtianjohns
Copy link
Contributor

I sympathize with the use case there, @jfedyczak. I think implementations in other libraries handle this issue with selector support, which allows users to declare how to map the arguments from the emitter into the stream.

I'd be happy to take a stab at that, but I think it deserves a separate issue and maybe a discussion about how that approach fits in with the larger goals of xstream.

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

Successfully merging a pull request may close this issue.

4 participants