symbol breaks on pass-through colocation about relay-compiler-language-typescript HOT 14 CLOSED

Hey, thanks for the kind words!

Would it be possible for you to provide a failing example app or a failing test in this repo?

from relay-compiler-language-typescript.

I think the example app in this repo should suffice. Both errors have the same root cause, which requires casting the object you're passing down to the type that the child expects.

from relay-compiler-language-typescript.

Is the sole issue here around manually passing data into a component that would normally be fetched by Relay?

from relay-compiler-language-typescript.

nope, just check out the example todo app in this repo & you'll see the typescript errors

from relay-compiler-language-typescript.

Ohhh, thanks for making me look twice at the example app. I was not seeing the type errors show up because of a local issue. I have fixed them, it was largely that I hadn’t upgraded @types/react-relay and @types/relay-runtime, which I’ve fixed in #62. Could it be that this is the cause for you?

Just yesterday did I surface those peer dependencies 77ba776 as well, so that should hopefully make this cause more clear in the future.

from relay-compiler-language-typescript.

@mattkrick Can you see if outdated DT typings might have been the problem in your case?

Regarding having to cast manually created data due to the unique symbol, while I agree it’s a bit of a nuisance, I think that type checking the fragment references and not having to cast them in your component code is preferable over having to cast in tests/stories.

I did file this issue which, if resulting in us getting a way to emit types for a full tree, could aid in these situations.

from relay-compiler-language-typescript.

Hey @alloy looks good!
The only thing it didn't fix in my app was handling for passthrough components.

Let's say I have a presentational component sandwiched in between 2 fragment containers. The presentational component passes down the viewer prop like it's a black box.

For example App has a presentational child called Foo, which has a container child Bar.
Here's a repro:
master...mattkrick:passthrough-component-test

The error I get is:

Error:(12, 25) TS2322: Type '{ children?: ReactNode; viewer: TodoListBar_viewer; }' is not assignable to type 'IntrinsicAttributes & MappedFragmentProps<Pick<Props, "viewer">> & ComponentRef & { children?: Re...'.
  Type '{ children?: ReactNode; viewer: TodoListBar_viewer; }' is not assignable to type 'MappedFragmentProps<Pick<Props, "viewer">>'.
    Types of property 'viewer' are incompatible.
      Type 'TodoListBar_viewer' is not assignable to type '_FragmentRefs<symbol>'.
        Property '" $fragmentRefs"' is missing in type 'TodoListBar_viewer'.

It's easy enough to just make the passhtrough component prop have an any type, but the fragment symbol is the only thing stopping it from being a little more expressive.

from relay-compiler-language-typescript.

@mattkrick You need to type up TodoListFoo differently. The viewer prop here needs to be typed to TodoApp_viewer. When you don't have Relay containers in between the mix the prop types don't change when you pass the data through components (remember, it really is just data objects). What makes this work in practice is the higher order component you create when calling create{Fragment,Refetch,Pagination}Container is remapping the data for you.

Does this make sense?

from relay-compiler-language-typescript.

Ah that's good! So the presentational component is more closely related to the parent type instead of the child type. I like it.

one caveat, let's say the parent doesn't have that fragment:

fragment App_viewer on User {
  viewer {
    todo {
      ...Bar_todo
    }
  }
}

// in App.ts
<Foo todo={viewer.todo}/>

in this case, the prop type should be App_viewer["todo"]? (if there's a cleaner way to grab subtypes, lemme know!)

from relay-compiler-language-typescript.

@mattkrick That is correct. Regarding the "cleaner" way of grabbing subtypes, we actually have a different discussion on this in #64.

Personally I think a cleaner way would be great, but I think we need to track that in the official relay repository (I think @alloy might already have created an issue to discuss it) - such that we can have the same features between the Flow and TypeScript implementations. As of right now we have tried to mirror the Flow features 1:1 and haven't attempted at making Relay with TypeScript any different than Relay with Flow. This is something I feel we should continue to maintain - in this way we don't need any special documentation other than setup and guidelines - which is obviously an area we still need to improve on.

from relay-compiler-language-typescript.

ah, works for me.
one last hurdle while trying this out-- what if the type in the parent is a list? that list gets converted into a ReadonlyArray with an unnamed generic, so there's nothing to grab.

fragment App_viewer on User {
  viewer {
    todos {
      ...Bar_todo
    }
  }
}

// in App.ts#render
return viewer.todos.map((todo) => <Foo todo={todo}/>)

in this case, what type should I use for todo in the Foo passthrough component?

from relay-compiler-language-typescript.

Does App_viewer[“viewer”][“todos”][0] work for your case?

from relay-compiler-language-typescript.

😮 ...i had no idea i could do that!

yep, that shuts me up. thanks for all your support!

from relay-compiler-language-typescript.

Hah, yeah it isn’t intuitive. Until you realise that indexed subscripting also allows for referencing specific elements in a tuple type.

Glad to hear you’re all set now, though!

from relay-compiler-language-typescript.