FAQ: TypeScript Support is Here!

[mikhael28]

Hey everyone!

Happy HacktoberFest! I've just now gone ahead and added in support for TypeScript in the ParetOS codebase! This is a great opportunity for the community to go through, and start refactoring components and really key in on tightening up the codebase. It's a great opportunity to reorganize our code, to do a better job of documenting the different data objects, and perhaps raising some flags (for example: x API field is no longer in use anywhere, should we deprecate that functionality in the API) based on that research.

Over the next few days, I will be writing up some tickets to begin refactoring certain components, utility functions and UI elements into TypeScript compatible code. A few things to note:

1. Please pull the latest code changes from main, and run yarn install to make sure you install all of the 'type' npm packages.
2. Read this if you don't know much about using React + TypeScript: https://github.com/typescript-cheatsheets/react#reacttypescript-cheatsheets
3. When doing work on a component/UI element, you may get an error saying 'this library doesn't have the proper types' and it will ask you to npm install a @types/nameof-library package from npm. That may be necessary, but after a short while - we should have all of these libraries installed, and not get that issue.
4. Regarding creating interface objects, for those objects that are re-used across multiple components, it makes sense to create an interface.js file and export those objects out to be used in a component by component basis. If we are just using an object shape for one particular component, create the interface before the functional component starts.
5. Install TypeScript dev tools in VS Code if you don't already have them - you may find they are very helpful for debugging, as I do.

I will update this announcement with more guidelines as they pop up, based on the open-source work we will be doing!

[akashshyamdev]

@mikhael28 I'd like to suggest a structure for our TS types:

1. Folder called types, which contain files for each entity we have, eg User. This would be for each collection in the DynamoDB Database
2. Each file should have an interface regarding the entity like IUser which has all the properties of the user
3. Apart from that, there can be other utility types regarding that.
4. Each React component should begin with an interface called ComponentNameProps, like ArenaProofModalProps which contains the props for the component.

This is what I follow on all my Typescript projects, let me know what you think. As for an example, here's a full TS repo I'm working on -

1. Example of a component - https://github.com/akashshyamdev/blockhub/blob/main/components/Button/Button.tsx
2. Exampe for types folder - https://github.com/akashshyamdev/blockhub/tree/main/types

Looking forward to hearing from you!

[mikhael28]

@akashshyamdev that directory structure sounds good, where we have a types folder that contains interfaces for the MAJOR object artifacts that we have, for example the User profile object, that we export and use across the repository. I don't like the idea of the I naming convention, where we add IUser to the names - I think that's confusing to newbies, who would be joining the repository. Let's keep the interface naming just User or Leaderboard or LeaderboardUser. The tricky thing will be making sure we avoid naming the interfaces along with the React components, so if that get's too difficult at some point - we will need to likely streamline our naming conventions.

In general, if we are using an Interface in only one component or container - let's leave it IN the component/container. This way, newbies to the project can more easily navigate things. Not everyone is used to using the VS Code auto-complete tools like a pro.

Regarding point number 4, I agree with this - but let's keep the ArenaComponentProps interfaces INSIDE their component as much as possible. Let's avoid making a bunch of different files/boilerplate if we can avoid it, and keep things simple for now.

Would you mind sending a PR in to establish the folder called types? Sorry for the delay, open source work is truly asynchronous.

[mikhael28]

@akashshyamdev how is everything going for you - you looking for work right now or already found it? I was wondering if you had a PR with anything mentioned in the previous comment?

[akashshyamdev]

Hey @mikhael28 , Sorry, I'm really tied up with freelance work right now.

[mikhael28]

Get the money! Best of luck - let us know how we can help :D

[jayeclark]

@akashshyamdev no worries, glad to hear you're busy with work! I think @vmcodes has created a types folder via PR #141 (which I assume will get merged soon), so things should be all set on this now anyway.

@mikhael28 Just catching up on this thread/all the threads, but what was discussed here makes a lot of sense to me. Should I update the style section of the Contributing guide soon to reflect it?

[mikhael28]

Yes @jayeclark , that would be great - please make that note in the Contributing guide!