Skip to content

Releases: muuki88/sbt-graphql

v0.16.0

25 Jan 08:14
37d62dd
Compare
Choose a tag to compare

Added codeGen directive #93

Added a codeGen directive that is erased during source code generation and
can be used to customize the generated code.

Example - skip code generation

To skip the code generation and provide your own type.

query CodeGenHeroNameQuery {
  hero @codeGen(useType: "Hero") {
    name
  }
}

You can also use the fully qualified class name to avoid clashes

query CodeGenHeroNameQuery {
  hero @codeGen(useType: "com.example.model.Hero") {
    name
  }
}

v0.15.0

25 Jan 07:42
fcd5727
Compare
Choose a tag to compare

Update sangria to 2.0.0-RC1 and misc updates / fixes (#87)

  • Update sangria to 2.0.0-RC1 and misc updates / fixes

  • Fixed the doubled escape sign $ while generating the source

v0.13.0 Remove jawn dependency

15 Jul 07:51
Compare
Choose a tag to compare

#72 - Update circe to 0.11.1 while replacing jawn with jackson

Thanks to @felixbr we are able to run with newer sbt versions without having jawn version conflicts.

0.10.1 release

17 Sep 19:10
v0.10.1
Compare
Choose a tag to compare

v0.10.1 (2018-09-17)

Full Changelog

Closed issues:

  • Implement magic #import like apollo-graphql #48

Merged pull requests:

  • Update scalameta to 4.0.0 RC1 #53 (ngbinh)
  • Update sangria and cats dependencies #52 (ngbinh)
  • Use cats to make some of the document wrangling a bit simpler #51 (felixbr)

Version 0.10.0 - Magic Imports

12 Sep 16:12
ec8f1aa
Compare
Choose a tag to compare

Magic #imports

Fix #48 / PR #50

This is a feature tries to replicate the apollographql/graphql-tag loader.js
feature, which enables including (or actually inlining) partials into a graphql query with magic comments.

Explained

The syntax is straightforward

#import path/to/included.fragment.graphql

The fragment files should be named liked this

<name>.fragment.graphql

There is a excludeFilter in graphqlCodegen, which removes them from code generation so they are just used for inlining
and interface generation.

The resolving of paths works like this

  • The path is resolved by checking all sourceDirectories in graphqlCodegen for the given path
  • No relative paths like ./foo.fragment.graphql are supported
  • Imports are resolved recursively. This means you can #import fragments in a fragment.

Example

I have a file CharacterInfo.fragment.graphql which contains only a single fragment

fragment CharacterInfo on Character {
    name
}

And the actual graphql query file

query HeroFragmentQuery {
  hero {
    ...CharacterInfo
  }
  human(id: "Lea") {
    homePlanet
    ...CharacterInfo
  }
}

#import fragments/CharacterInfo.fragment.graphql

Version 0.9.1

29 Aug 12:58
6203fa7
Compare
Choose a tag to compare

Add additional imports to generated Interfaces.scala

Version 0.9.0

10 Aug 09:57
6203fa7
Compare
Choose a tag to compare

Interfaces & types

Pull Request: #45

The ApolloSourceGenerator now generates an additional file Interfaces.scala with the following shape:

object types {
   // contains all defined types like enums and aliases
}
// all used fragments and interfaces are generated as traits here

We generate the types, aliases and interfaces by

  1. Merging all graphql documents into a single one. Sangria takes care of fragment deduplication. The behaviour when a fragment has the same name but different contents is at the moment unspecified.
  2. From the "master document" we generate all interfaces, types and aliases that are actually used
  3. We import types._ in all generated code. The interfaces are already in the package scope. so no additional import is required

Use case

Share common business logic around a fragment that shouldn't be a directive

You can now do this by defining a fragment and include it in every query that
requires to apply this logic. sbt-graphql will generate the common trait?,
all generated case classes will extend this fragment trait.

Limitations

You need to copy the fragments into every graphql query that should use it.
If you have a lot of queries that reuse the fragment and you want to apply changes,
this is cumbersome.

You cannot nest fragments. The code generation isn't capable of naming the nested data structure. This means that you need create fragments for every nesting.

Invalid

query HeroNestedFragmentQuery {
  hero {
    ...CharacterInfo
  }
  human(id: "Lea") {
    ...CharacterInfo
  }
}

# This will generate code that may compile, but is not usable
fragment CharacterInfo on Character {
    name
     friends {
        name
    }
}

correct

query HeroNestedFragmentQuery {
  hero {
    ...CharacterInfo
  }
  human(id: "Lea") {
    ...CharacterInfo
  }
}

# create a fragment for the nested query
fragment CharacterFriends on Character {
    name
}

fragment CharacterInfo on Character {
    name
    friends {
        ...CharacterFriends
    }
}

Version 0.8.1

26 Jul 08:21
4d96cfb
Compare
Choose a tag to compare
  • #43 Remove unnecessary type in GraphQLQuery trait
  • #41 Add withPost() to IntrospectionSchemaLoader to send post instead of get requests

Thanks @felixbr for all the input and work ❤️

Version 0.8.0

24 Jul 16:09
41c556c
Compare
Choose a tag to compare

JSON data decoder

#40 adds a decoder for the top level Data type. Before the circe decoder chain was incomplete.

document val in GraphQLQuery trait

#37 adds a document field to the GraphQLQuery trait for easier access to the raw document.

Remove redundant import

#39 fixes scalac linting error

User defined imports

#36 allows custom imports in every generated code

graphqlCodegenImports ++= Seq(
  "my.package._",
  "my.package.foo"
)

Version 0.7.0

23 Jul 15:57
Compare
Choose a tag to compare

Upgraded circe to 0.9.3