DOMKit?

[j-f1]

It would be great to have some sort of type-safe DOM API that better matches DOM as exposed to JS (for example document.querySelector('foo')?.appendChild(document.createElement('bar'))) without having to go through the ceremony of .object! and .function!. It looks like there’s some work in this direction in webidl2swift but I’m not sure how much more is needed.

[MaxDesiatov]

Generating the WebAPI module as described in the webidl2swift example worked for me, but they have a dependency on a fork of JavaScriptKit. I think upstreaming changes from that fork could be the first step.

[j-f1]

I tried to merge but it seems like they made a bunch of unrelated changes in the fork which seem vaguely like a good idea since they reduce memory usage (I think) and cut down on the number of arguments that need to be passed around on the JS side but that means it’s hard to extract just the new stuff

And of course this repo has changed a bunch too so there were a lot of conflicts and now it doesn’t build

[j-f1]

I’ve got DOMKit building! (haven’t tried running it yet)

https://github.com/j-f1/DOMKit

let document = DOMKit.Document(jsValue: JSObjectRef.global.document)

let button = document.createElement(localName: "button")
button.textContent = "Hello, world"

class ClickListener: EventListener {
    required init(objectRef: JSObjectRef) {
        self.objectRef = objectRef
    }

    var objectRef: JSObjectRef
    static func canDecode(from jsValue: JSValue) -> Bool { false }
    func handleEvent(event: Event) {
        (event.target as? HTMLElement)?.textContent = "Clicked!"
    }
}

let emptyObject = JSObjectRef.global.Object.function!(.new)

button.addEventListener(type: "click", callback: ClickListener(objectRef: emptyObject))
_ = document.querySelector(selectors: "body")?.appendChild(node: button)

I’ll try it out tomorrow then clean up #26 so the commits are more meaningful.

[j-f1]

While this is a start, several changes are needed for a truly great native swift DOM API. We need to be able to modify the default function signatures to change or remove parameter names. Well some named parameters would be a great addition to the usability of the DOM API, I think that most of them provide little benefit. Dude also be great to extend the DON API with methods that make use of native Swift types and best practices. For example, options that are passed as an object in JavaScript could be expanded out to named parameters in Swift. It would also be good to allow passing Swift closures as an event handler, as the current way of creating a event handler object is extremely cumbersome.

I'm not sure if these additions should replace the current signatures or instead augment the current signatures — perhaps in a different file from the automatically generated bindings.

[j-f1]

With a ton of tweaks, I have got it working* again with perhaps fewer changes!

*I’m too scared to actually run it rn but it type checks!

[MaxDesiatov]

Closing this as we got it working more or less, appropriate discussions should happen in the DOMKit repository https://github.com/swiftwasm/DOMKit