Skip to content

Commit

Permalink
Specified scope when processing joins and updated README
Browse files Browse the repository at this point in the history
  • Loading branch information
kmcaloon committed May 19, 2020
1 parent 864192d commit a6c31b8
Show file tree
Hide file tree
Showing 2 changed files with 30 additions and 7 deletions.
32 changes: 28 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ https://drive.google.com/file/d/1FVch2HbAWk1TEXph1katiNb1uuaBLSHf/view?usp=shari
- Replicates Gatsby's beloved patterns
- GROQ-based page queries with HMR
- GROQ-based static queries with live reloads
- Leverages GROQ's native functionality for advanced querying, node/document projections, joins (see [limitations](#joins)), etc,
- Leverages GROQ's native functionality for advanced querying, node/document projections, joins (see [notes on joins](#joins)), etc,
- String interpolation ("fragments") within queries, much more flexible than GraphQL fragments
- GROQ explorer in browser during development at `locahost:8000/__groq` **(TO DO)**
- Optimized for incremental builds on Cloud and OSS **(TO DO)**
Expand Down Expand Up @@ -69,7 +69,7 @@ export function() {
```
5. For more flexibility and advanced usage check out [Fragments](#fragments)

**NOTE: If using joins, please see [limitations](#joins)**
**NOTE: If using joins, please see [notes on joins](#joins)**

## 🤔 What is This? <a name="introduction"></a>
Gatsby is an amazing tool that has helped advance modern web development in significant ways. While many love it for its magical frontend concoction of static generation and rehydration via React, easy routing, smart prefetching, image rendering, etc., one of the key areas where it stands out from other similar tools is its GraphQL data layer. This feature is a large part of why some developers love Gatsby and why others choose to go in another direction. Being able to source data from multiple APIs, files, etc. and compile them altogether into a queryable GraphQL layer is ***amazing***, but many developers simply don't enjoy working with GraphQL. This is where GROQ comes in.
Expand Down Expand Up @@ -150,9 +150,33 @@ To use GROQ fragments with this plugin, for now all fragments must be exported f

## 🤦 Limitations
### Joins <a name="joins"></a>
Apart from references to assets such as images within Sanity datasets, the shorthand join syntax using the `->` operator is not supported. This is primarily related to the GROQ js client but may change in the future. Until then use the "Other Joins" syntaxes as documented [here](https://www.sanity.io/docs/groq-joins).
The ability to join multiple documents and retrieve their fields is a popular feature of GROQ. More testing needs to be done, but currently most join syntaxes are supported other than the `references()` function.

Here is an example needing to match a `_ref` found within an array of objects: https://groq.dev/oLIs5ABtnM0xrG9aSSJBYg
For Sanity users, if using the `->` operator you will need to append `._ref` to the field which contains the reference. So with a Sanity dataset, the usual
`referenceField->{ ... }` would instead look like this: `referenceField._ref->{ ... }`. Likewise for arrays: `arrayOfReferences[]._ref->{ ... }`. If you are only using Sanity data within your Gatsby project and would like to use the regular syntax, within the plugin options set `autoRefs: true` and you won't have to worry about appending the extra field.

### Other usage with gatsby-source-sanity
For every `_ref` field within your documents the source plugin injects the referenced document's GraphQL node id instead of its default `_id` value. This means that whenever you are trying to match `_ref` values to documents you need to use the `id` field instead of `_id`.

So instead of what you are used to:
```
{
...,
"document: *[ _id == ^._ref ] {
...
}[0]
}
```
You would use this:
```
{
...,
"document: *[ id == ^._ref ] {
...
}[0]
}
```
If you are using the source plugin and running issues into issues with your joins, if all else fails try double checking your queries and make sure you are matching every `_ref` to the actual node `id`.


## ⌛ TO DO (random order)
Expand Down
5 changes: 2 additions & 3 deletions index.js
Original file line number Diff line number Diff line change
Expand Up @@ -105,19 +105,18 @@ function processJoins( query ) {
const search = `\\S+->\\w*`;
const regex = /\S+->\w*/gm;


for( let match of regex.exec( processedQuery ) ) {

let field = match.replace( '->', '' );
let replace = null;

// Single refs.
if( ! field.includes( '[]' ) ) {
replace = `*[ ${matchField} == ${field}${refOption} ][0]`;
replace = `*[ ${matchField} == ^.${field}${refOption} ][0]`;
}
// Arrays.
else {
replace = `*[ ${matchField} in ${field}${refOption} ]`;
replace = `*[ ${matchField} in ^.${field}${refOption} ]`;
}

processedQuery = processedQuery.replace( match, replace );
Expand Down

0 comments on commit a6c31b8

Please sign in to comment.