branch: externals/graphql
commit ca75ab64c58ca7ab9621b881689d4461ebacb164
Author: Sean Allred <allred.s...@gmail.com>
Commit: Sean Allred <allred.s...@gmail.com>
Minor README formatting updates
Mostly hard-wrapping. I'd like to see what this looks like before
considering removing all the language tags from code blocks. Ideally,
we could just find a way to support the syntax in ELPA's renderer.
---
README.md | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/README.md b/README.md
index 76e106ee8a..800baecbf4 100644
--- a/README.md
+++ b/README.md
@@ -3,9 +3,11 @@
[](https://melpa.org/#/graphql)
[](https://travis-ci.org/vermiculus/graphql.el)
-GraphQL.el provides a set of generic functions for interacting with GraphQL
web services.
+GraphQL.el provides a set of generic functions for interacting with
+GraphQL web services.
See also the following resources:
+
- [GraphQL language service][graph-lsp] and [`lsp-mode`][el-lsp]
- [`graphql-mode`][graphql-mode]
- [This brief overview of GraphQL syntax][graphql]
@@ -17,20 +19,37 @@ See also the following resources:
## Syntax Overview
Two macros are provided to express GraphQL *queries* and *mutations*:
-- `graphql-query` encodes the graph provided under a root `(query ...)` node.
-- `graphql-mutation` encodes the graph provided under a root `(mutation ...)`
node.
-Both macros allow special syntax for query/mutation parameters if this is
desired; see the docstrings for details. I will note that backtick notation
usually feels more natural in Lisp code.
+
+- `graphql-query` encodes the graph provided under a root `(query
+ ...)` node.
+- `graphql-mutation` encodes the graph provided under a root
+ `(mutation ...)` node.
+
+Both macros allow special syntax for query/mutation parameters if this
+is desired; see the docstrings for details. I will note that backtick
+notation usually feels more natural in Lisp code.
### Basic Queries
-The body of these macros is the graph of your query/mutation expressed in a
Lispy DSL. Generally speaking, we represent fields as symbols and edges as
nested lists with the edge name being the head of that list. For example,
+
+The body of these macros is the graph of your query/mutation expressed
+in a Lispy DSL. Generally speaking, we represent fields as symbols and
+edges as nested lists with the edge name being the head of that list.
+For example,
+
```emacs-lisp
(graphql-query
(myField1 myField2 (myEdges (edges (node myField3)))))
```
-will construct a query that retrieves `myField1`, `myField2`, and `myField3`
for every node in `myEdges`. The query is returned as a string without any
unnecessary whitespace (i.e., formatting) added.
+
+will construct a query that retrieves `myField1`, `myField2`, and
+`myField3` for every node in `myEdges`. The query is returned as a
+string without any unnecessary whitespace (i.e., formatting) added.
## Following Edges
-Multiple edges can of course be followed. Here's an example using GitHub's
API:
+
+Multiple edges can of course be followed. Here's an example using
+GitHub's API:
+
```emacs-lisp
(graphql-query
((viewer login)
@@ -38,7 +57,10 @@ Multiple edges can of course be followed. Here's an example
using GitHub's API:
```
## Passing Arguments
-Usually, queries need explicit arguments. We pass them in an alist set off by
the `:arguments` keyword:
+
+Usually, queries need explicit arguments. We pass them in an alist set
+off by the `:arguments` keyword:
+
``` emacs-lisp
(graphql-query
((repository
@@ -49,7 +71,11 @@ Usually, queries need explicit arguments. We pass them in
an alist set off by t
(edges
(node number title url id))))))
```
-As you can see, strings, numbers, vectors, symbols, and variables can all be
given as arguments. The above evaluates to the following (formatting added):
+
+As you can see, strings, numbers, vectors, symbols, and variables can
+all be given as arguments. The above evaluates to the following
+(formatting added):
+
``` graphql
query {
repository (owner: "github", name: $repo) {
@@ -63,14 +89,18 @@ query {
}
}
```
-Objects as arguments work, too, though practical examples seem harder to come
by:
+
+Objects as arguments work, too, though practical examples seem harder
+to come by:
``` emacs-lisp
(graphql-query
((object :arguments ((someVariable . ((someComplex . "object")
(with . ($ complexNeeds))))))))
```
+
gives
+
``` graphql
query {
object (
@@ -83,7 +113,9 @@ query {
```
## Working with Responses
+
- `graphql-simplify-response-edges`
+
Simplify structures like
(field
@@ -94,14 +126,25 @@ query {
into `(field (node1values) (node2values))`.
## Keyword Reference
+
- `:arguments`
- Pass arguments to fields as an alist of parameters (as symbols) to values.
See `graphql--encode-argument-value`.
+
+ Pass arguments to fields as an alist of parameters (as symbols) to
+ values. See `graphql--encode-argument-value`.
+
- `:op-name`, `:op-params`
- Operation name/parameters. Given to top-level *query* or *mutation*
operations for later re-use. You should rarely (if ever) need to supply these
yourself; the `graphql-query` and `graphql-mutation` macros give you natural
syntax to do this.
+
+ Operation name/parameters. Given to top-level *query* or *mutation*
+ operations for later re-use. You should rarely (if ever) need to
+ supply these yourself; the `graphql-query` and `graphql-mutation`
+ macros give you natural syntax to do this.
## Planned
+
- `:as` keyword for [aliases][graphql-alias] (`graphql-encode`).
-- `...` qualifier for [fragments][graphql-fragment] and [inline
fragments][graphql-ifragment] (`graphql--encode-object`)
+
+- `...` qualifier for [fragments][graphql-fragment] and [inline
+ fragments][graphql-ifragment] (`graphql--encode-object`)
[graphql-alias]: http://graphql.org/learn/queries/#aliases
[graphql-variable]: http://graphql.org/learn/queries/#variables
