increased strictness of types #695

jbaxleyiii · 2017-05-07T16:06:12Z

This is a PR I'm super excited about. It should make typescript and flow users very happy! 🎉

Following the discussion in #394, this PR seeks to make adding types easy to the graphql HOC for both flow and typescript

Examples:

Typescript

Type query results and expect their values in the the wrapped component

Safely use the `options` function based on props passed to wrapped component

Safely build props based on result data, passed props, and what react-apollo passes down

Flow

Type query results and expect their values in the the wrapped component

Safely use the `options` function based on props passed to wrapped component

Safely build props based on result data, passed props, and what react-apollo passes down

Known flow issues

Options as a function or and object is not currently supported. With union types in flow, I couldn't get an interface with all optional params to be distinguishable from a callable arrow function which returns said interface. For now, only the function version is allowed.
Result data which could be null, is typed as existing. I tried to get result data being optional QueryProps & ?R but then I couldn't get flow to pass something like data.code && // use data.code. If you have any knowledge here I'd love it!

For the flow typings, we will need to move the AC ones to AC and do a release first. I'd love to do a tagged release with them bundled with the lib so they are automatic like typescript typings are. If it works (fingers crossed), we can do the same for RA.

I would love feedback from @helfer @ianks and @brettjurgens if they are willing. This is a breaking typescript change so I've bumped the minor version. I hope that works for people!

I'll probably play around with overloads for typescript to detect mutation / query / subscription. I'm not totally sure how to do that in flow.

If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
Make sure all of the significant new logic is covered by tests
Rebase your changes on master so that they can be merged easily
Make sure all tests and linter rules pass
Update CHANGELOG.md with your change

brettjurgens

nice 👍 some minor comments

brettjurgens · 2017-05-07T17:51:07Z

src/graphql.tsx

-}
-
-export default function graphql(
+export default function graphql<TResult = {}, TProps = {}, TChildProps = DefaultChildProps<TProps, TResult>>(


i think you'll need to bump typescript to 2.3 in package.json for the default generics

brettjurgens · 2017-05-07T17:51:47Z

src/graphql.tsx

@@ -142,7 +153,7 @@ export default function graphql(
    // However, this is an unlikely scenario.
    const recycler = new ObservableQueryRecycler();

-    class GraphQL extends Component<any, any> {
+    class GraphQL extends Component<TProps, any> {


not important, but can probably set state to {}

…merged

stubailo

This looks dope!

stubailo · 2017-05-08T06:19:20Z

Changelog.md

@@ -4,6 +4,9 @@ Expect active development and potentially significant breaking changes in the `0

 ### vNext

+### 1.4.0
+- Feature: Enhanced typescript definitions to allow for more valid type checking of graphql HOC


I think this will be a breaking change for TS devs, right? Might be worth a mention in the changelog.

@stubailo for sure! I'll add that and note it in the release as well

stubailo · 2017-05-08T06:19:58Z

src/graphql.tsx

+  mutate?: MutationFunc<TResult>;
+}
+
+export type DefaultChildProps<P, R> = P & { data?: QueryProps & R, mutate?: MutationFunc<R> };


Wow this is dope

right? I'm wondering if I setup some overloads if we can get it to correctly type mutation / query / subscription. Going to try my hand at it tonight

ianks · 2017-05-08T17:21:40Z

src/graphql.tsx

@@ -142,7 +157,7 @@ export default function graphql(
    // However, this is an unlikely scenario.
    const recycler = new ObservableQueryRecycler();

-    class GraphQL extends Component<any, any> {
+    class GraphQL extends Component<TProps, {}> {


nit, but I think void would be more appropriate for the type of State here.

ianks · 2017-05-08T17:23:59Z

src/graphql.tsx

+  skip?: boolean | ((props: any) => boolean);
+  name?: string;
+  withRef?: boolean;
+  shouldResubscribe?: (props: TProps, nextProps: TProps) => boolean;


Would props and nextProps not be optional here?

i.e.

{ //... shouldSubscribe: () => true //should be OK }

that should still be fine, they should only be optional if the call can pass the variables as undefined

interface Test { testFn (x: string, y: string): boolean; } let z: Test = { // this is fine testFn: () => true };

lewisf

I only took a look at the Flow typings but generally what are your thoughts about adding more specific constraints on the generics for things that are exported? It may help produce more useful errors when types don't line up in usage.

lewisf · 2017-05-08T23:24:47Z

index.flow.js

+  ): void;
+
+  declare export function getDataFromTree(
+    rootElement: any,


these are consistent with the ts types, but should these be React$Element<*>?

@lewisf yeah the server needs better typings all around, I'll update the PR for typescript and flow typings tonight for it

lewisf · 2017-05-08T23:34:35Z

index.flow.js

+    props: P
+  ) => QueryOptions | MutationOptions;
+
+  declare export interface OperationOption<TProps, TResult> {


it may be useful to give any exported things that use generics more specific types

interface OperationOption<TProps: {}, TResult: {}>

lewisf · 2017-05-08T23:36:31Z

index.flow.js

+
+  declare export interface OperationComponent<
+    TResult: mixed = {},
+    TOwnProps: mixed = {},


Does it make sense to do Object here instead of mixed?

brettjurgens · 2017-05-09T15:06:04Z

src/graphql.tsx

  error?: ApolloError;
  networkStatus: number;
  loading: boolean;
-  variables: {
+  variables?: {


i think this should not have the ? it looks like if there's no variables it's an empty object, not undefined

…apollo into types-rewrite

jbaxleyiii · 2017-05-10T03:11:25Z

This is ready to go for a first release in my opinion after apollographql/apollo-client#1688 is merged and released

helfer · 2017-05-12T04:12:13Z

This looks great! Let's get that PR on apollo-client merged! 🎉

jbaxleyiii · 2017-05-12T04:13:28Z

@helfer I'll have tests written for flow typings tomorrow so we can merge and release AC, then we can bump the version here, release, write a blog post, then 🎉

megamaddu · 2017-05-13T16:13:32Z

This looks great!

megamaddu · 2017-05-13T16:27:39Z

It looks like MutationOptions from react-apollo isn't getting exported because it's already re-exporting everything from apollo-client, which also defines MutationOptions. I was going to make a new issue but it might fit well with these related changes.

stubailo · 2017-05-29T20:43:15Z

@jbaxleyiii ping, any more news? Can I help?

jbaxleyiii · 2017-05-30T01:25:35Z

@stubailo I wanted to make sure I had the availability to support this release and apollographql/apollo-client#1688 with quick responsiveness after release so I held off until I was certain I could do that. 👍

I've updated the AC PR and will tweak this one next to make sure they are ready since I will be able to support the next few releases well!

jpshelley · 2017-06-06T19:03:35Z

@jbaxleyiii still trying to understand flow, but should types be committed to https://github.com/flowtype/flow-typed as well? So from the command line flow-typed install or flow-typed update can be ran?
My project still shows react-apollo as having flow type any for all its declarations.

dsifford · 2017-06-07T02:33:51Z

Perhaps I'm dense or am lacking sleep, but I can't get this change to work with a combination of decorators, React.PureComponent, and without typing any to the render method of this file:

https://github.com/aliemteam/aliemcards/blob/master/app/cards/Card.tsx

Has this PR been tested enough to merge? I only see a few situations of this being used in the associated test files and the changes are quite complex.

Any help here would be thoroughly appreciated.

Edit: Looks like all the decorator tests are wrapping components that are given the any type (example below). That doesn't seem safe.

@graphql(query)
class Container extends React.Component<any, any> {}

dsifford · 2017-06-07T16:22:58Z

Also, one other thing I suppose I should mention.

I'm using visual studio code. Until now, I've never had a situation where my editor freezes up and lags. Exclusively the new graphql types cause this to happen.

I appreciate the hard work, but IMHO, the types are too strict. Maybe we could work on a happy medium? I'd be happy to collaborate on a PR.

dsifford · 2017-06-07T16:35:06Z

@jbaxleyiii Just pulled the repo, did a yarn install, and opened ./test/react-web/client/graphql/queries/api.test.tsx without touching any code and I'm getting a similar error to what I got in the repo I linked to above.

Does this file work for you guys?

ianks · 2017-06-07T17:06:06Z

I appreciate the hard work, but IMHO, the types are too strict.

What does this mean exactly? The types should restrict invalid code, but allow valid code. Can you provide some examples of where this does not happen?

dsifford · 2017-06-07T17:28:57Z

@ianks Maybe a poor choice of words on my part. Strictness is a good thing, I agree. But the complexity of the generics in this PR don't appear to have been tested thoroughly enough. Also, I'm wondering what the added value of adding all this complexity brings to the table?

I admittedly have not used all the functionality of react-apollo, so I can't say with certainty that there isn't added value here, but what I can say is that the strictness I was able to get with the old types was perfectly fine for the features that I was using.

Also, the changes appear to have been crippling to the typescript language server due to how deeply dependent some of the generics are on each other. For example, just tracing the graphql generic quickly, I'm seeing at least 4 unions, 4-5 intersections, and 3-4 levels of sub-generics. It's a great showcase of Typescripts new generic defaults, but it cripples the typescript language server in visual studio code. Change one value inside the graphql function or change a type that is used somewhere in the generic chain, and the language server has to dive into all that complexity every single time to check.

I'm in no way trying to lessen the value of @jbaxleyiii's work on this PR, and really appreciate all the other work he's done, so please don't take this the wrong way. All I'm saying is that it appears that this change could warrant tests in a handful of different situations to make sure that all the added complexity added by these types has been thoroughly tested. Also, I'm wondering if there might be a way to break apart the length of the type dependency chain to make it less of a workload on the typescript language server for those of us who utilize it for real-time warnings (vscode users, for example).

Thanks for considering. Again, happy to help in any way if needed.

ianks · 2017-06-07T17:36:17Z

@dsifford what version of typescript are you on?

dsifford · 2017-06-07T17:40:42Z

@ianks Latest, stable in the project that I linked to above.

2.3.2 when I pulled this repo and opened up ./test/react-web/client/graphql/queries/api.test.tsx and noticed the errors in the screenshot above.

ianks · 2017-06-07T17:47:44Z

@dsifford can you make a minimal reproduction of this? essentially a dir with a yarn.lock and a file which causes this bug?

EDIT: Nevermind I see you provided a file for this

dsifford · 2017-06-07T17:54:38Z

Yep, I'd be glad to! I appreciate the hospitality 😄

Gotta run to class now though. Can we hold that thought until maybe tomorrow afternoon?

Also, just to confirm: You aren't able to reproduce the error in this repo that I'm seeing? If not, that's pretty strange... I'd feel pretty silly if this ended up being an issue with my system or something! 😖

alexzielenski · 2017-06-08T06:10:06Z

Same errors for me, I thought i was going insane trying to get these types to compile. Can confirm that a simple yarn install on this repo and viewing ./test/react-web/client/graphql/queries/api.test.tsx will yield these errors. On TS 2.3.2, 2.3.4 and 2.4.0

jbaxleyiii · 2017-06-12T14:48:24Z

@dsifford and @alexzielenski I'm hoping to take a look at your issues this week. Could you please open a new issue for tracking it?

dsifford · 2017-06-16T03:45:59Z

Sorry for the delay @jbaxleyiii! Just opened #786 for this. Thanks in advance! 😄

dav-ell · 2017-07-04T14:52:17Z

Does documentation exist for how to use this yet? Say, setting up an example project with all the type benefits described in the original post?

The post by @alexzielenski in #786 does a good job of explaining how to get something working, and could be used as a starting point for documentation.

I love what you guys are doing here! Thanks so much for all the hard work!

James Baxley added 2 commits May 7, 2017 12:00

increased strictness of typescript types

fa0e148

add mutation to default child props

e7be433

brettjurgens reviewed May 7, 2017

View reviewed changes

James Baxley added 3 commits May 7, 2017 15:06

lock ts version to greater than 2.3.0 and set state to be {}

6708871

fix lint error

14a08fb

lock jest to 19 for now

e652e08

jbaxleyiii changed the title ~~increased strictness of typescript types~~ increased strictness of types May 8, 2017

added flow typings! TODO remove AC typings after they are tested and …

e30b834

…merged

stubailo reviewed May 8, 2017

View reviewed changes

jbaxleyiii mentioned this pull request May 8, 2017

[WIP/Discussion] Enhance types #394

Closed

ianks reviewed May 8, 2017

View reviewed changes

lewisf reviewed May 8, 2017

View reviewed changes

jbaxleyiii self-assigned this May 9, 2017

Merge branch 'master' into types-rewrite

f7a5282

brettjurgens reviewed May 9, 2017

View reviewed changes

James Baxley added 3 commits May 9, 2017 21:45

more strict types for server code and a few flow tweaks

52811e8

Merge branch 'types-rewrite' of https://github.com/apollostack/react-…

658cb88

…apollo into types-rewrite

support bundled flow types

9ee0cc5

jbaxleyiii mentioned this pull request May 30, 2017

add initial flow typings for apollo-client apollographql/apollo-client#1688

Merged

1 task

change options name to fix AC collision and add flow smoke test

401f604

jbaxleyiii force-pushed the types-rewrite branch from 545241c to 401f604 Compare May 30, 2017 02:17

Merge branch 'master' into types-rewrite

a36c853

James Baxley added 2 commits May 29, 2017 22:24

lock RN versions

9bc9367

version bump uglify

e95593c

jbaxleyiii mentioned this pull request May 30, 2017

Update uglify-js to the latest version 🚀 #700

Closed

fix uglify command

eb4e0c0

jbaxleyiii mentioned this pull request May 30, 2017

Add support for client in options #729

Merged

6 tasks

Merge branch 'master' into types-rewrite

308316c

This was referenced May 30, 2017

Problems setting up local environment #717

Closed

MutationOptions typings conflict with 'apollo-client' package? #720

Closed

jbaxleyiii merged commit 7cc8d22 into master May 30, 2017

jbaxleyiii deleted the types-rewrite branch May 30, 2017 02:59

jbaxleyiii mentioned this pull request May 30, 2017

Type safe usage of @graphql in TypeScript projects #635

Closed

dsifford mentioned this pull request Jun 16, 2017

New TypeScript definitions broken + cause critical slowdowns of the language server #786

Closed

increased strictness of types #695

increased strictness of types #695

Conversation

jbaxleyiii commented May 7, 2017 • edited Loading

Typescript

Type query results and expect their values in the the wrapped component

Safely use the options function based on props passed to wrapped component

Safely build props based on result data, passed props, and what react-apollo passes down

Flow

Type query results and expect their values in the the wrapped component

Safely use the options function based on props passed to wrapped component

Safely build props based on result data, passed props, and what react-apollo passes down

Known flow issues

brettjurgens left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stubailo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianks May 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lewisf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbaxleyiii commented May 10, 2017

helfer commented May 12, 2017

jbaxleyiii commented May 12, 2017

megamaddu commented May 13, 2017

megamaddu commented May 13, 2017

stubailo commented May 29, 2017

jbaxleyiii commented May 30, 2017

jpshelley commented Jun 6, 2017

dsifford commented Jun 7, 2017 • edited Loading

dsifford commented Jun 7, 2017

dsifford commented Jun 7, 2017

ianks commented Jun 7, 2017 • edited Loading

dsifford commented Jun 7, 2017

ianks commented Jun 7, 2017

dsifford commented Jun 7, 2017

ianks commented Jun 7, 2017 • edited Loading

dsifford commented Jun 7, 2017

alexzielenski commented Jun 8, 2017 • edited Loading

jbaxleyiii commented Jun 12, 2017

dsifford commented Jun 16, 2017

dav-ell commented Jul 4, 2017 • edited Loading

jbaxleyiii commented May 7, 2017 •

edited

Loading

Safely use the `options` function based on props passed to wrapped component

Safely use the `options` function based on props passed to wrapped component

ianks May 8, 2017 •

edited

Loading

dsifford commented Jun 7, 2017 •

edited

Loading

ianks commented Jun 7, 2017 •

edited

Loading

ianks commented Jun 7, 2017 •

edited

Loading

alexzielenski commented Jun 8, 2017 •

edited

Loading

dav-ell commented Jul 4, 2017 •

edited

Loading