Improve Flow support

[mgtitimoli]

In order to improve flow support I have the following suggestions:

• Improve types generation
  • Using types spread is better than intersect types (using &), as the latter where there are property collisions the resulting type is the intersection of all the types of that particular prop (see here)
• Improve enum values generations
  • Cast entry values to their literal types to be able to use each of them independently as otherwise all of them are string (see this issue comment)
  • Introduce some config to customize their names (f.e. use camelCase instead of PascalCase + "Values") and their entry names (f.e. use camelCase instead of snake_case)

[dotansimha]

Thank you @mgtitimoli !

When we first added Flow support, it was very initial and our experience Flow was very basic.

You are right regarding the spread over intersect, and I think it will also resolve this issue: #1673

Regarding enums, we allow you now to customize the namingConvention and change the way to transform the enums values names.
Regarding the literal types, it could be very nice, we have a similar configuration for TypeScript plugins and it generates this kind of output.

I hope we'll have some time during this month to handle these, we are currently working on adding some core features (And we always welcome PRs 😉 ).

[matikrk]

Hi,
I started to work on improving flow support. Right now it generates code using spread operator.

Code working well for flow, but have problems for other libs. This edited code is in used also in other plugins.
@dotansimha I have a few questions:
It is possible to apply this code only inside flow plugin? Or could you help me manage it?

You can check changes here: https://github.com/matikrk/graphql-code-generator/pull/1

[dotansimha]

Hi @matikrk!
That sounds awesome! You can apply changes to the Flow plugin using the class FlowVisitor. The common logics are in BaseTypesVisitor, so if you need to add custom logic that applies only for flow, change/override methods in FlowVisitor.

Please let me know if you need more help with that!

[matikrk]

I've worked a bit on it and created 2 another version of this change:

• https://github.com/matikrk/graphql-code-generator/pull/2 - overwrite all classes - working, but have a lot copy paste
• https://github.com/matikrk/graphql-code-generator/pull/3 - combination of 1 and 2 - less copy paste, working like 2

---

version 3 now is working

[matikrk]

All types in flow use spread operator. All test passing and also works well on my other project.

@dotansimha If you could look on this PR https://github.com/matikrk/graphql-code-generator/pull/3 will be great

If you have suggestions about naming pls let me know.
If you want I could rename this isFlow/ _flow to something like flowSpreadSyntax and move it to config to add it as an option, but IMHO spread operator is better than &, less problems with flow

---

Final version is here #2569

[dotansimha]

The initial implementation of this change was in: #2569, thanks @matikrk !
I rebased and changed it a bit in order to match changes we recently introduced in terms of selections set transformations.

The final implementation is here: #2602

It will be available in the next release.

Thanks @mgtitimoli @matikrk

[mgtitimoli]

Hey there,

Before moving forward I want to apologize for not being so much into this.

I've checked the PR and I found 2 things that imo they should be addressed as the way they are now could create issues:

1. You can't use spread without exact, as if you do so, then the resulting object fields end up being optional.
2. I haven't check in depth the code, but there are references to $Pick and this is not included in Flow, there are some packages out there that offer this utility type, so if it is being used from some of these then it's ok, if not, then it's broken

[matikrk]

1. I forget about it, coz I use exact as default. @dotansimha It's should be added somehow or force exact
2. $Pick is somewhere defined, I'm sure it's is in the generated file.
   It's inside packages/plugins/flow/operations/src/index.ts:44

[dotansimha]

@matikrk I think we can set the default behaviour of Flow plugins to use the exact operators. It's an easy fix and shouldn't cause breaking changes.

$Pick is defined by us, like that:

type $Pick<Origin: Object, Keys: Object> = $ObjMapi<Keys, <Key>(k: Key) => $ElementType<Origin, Key>>;

Which allow use to pick multiple fields from a type, and create a new type out of it.

[mgtitimoli]

I use the same $Pick on my projects, nice!

One tricky thing about it is that when you use it, Keys object type also has to be exact, otherwise the resulting type won't be, and you would be in first case I described here.

type T0 = {|
  k0: string,
  k1: number
|};

type T1Inexact = $Pick<T0, {k1: any}>;

type T2Broken = {|...T1Inexact|};

type T1Exact = $Pick<T0, {|k1: any|}>;

type T2Fine = {|...T1Exact|};

[dotansimha]

Ohh I see. Thanks @mgtitimoli ! I'll do those fixes soon :)

[dotansimha]

@mgtitimoli Fixed in: #2613
Now exact operator is true by default, and also included in $Pick.

[dotansimha]

Fixed in 1.8.0 🚀