| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Instead of passing the payload for Workers directly to `.onmessage`, perform something more similar to what the browser API provides, namely create an event object with a `.data` property. This does not make `MessagePort` implement the `EventTarget` API, nor does it implement the full `MessageEvent` API, but it would make such extensions non-breaking changes if we desire them at some point in the future. (This would be a breaking change if Workers were not experimental. Currently, this method is also undocumented and only exists with the idea of enabling some degree of Web compatibility.)
|
@addaleax build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2593/pipeline |
Sorry, something went wrong.
|
I can't comment much on the implementation, but I'm very supportive of the event-ish object for easier web interop and future-proofing the API. Thanks for doing this, @addaleax! |
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-pull-request/20782/ (:heavy_check_mark:) |
Sorry, something went wrong.
Instead of passing the payload for Workers directly to `.onmessage`, perform something more similar to what the browser API provides, namely create an event object with a `.data` property. This does not make `MessagePort` implement the `EventTarget` API, nor does it implement the full `MessageEvent` API, but it would make such extensions non-breaking changes if we desire them at some point in the future. (This would be a breaking change if Workers were not experimental. Currently, this method is also undocumented and only exists with the idea of enabling some degree of Web compatibility.) PR-URL: #26082 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Instead of passing the payload for Workers directly to `.onmessage`, perform something more similar to what the browser API provides, namely create an event object with a `.data` property. This does not make `MessagePort` implement the `EventTarget` API, nor does it implement the full `MessageEvent` API, but it would make such extensions non-breaking changes if we desire them at some point in the future. (This would be a breaking change if Workers were not experimental. Currently, this method is also undocumented and only exists with the idea of enabling some degree of Web compatibility.) PR-URL: #26082 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Instead of passing the payload for Workers directly to `.onmessage`, perform something more similar to what the browser API provides, namely create an event object with a `.data` property. This does not make `MessagePort` implement the `EventTarget` API, nor does it implement the full `MessageEvent` API, but it would make such extensions non-breaking changes if we desire them at some point in the future. (This would be a breaking change if Workers were not experimental. Currently, this method is also undocumented and only exists with the idea of enabling some degree of Web compatibility.) PR-URL: #26082 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Notable Changes
* n-api:
* Implement date object (Jarrod Connolly)
#25917
* util:
* Add compact depth mode for `util.inspect()` (Ruben Bridgewater)
#26269
* worker:
* Improve integration with native addons (Anna Henningsen)
#26175
* MessagePort.prototype.onmessage takes arguments closer to the Web
specification now (Anna Henningsen)
#26082
Notable Changes
* n-api:
* Implement date object (Jarrod Connolly)
nodejs#25917
* util:
* Add compact depth mode for `util.inspect()` (Ruben Bridgewater)
nodejs#26269
* worker:
* Improve integration with native addons (Anna Henningsen)
nodejs#26175
* MessagePort.prototype.onmessage takes arguments closer to the Web
specification now (Anna Henningsen)
nodejs#26082
|
hey @addaleax, it seems that this changes the api when calling postMessage on the worker instance (and so onmessage inside the worker), but I don't see it changes the other way, when calling postMessage from inside the worker and getting the result in onmessage on the worker instance. Is it expected? Do you have any plan to implement this change as well? |
Sorry, something went wrong.
Sorry, something went wrong.
|
Ah I realize that in our code we use on('message', handler), and not onmessage indeed. But the general comment about implementing the structure { data: XXX } still applies :) |
Sorry, something went wrong.
|
Just to make it clear, this changes the info passed to port.onmessage to an object with a .data property, but does not change the info passed to port.on('message')? |
Sorry, something went wrong.
Yes, exactly. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Instead of passing the payload for Workers directly to .onmessage,
perform something more similar to what the browser API provides,
namely create an event object with a .data property.
This does not make MessagePort implement the EventTarget API, nor
does it implement the full MessageEvent API, but it would make
such extensions non-breaking changes if we desire them at
some point in the future.
(This would be a breaking change if Workers were not experimental.
Currently, this method is also undocumented and only exists with
the idea of enabling some degree of Web compatibility.)
Checklist