Implement newtype derive for scalars.

[theduke]

This commit implements a newtype style custom derive
for scalars via #[derive(GraphQLScalarValue)], which now
supports both deriving a base enum scalar type and newtypes.

For newtypes, the #[graphql(transparent)] attribute is
required.

This commit:

• implements the derive
• adds integration tests
• updates the book

Closes #303

[codecov-io]

Codecov Report

Merging #368 into master will decrease coverage by 0.36%.
The diff coverage is 33.04%.

@@            Coverage Diff             @@
##           master     #368      +/-   ##
==========================================
- Coverage   86.08%   85.72%   -0.37%     
==========================================
  Files         107      108       +1     
  Lines       15600    15710     +110     
==========================================
+ Hits        13429    13467      +38     
- Misses       2171     2243      +72

Impacted Files	Coverage Δ
juniper_codegen/src/lib.rs	2.12% <ø> (ø)	⬆️
...s/juniper_tests/src/codegen/derive_input_object.rs	64.17% <ø> (ø)	⬆️
juniper_codegen/src/derive_scalar_value.rs	0% <0%> (ø)	⬆️
...iper_tests/src/codegen/scalar_value_transparent.rs	92.68% <92.68%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a84dbf7...0268d03. Read the comment docs.

[theduke]

@LegNeato ping

[LegNeato]

I haven't looked at this super closely, but why would you ever not want transparent for a newtype?

Can we do it automatically for newtypes like serde does?

[theduke]

Serde requires the #[serde(transparent)] attribute.

Technically we could just do newtype for tuple structs with a single filed, but since we are reusing the macro for two different purposes I prefer to be explicit. It also gives some more clarity as to what's happening for the reader of the code, and it's analogous to serde and #[repr(transparent)].

[LegNeato]

But what about this from https://serde.rs/impl-serialize.html:

Data formats are encouraged to treat newtype structs as insignificant wrappers around the inner value, serializing just the inner value

And this link shows that the json serializer at least doesn't need serde(transparent):

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d9d970167e8550e808b153252eb89eaf

[theduke]

I always thought the #transparent attr was mandatory.
Turns out serde also supports [#transparent] with regular structs with only one field, and tuple structs with multiple fields but only one that's not skipped.

Not so sure if we'd want to support that.

[LegNeato]

I think we should mirror serde's behavior whenever possible...it's very ergonomic and battle-tested.

[LegNeato]

Any update on this? I need it for a project so happy to do the final tweaks if you don't have time.

[theduke]

I removed the requirement for the transparent attribute.

I would'nt support anything other than single field tuple structs for now though. Better to be conservative and reconsider once someone asks for it.

So should be good to merge.

[mwilliammyers]

Just to nitpick - should we take out #[graphql(transparent)] from the examples in the docs?