Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add typescript support to issue-tracker #122

Open
wants to merge 37 commits into
base: main
Choose a base branch
from

Conversation

renanmav
Copy link

@renanmav renanmav commented Nov 12, 2019

As talked with @jstejada, @josephsavona and @ksaldana1, we would like to add typescript support to issue-tracker example.

And here it is.

Just a minor problem. When we add the Concurrent mode like this, the Root.tsx component with header isn't rendered anymore. To be honest, I don't know why this is happening. Any help?

@facebook-github-bot
Copy link

Hi renanmav! Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file.In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

Copy link
Contributor

@josephsavona josephsavona left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for working on this! I think this could really help folks understand the code. The overall theme of my feedback is to keep the changes focused on adding TypeScript support: please revert arbitrary naming, content, and formatting changes.

issue-tracker/src/Root.tsx Show resolved Hide resolved
issue-tracker/src/routing/Link.tsx Outdated Show resolved Hide resolved
issue-tracker/src/routing/Link.tsx Outdated Show resolved Hide resolved
issue-tracker/src/routing/RouteRenderer.tsx Outdated Show resolved Hide resolved
issue-tracker/src/routing/RouteRenderer.tsx Outdated Show resolved Hide resolved
issue-tracker/src/IssueListItem.tsx Outdated Show resolved Hide resolved
issue-tracker/src/IssueDetailRoot.tsx Outdated Show resolved Hide resolved
issue-tracker/src/IssueDetailComments.tsx Outdated Show resolved Hide resolved
issue-tracker/src/IssueActions.tsx Outdated Show resolved Hide resolved
issue-tracker/.eslintrc Outdated Show resolved Hide resolved
issue-tracker/.prettierrc Outdated Show resolved Hide resolved
Copy link
Contributor

@josephsavona josephsavona left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks for the updates! There's still a few things around the types and extraneous changes - also looks your editor really wants to automatically "correct" the capitalization in "GitHub" for some reason!

issue-tracker/src/IssueActions.tsx Outdated Show resolved Hide resolved
issue-tracker/src/IssueDetailComments.tsx Outdated Show resolved Hide resolved
issue-tracker/src/IssueDetailRoot.tsx Outdated Show resolved Hide resolved
issue-tracker/src/Issues.tsx Outdated Show resolved Hide resolved
issue-tracker/src/JSResource.ts Outdated Show resolved Hide resolved
issue-tracker/src/JSResource.ts Outdated Show resolved Hide resolved

export default function Root(props) {
const Root = (props: Props) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious, why the change here?

Copy link

@ksaldana1 ksaldana1 Nov 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tangentially related—usually when declaring functional components in TypeScript, I tend to use const declarations with a React.FC<Props> generic type annotation. This both enforces the return type of your function, as well as correctly typing the Props interface. This current definition is actually a bit misleading—with the way this is declared you will not have a children prop. This may not matter now, but it becomes annoying the second you want to add it. Using React.FC will add those additional properties for you on top of your generic argument.

const Root: React.FC<Props> = (props) => {} // props is typed with our generic + children

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've also come across that medium article once, and even if some of the tips are useful, I'd still go with the official way of typing react functional components, like most people are used to, with React.FC<Props> just like @ksaldana1 suggested.

issue-tracker/src/routing/RouteRenderer.tsx Outdated Show resolved Hide resolved
issue-tracker/src/routing/createRouter.ts Outdated Show resolved Hide resolved
issue-tracker/src/routing/createRouter.ts Outdated Show resolved Hide resolved
@renanmav
Copy link
Author

I'm sorry about all the unnecessary changes. This was a study that became this PR.

Copy link
Contributor

@josephsavona josephsavona left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So close!

issue-tracker/src/routing/RouteRenderer.tsx Outdated Show resolved Hide resolved
issue-tracker/src/routes.ts Outdated Show resolved Hide resolved
exact?: boolean;
strict?: boolean;
component: Resource<any>;
prepare: (params: {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's not dead necessary for this example, but how about making prepare optional, so we can use the router for non-relay routes also?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you, but a comment made by @josephsavona:

this could be non-optional


/**
* An alternative to react-router's Link component that works with
* our custom RoutingContext.
*/
export default function Link(props) {
const Link: React.FC<Props> = props => {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for not destructuring the props eg. const Link: React.FC<Props> = ({ children, to }) => {}? Same with all other instaces of React.FC

Also children is already defined by the FC type, so no reason to define it again in Props interface.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These destructures are really necessary? I think that they add an unnecessary complexity.


no reason to define it again

Thanks!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't destructing props in functional components the standard? How is this complexity? If you did that you could remove 8 unnecessary props. just in that component.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but I would add 8 unnecessary new lines to destructure. I'd have 16 lines between destructuring and usage against 8 lines with actual strategy.

In fact, using props.<propName> enforces that this data comes as props.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So... I guess this is pretty basic stuff but...
Changing const Link: React.FC<Props> = props => {} to const Link: React.FC<Props> = ({ children, to }) => {} means that, in just that Link component, you can remove props. from 7 instances of props.to and 1 instance of props. from props.children... how is this adding complexity to you... or 16 new lines. If anything it reduces redundancy (or what am I not seeing here?)

Sorry, what you say makes no sense to me. Thought everyone was doing it since ES2015. Maybe read this.

@renanmav
Copy link
Author

I think we are ready @josephsavona @jstejada

@josephsavona
Copy link
Contributor

josephsavona commented Nov 25, 2019

@renanmav Awesome, thank you again for your contributions. I'll check this out locally and experiment a bit and may make a few minor tweaks before landing, but this looks great.

EDIT: With the combination of holidays and some personal/family issues I didn't get a chance to follow-up on this, my apologies.

@PatoBeltran
Copy link

I'm interested in seeing this working too, let me know if there's any work to be done so I can jump in

@jgcmarins
Copy link

What's missing for this one to be merged?

@daig
Copy link

daig commented Mar 27, 2020

Ahhhh everything in this repo seems abandoned :/

@jgcmarins
Copy link

Hi @daig,
We've been using the same code from issue-tracker in production with suspense and preloadQuery and everything works just fine. Nothing abandoned here.
You can follow @sibelius Live for React Europe as well. It follows the exact same implementation used by issue-tracker.

@josephsavona
Copy link
Contributor

josephsavona commented Mar 27, 2020

Just noting that we haven't added many changes here because the example is flushed out and complete. We fully intend to keep this example up-to-date as our APIs evolve, but so far that hasn't warranted any changes because these APIs are now fairly stable.

TypeScript support - this PR - would certainly be nice to have, but I already spent a lot of time reviewing this and simply ran out of steam. This PR is probably going to have to wait until I or someone else on the team have enough free personal time to review again, make edits, and land.

@sorenhoyer
Copy link

sorenhoyer commented Mar 27, 2020

There are still many things that could be improved so good that you did not merge it yet. It makes somewhat sense to make this pr overwrite the existing js code during development to document the changes/diffs. But may I suggest to keep both a js and ts version by making one final commit where the folder is renamed to something like issue-tracker-ts or moved to a ts and then bring back the js version - after this PR is in a good state and approved of course.

@sibelius
Copy link
Contributor

what about keep here Flow examples, and create https://github.com/relay-tools/relay-examples-typescript?

so we can move faster and iterate more there, as relay team is not using typescript

@josephsavona
Copy link
Contributor

A separate repo for the TS version makes a lot of sense. Please post back here as you make progress, so that we can take a look and provide feedback, and also add a link to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants