@kassens first up, thanks a lot for generating Flow types in relay-compiler! It's extremely useful and already I've been able to tightened up my GraphQL schema based on frontend types and vice versa. :heart:
Here's the context for a suggestion. In my app, relay-compiler generates the following Flow types:
export type BondInformation_node = {|
+id: string;
+customs_bond: ?{|
+id: string;
+client_id: string;
+bond_number: ?string;
// other stuff elided
|};
|};
Note the nullability on customs_bond. That type is correct, but it's a little bit annoying. I'd prefer it to generate:
export type BondInformation_node_CustomsBond = {|
+id: string;
+client_id: string;
+bond_number: ?string;
// other stuff elided
|};
export type BondInformation_node = {|
+id: string;
+customs_bond: ?BondInformation_node_CustomsBond;
|};
The rationale for this is that I want to use the type BondInformation_node_CustomsBond in my React component, but I don't want to bring along the nullability. Right now the best I could figure out is
type BondInformation_node_CustomsBond = $PropertyType<BondInformation_node, 'customs_bond'>;
But that isn't ideal because it brings along nullability. Maybe this is a Flow suggestion and there should be a way to "unwrap" the type like $UnwrapMaybe<$PropertyType<BondInformation_node, 'customs_bond'>>. But I wouldn't need to do that if relay-compiler generated types a little differently.
EDIT: In https://github.com/facebook/flow/issues/4306 I learned that I can do $NonMaybeType<$PropertyType<BondInformation_node, 'customs_bond'>> to get the type I want. I guess you could keep this issue open if you think it's worthwhile to decompose the generated type, but now that I know I can do it with Flow I'd also be happy to close it.
Yeah, you could use $NonMaybeType
Not generating nested object type is intended -- we used to generate them. We might consider having a directive that indicate you would like to generate flow type for the specific nested object.
Maybe I am overlooking something, but what's the point in generating Flow types, which has to be retyped? What does Facebook do?
type Edges = $NonMaybeType<$PropertyType<AllPosts_viewer, 'edges'>>
type Node = $NonMaybeType<Edges, 'node'>>??
Or check everything nullable in React component? 馃
OK. It's because schema migrations as somewhere explained. Permissions can fail, whatever can happen better stale than dead.
Generating the names for decomposed flow types is not easy as there are some scenarios where a pattern like BondInformation_node_CustomsBond would conflict. Generally, I would like to get to a point where you don't have to look at the generated files and have them be an implementation detail.
For helper functions in the same module, it's often not needed to type them as flow just infers the type. If you pass across module boundaries, it's frequently a better idea to have the other module boundaries be their own Relay containers. I realize we're not covering 100% here, but I'm looking were we can push this and slowly refine our documentation and recommendations around this.
For helper functions in the same module, it's often not needed to type them as flow just infers the type.
A lot of our helper functions have annotated types, so we need to import the types for that. Arguably we could have Flow infer those, I guess. But that would make Relay opinionated about how you use Flow.
Also, we explicitly type the inner React component too. If I omit that, will Flow tell me when I use a nullable Relay-derived prop without checking that it exists? Because it's super useful to connect Flow types to the backend schema. If this connection happened automatically that'd be amazing. Probably that what you're referring to with "I would like to get to a point where you don't have to look at the generated files and have them be an implementation detail"?
Most helpful comment
Maybe I am overlooking something, but what's the point in generating Flow types, which has to be retyped? What does Facebook do?
Or check everything nullable in React component? 馃