You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 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.
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.
Activity
mobile-bungalow commentedon Oct 25, 2024
Because it's something I will be referencing quite a bit I will leave the whatwg documentation for the document interface here.
carson-katri commentedon Nov 12, 2024
Core has this
Selectortype:liveview-native-core/crates/core/src/dom/select.rs
Line 5 in 80615ec
I would personally prefer to use this enum to construct selectors than with a string like the web API.
bcardarella commentedon Nov 12, 2024
@carson-katri what is the API like? What are you passing in for a query?
carson-katri commentedon Nov 12, 2024
It would look something like this from Swift:
And here's an example of it being used in core:
liveview-native-core/crates/core/src/live_socket/channel.rs
Lines 111 to 123 in 80615ec
bcardarella commentedon Nov 12, 2024
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 commentedon Nov 12, 2024
The API already exists in core, I just don't think it's exposed to the clients.
bcardarella commentedon Nov 12, 2024
@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:
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 commentedon Nov 12, 2024
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.