Skip to content

Ensuring our API is similar to Web #212

Open

Description

@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.

Activity

  1. mobile-bungalow commented on Oct 25, 2024

    @mobile-bungalow
    Contributor

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

  2. carson-katri commented on Nov 12, 2024

    @carson-katri
    Member

    Core has this Selector type:

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

  3. bcardarella commented on Nov 12, 2024

    @bcardarella
    ContributorAuthor

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

  4. carson-katri commented on Nov 12, 2024

    @carson-katri
    Member

    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:

    .select(Selector::And(
    Box::new(Selector::Attribute(AttributeName {
    namespace: None,
    name: "data-phx-upload-ref".into(),
    })),
    Box::new(Selector::AttributeValue(
    AttributeName {
    namespace: None,
    name: "name".into(),
    },
    AttributeValue::String(phx_target_name.into()),
    )),
    ))

  5. bcardarella commented on Nov 12, 2024

    @bcardarella
    ContributorAuthor

    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

  6. carson-katri commented on Nov 12, 2024

    @carson-katri
    Member

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

  7. bcardarella commented on Nov 12, 2024

    @bcardarella
    ContributorAuthor

    @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.

  8. mobile-bungalow commented on Nov 12, 2024

    @mobile-bungalow
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions