-
Notifications
You must be signed in to change notification settings - Fork 38
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
Adding operator attachEventWithElement #124
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% convinced that we should add this feature and would like to encourage thinking about an alternative such as opening up the possibility to have more than one ref
per element.
import { combineRefs } from './combineRefs'; | ||
import { of } from 'rxjs'; | ||
|
||
export const attachEventWithElement = (...events) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about the ergonomics of this operator. What I don't like is that it produces only a single stream for all of the registered events, forcing the user of the API to do the splitting manually. I have the feeling that it'd be more valuable if it returned one stream per defined event.
The other part of the question is whether we should add this at all. Its a userland solution for an underlying problem: You can only define a single ref
per element. So if we find a way to add more than one ref
, that might solve the problem already.
What do you think?
...eventsAndElement.map(([handler]) => handler) | ||
); | ||
const streams = eventsAndElement.map(([_, stream]) => stream); | ||
return [refHandler, ...streams]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we keep this API design we could use streams[0], streams[1]
here instead of the spread operator for more explicitness, smaller size and better performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same goes for the other usages
What changed in this PR:
This PR adds the operator
attachEventWIthElement
which extends the already existingattachEvent
operator by returning an observable that will contains the el reference where the eventHandler(s) are attached to.