Ensuring our API is similar to Web

[bcardarella]

Because we are "just building a browser" with LVN Core I want to ensure that we are matching the same API that exists on the web, in other words if we are exposing analagous functions to clients tha would exist within a browser we should be exposing the same fucntion name. Examples:

• document - should expose the underlying document
• document.querySelector(selectors) - for querying the document

Our mission is to ensure we are providing a new yet familiar experience. We are building on top of existing knowledge that developers have about how a web browser works but we are swapping out certain parts of that stack. LVN's role is to be the foundational piece of this.

[mobile-bungalow]

Because it's something I will be referencing quite a bit I will leave the whatwg documentation for the document interface here.

[carson-katri]

Core has this Selector type: https://github.com/liveview-native/liveview-native-core/blob/80615ec8b28e702f73f6eef3d08a71fc6fa9e75e/crates/core/src/dom/select.rs#L5

I would personally prefer to use this enum to construct selectors than with a string like the web API.

[bcardarella]

@carson-katri what is the API like? What are you passing in for a query?

[carson-katri]

It would look something like this from Swift:

document.select(.tag("Text")) // Text
document.select(.id("my-text")) // #my-text
document.select(.and(.tag("Text"), .attribute("verbatim"))) // Text[verbatim]
document.select(.and(.id("my-text-1"), .id("my-text-2")))) // #my-text-1, #my-text-2

And here's an example of it being used in core: https://github.com/liveview-native/liveview-native-core/blob/80615ec8b28e702f73f6eef3d08a71fc6fa9e75e/crates/core/src/live_socket/channel.rs#L111-L123

[bcardarella]

wouldn't that require supporting API on Core? The idea with using a pre-existing parser with a selector engine was we could utilize it for querying without having to write something from scratch

[carson-katri]

The API already exists in core, I just don't think it's exposed to the clients.

[bcardarella]

@carson-katri I'm not sure I'm in agreement with this API. It would mean exposing it to the developers as well, for example to target another set of elements query selector API is already known. But this API would be something new. I'm talking about situations ilke:

LVN.hide(to: "#other")

this is a contrived example but relying on CSS query selector syntax means we are allowing people to use pre-existing knowledge. If we are now requiring a new query engine API it would require both knowledge acquisition but also an encoding/decoding format so it can be written into and extracted from templated.

[mobile-bungalow]

I think I can just expose the API to the crates that consume the FFI API, as it might be useful there, without us making it a public API in the swift packages or jetpack packages. Exposing the string API shouldn't be that hard.