-
Notifications
You must be signed in to change notification settings - Fork 89
Conversation
enables: ```ts for (const attribute of el.attributes) { ```
@harrishancock will this ship in the next release? |
My bad, I don't think the change in my PR is quite right. Current change: - readonly attributes: Iterator<{ name: string; value: string }>;
+ readonly attributes: IterableIterator<{ name: string; value: string }>; The worker runtime actually exposes this interface: readonly attributes: IterableIterator<[string, string]>; This means the worker's Element.attributes is not symmetric with the DOM's. Before I update the PR, can you confirm this is intentional? With the DOM API you'd write: for (const { name, value } of el.attributes) {
console.log(name, value);
} With the HTMLRewriter it's: for (const [name, value] of el.attributes) {
console.log(name, value);
} |
I'm not sure if the asymmetry with the DOM's API is intentional or not. (/cc @inikulin) It's a little unfortunate, but workers-types should just match what the runtime does and is documented to do, since changing the behavior, if we choose to do so, would take some time. As for when this can be released, I defer to @ispivey! |
@harrishancock @inikulin sounds good- PR matches the docs and workers runtime now. There's another small divergence from the DOM API with respect to Element.tagName. In the DOM it's always uppercase and in workers it's lowercase. May be worth calling these out in the docs. |
Back end returns an object that exposes two getters mimicking DOM API. So, the change will be required in Workers runtime only. |
@harrishancock @ispivey I think this is ok to merge. The PR matches the Cloudflare workers runtime as it is today, fixing a bug in the type definitions that prevents writing valid code like this: rewriter.on('bla', {
element: element => {
for (const [name, value] of element.attributes) { <----- |
enables: