Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: a way to avoid certain references #25

Open
Leksat opened this issue Jan 18, 2021 · 4 comments
Open

Feat: a way to avoid certain references #25

Leksat opened this issue Jan 18, 2021 · 4 comments

Comments

@Leksat
Copy link
Contributor

Leksat commented Jan 18, 2021

Problem/Motivation

I was experimenting with Drupal. In most cases the toolkit was just working, which is super cool. Thanks for the great work!

Now I met the first issue when tried to add content translation support. In Drupal, content translations aren't separate entities, they don't have own IDs, just language codes differ. The idea was to fetch all translations of a Drupal entity into a single Gatsby node. However, in Drupal schema, a content entity and it's translations have the same GraphQL type.

Probably better to explain with screenshots :)

Here is my original fragment:
Screenshot_2021-01-14_at_17_21_28

Both entities and entityTranslations fields have [NodeArticle] type. The toolkit's sees the entityTranslations type and replaces the original fields with a reference. This leads to two things:

  1. entityTranslations field's sub-fields are moved to entities field.
  2. Content translations are fetched with separate NODE_ queries. Drupal serve all of them in the default language.

Screenshot_2021-01-14_at_17_18_29

Proposed resolution

Add something like @noReference directive:

fragment NodeArticle on NodeArticle {
  entityId
  entityTranslations @noReference {
    entityLabel
    body {
      summaryProcessed
      processed
    }
    fieldTags {
      entity {
        ...TaxonomyTermTags
      }
    }
    fieldImage {
      entity {
        ...MediaImage
      }
    }
  }
}

Does this proposal sound good?

@Leksat
Copy link
Contributor Author

Leksat commented Jan 18, 2021

I tried to make my idea to work, but it looks like it's too much of work. And the result would look like a hack (in comparison with the current toolkit code).

I think it should be easier for me to adjust the Drupal's schema. I mean switch to GraphQL module version 4 and write custom schema/resolvers.

@vladar
Copy link
Contributor

vladar commented Jan 28, 2021

Hey, I did a draft of the drupal sourcing using the toolkit here: https://github.com/vladar/gatsby-source-drupal-graphql

But it does create a separate node for each translation using a fragment like this for id:

fragment MyIdFragment on SomeDrupalType {
  __typename
  entityId
  entityLanguage {
    id
  }
}

@Leksat
Copy link
Contributor Author

Leksat commented Jan 28, 2021

Oh! I thought that the ID fragment should have __typename plus one ID field. Didn't know that multiple ID fields are allowed. Looks like I misread the docs 🤦
Thanks for the hint!

So I guess this issue can be closed?

BTW, we switched our Drupal Gatsby Toolkit prototype to GraphQL module version 4. And we won't go back to v3 🙂 Here is why: https://github.com/AmazeeLabs/silverback-mono/tree/development/apps/silverback-drupal#why-not-version-3-of-drupal-graphql-module

@vladar
Copy link
Contributor

vladar commented Jan 28, 2021

We had to update the toolkit to support nested fields in id fragments (as it turned out to be useful). You can use as many fields as needed for gatsby ids.

But keep in mind that for "delta sourcing" you will need to provide all of the id fields and a proper NODE_ query to re-fetch individual translations.

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

No branches or pull requests

2 participants