-
Notifications
You must be signed in to change notification settings - Fork 9
RFC: EventHandler #25
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
Conversation
|
@geovie sorry for the delay on this. We'll review this soon |
| // schedule a js function call with the arguments returned from the closure | ||
| pub fn schedule<T, F>(&self, closure: F) | ||
| where T: Value | ||
| F: FnOnce(&mut TaskContext, Handle<JsValue>, Handle<JsFunction>) -> Vec<Handle<T>>, |
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.
Probably IntoIterator can be used instead of Vec, but that can be decided during the implementation
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.
It needs to be turned into a Vec for other methods. Making it IntoIterator would be inefficient for the common case of already having a vector.
I really like this idea, but I think for it to make sense everything that takes a Vec<Handle<JsValue>> should be switched to IntoIterator.
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.
@kjvalencik Vec already implements IntoIterator, so it can be passed directly.
|
Hi, I would love to see this completed, merged and released, can I help for anything? |
|
@z0mbie42 this is being discussed both in this RFC as well as in the slack workspace. You are welcome to join the conversation if you have thoughts! We don't currently have an expected completion date, but hopefully not long! |
|
@dherman This looks good to me. Do you want to make a call for final comment period or given the demand for this feature, should we skip that? |
|
I like the simplification and reduction of boilerplate that you get from just being able to compute the arguments list instead of having to explicitly call the handler. In the future if we wanted (say, for performance) a lower-level method that lets you schedule arbitrary logic that take the cb.schedule_with(move |cx, this, func| { ... })we could add that backwards-compatibly. I don't think it's urgent, though, and I think we should accept the RFC as-is. We can always add more methods later. Awesome work, and thanks for keeping at it! |
|
I've labelled the RFC as being in final comment period! Thanks again @geovie for your work on this. |
|
🎉🎉🎉🎉🎉 RFC #25 is merged! 🎉🎉🎉🎉🎉 |
|
RFC #25 is implemented and merged behind a feature flag in neon-bindings/neon#375! |
Provide a way for bindings to call back into JavaScript from threads other than the Node.JS main thread
Rendered
Preliminary implementation: neon-bindings/neon#375