Skip to content
This repository has been archived by the owner on Mar 21, 2021. It is now read-only.

WOOHOO! GraphQL interface 🔥 #29

Merged
merged 4 commits into from Jul 19, 2017
Merged

WOOHOO! GraphQL interface 🔥 #29

merged 4 commits into from Jul 19, 2017

Conversation

joelgriffith
Copy link
Owner

@joelgriffith joelgriffith commented Jul 18, 2017

navaliaql

Exposes a global navalia CLI, that'll boot up a GraphQL server for interacting with interactively! This does change some of the typings in Chrome.ts, but shouldn't be a major change

@mute
Copy link
Collaborator

mute commented Jul 18, 2017

:whoa:

This is really interesting.

So, if I'm following correctly, the idea is after executing a workflow, a user would have the option of querying elements / properties on the page using GraphQL syntax?

@joelgriffith
Copy link
Owner Author

It's actually all done at once, so you'd have to get everything lined up properly before executing. It does open the doors for more interactive workflows, but they'd need to be built on top of this

@joelgriffith
Copy link
Owner Author

I'll throw up an example gif in the AM since it is an odd concept

@joelgriffith
Copy link
Owner Author

Posted a gif in the first comment, still needs some work and API changes to line up just right, but the core is there

@joelgriffith joelgriffith merged commit 3cec11c into master Jul 19, 2017
@mute
Copy link
Collaborator

mute commented Jul 19, 2017

The API structure you came up with is really interesting -- so is there basically an implicit .then between each of the statements?

@joelgriffith
Copy link
Owner Author

joelgriffith commented Jul 19, 2017

Yes, which kind of goes against the norm in GraphQL where each field is executed in parallel. Otherwise queries would just be pyramids (and since all actions have side-effects here). Might regret it later 😬

@mute
Copy link
Collaborator

mute commented Jul 19, 2017

I wonder if the parallelism piece might actually be really useful here, though?

Like, even though this is a pyramid, I think something like this would actually be awesome:

{
  goto(url:"duckduckgo.com") {
    click(selector:".load-button") {
      text(selector: ".whatever")
      text(selector: ".other")
    }

    click(selector:'.-other-load-button') {
      text(selector: ".something-else")
      text(selector: ".something-other")
    }
  }
}

The idea here would be that at each tier, the queries should be parallelizable, and each leaf node can thus run in a new tab.

So, in this specific case, we'd end up with 4 tabs executing in parallel, two clicking -load-button and then returning the results of a different selector, the other two clicking -other-load-button and waiting on the results of their selectors.

What do you think? I totally get the concern about huge query pyramids, but I think that it's possible to work around that concern by using fragments intelligently, too.

@joelgriffith
Copy link
Owner Author


Let's discuss more in #30. This idea is incredibly intriguing...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants