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

TypeScript Support branch #223

Merged
merged 50 commits into from
Jan 26, 2022
Merged

TypeScript Support branch #223

merged 50 commits into from
Jan 26, 2022

Conversation

tarrball
Copy link

@nukemandan This PR migrates the template over to TypeScript (addressing issue #205).

Couple issues of note:

  • Some types are added as any to make the linter/compiler happy. It would be nice to clean these up and make the TS config more strict, but that will be a larger time investment.
  • TS(X) filenames now begin with a lowercase letter to match TS conventions (but could be swapped back to beginning with an uppercase letter if desired).
  • Spacing within curly brackets in React templates seemed to have some inconsistencies, so I went with the lint rule of "always" adding spaces in curly brackets. This could be turned off. I don't care, as long as it's consistent.

@tarrball tarrball mentioned this pull request Dec 26, 2021
@KiChjang
Copy link

Great work so far in getting the codebase to compile under TypeScript! As you did note, most of the important arguments and parameters are lacking proper typing, and as such we're not really leveraging the most out of TypeScript yet. Do you plan to work on typifying those in this PR?

@tarrball
Copy link
Author

@KiChjang completely agree. I am certainly willing to work on adding proper types in this PR.

Great work so far in getting the codebase to compile under TypeScript! As you did note, most of the important arguments and parameters are lacking proper typing, and as such we're not really leveraging the most out of TypeScript yet. Do you plan to work on typifying those in this PR?

@KiChjang
Copy link

Hmm... on second thought, it may be better to open a new PR just for the typings, as the current PR already has quite a lot of lines changed, and would increase the review burden. I certainly would want to have your PRs reviewed and merged ASAP, so perhaps this is the better way.

@kamikazebr
Copy link

Need more review or you will take that @KiChjang? Let me know.

src/interactor.tsx Outdated Show resolved Hide resolved
src/nodeInfo.tsx Outdated Show resolved Hide resolved
@@ -111,9 +111,9 @@ const loadAccounts = (state, dispatch) => {
asyncLoadAccounts();
};

const SubstrateContext = React.createContext();
const SubstrateContext = React.createContext(undefined);

Choose a reason for hiding this comment

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

Does the compiler complain if you leave out the undefined parameter?

Copy link
Author

@tarrball tarrball Dec 28, 2021

Choose a reason for hiding this comment

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

Yes, React.createContext() requires 1 parameter (a default value). So passing in undefined here should have the exact same behavior, as I understand it.

const [currentValue, setCurrentValue] = useState(0);
const [formValue, setFormValue] = useState(0);
const [currentValue, setCurrentValue] = useState('0');
const [formValue, setFormValue] = useState('0');

Choose a reason for hiding this comment

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

I suspect TypeScript isn't happy about the state being both a string and a number, hence why you had to change the argument to a '0', correct?

Copy link
Author

@tarrball tarrball Dec 28, 2021

Choose a reason for hiding this comment

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

That is correct

@KiChjang
Copy link

@kamikazebr I appreciate the volunteering! I've been writing Rust for a while, so my knowledge of the TypeScript setup is a little rusty (no pun intended). As far as I remember, one can configure TypeScript compiler to operate in many ways, such as compiling first to JS via babel to achieve browser compatibility, or use TS files directly to serve pages. I haven't really figured out what the best strategy to use yet, so perhaps you could review that part and offer your opinions.

I'd also like to ask other maintainers like @nukemandan and see what they prefer for the TS compilation strategy.

@wirednkod
Copy link
Collaborator

Okay, that makes sense. I think I'm just confused about this branch (tarrball:main) and how it fits in with the new branch you created (ts/main). Are you suggesting scrapping this PR and starting new branches off ts/main to work on the migration more iteratively going forward?

@jimmychu0807 created the PR. The idea of having 1 PR that smaller ones will be point to is good, but not sure if it is mandatory.

* Remove the traces on custom type and update to based on Node v16

* webpack 5 migration

* Rm eslint related dev-dependencies & use URLSearchParams over querystring

* Updated to the latest polkadot-js libs

* Integrate with prettier

* Friendlier connection failure message.

* Refactored current selected account into SubstrateContext

* bugfix

* Fix console warning

* Update README

* Update to solve a yarn berry issue
@jimmychu0807
Copy link
Owner

jimmychu0807 commented Jan 20, 2022

@tarrball yes. I mean to retarget the PR to ts/main branch. Then this branch can be improved iteratively for a period of time (thinking of within a month of time) and doesn't have to get everything right at first, such as getting all the types right, before get merged into this "feature branch". Then this feature branch will eventually be merged into main.

@wirednkod @kamikazebr maintaining both js and ts is not my intention as well. As mentioned above, we probably maintain BOTH branches only for a short period of time, say a month or less, and then once the ts version got tested and stablized, it will be merge into main.

For maintenance, I suggest that for those prefer js, they can download the monthly-2022-01 tagged version or go back the git history and use this version of FE templ. I foresee by monthly-2022-03 (if not earlier), FE template will likely switch to ts.


Btw, I made an improvement in the PR #225 that the currentAccount got moved into the SubstrateContext also. So the selected account can be retrieved from the context and doesn't have to be passed around. There are multiple misc fixes also, thus the code conflicts arised.

@tarrball tarrball changed the base branch from main to ts/main January 20, 2022 22:58
@tarrball
Copy link
Author

Merged in updates from #225 & resolved conflicts. There's still some issues building TypeScript with the newly added react-app-rewired package from that PR to work through.

@jimmychu0807 jimmychu0807 merged commit d57b8b3 into jimmychu0807:ts/main Jan 26, 2022
@jimmychu0807
Copy link
Owner

@tarrball thank you for the effort of translating the project to ts version. The code is merged to ts/main.

@sebastiendan
Copy link

The project is not building for me on the ts/main branch:

$ yarn build

Failed to compile.

Module not found: Error: Can't resolve './App' in '/path/to/substrate-frontend-template/src'

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.

7 participants