0007 proposal: to adapt Typescript in backend.#11
0007 proposal: to adapt Typescript in backend.#11dadiorchen wants to merge 2 commits intoGreenstand:mainfrom
Conversation
|
|
||
| Developer need to learn Typescript. | ||
|
|
||
| But, I suggest we just use the most basic features of Typescript. Because a over-typed System goes to a wrong direction, actually it makes the code less readable. |
There was a problem hiding this comment.
I'd suggest splitting this out into a separate option:
- Option 1: Fully adopt TypeScript.
- Option 2: Use basic TypeScript features (list suggestions of features to use)
- Option 3: Use vanilla JavaScript
|
|
||
| But, I suggest we just use the most basic features of Typescript. Because a over-typed System goes to a wrong direction, actually it makes the code less readable. | ||
|
|
||
| So I suggest we just use TS in a simple way, and if we set up the codebase with Typescript correctly, then a newcoming developer shouldn't need to take a long time to learn Typescript to start coding. |
There was a problem hiding this comment.
I agree with this. Basic TypeScript features can bring a lot of benefits.
We should try to define a style guide to help developers decide how much to use, with a corresponding linter configuration.
There was a problem hiding this comment.
Yes, maybe a good eslint config, TS config and template repo is helpful
| * The code quality. | ||
|
|
||
| ## Considered Options | ||
|
|
There was a problem hiding this comment.
We could consider compiled languages too like Kotlin, but I understand Typescript is a natural progression from javascript.
|
|
||
| Developer need to learn Typescript. | ||
|
|
||
| But, I suggest we just use the most basic features of Typescript. Because a over-typed System goes to a wrong direction, actually it makes the code less readable. |
There was a problem hiding this comment.
My knowledge of Typescript is basic, but any typed language gives good tools to model the domain, but modeling it right is an ongoing process regardless of the language.
There was a problem hiding this comment.
@arunbakt that's a book to discuss it :D
arunbakt
left a comment
arunbakt
left a comment
There was a problem hiding this comment.
I support and agree using a typed language is a good thing for a code base that is large or expected to grow large and with rich domain complexity. Domain driven design practical patterns that are available publicly use typed languages like C#/Java. It will be a considerable advantage to use typed language where we could learn and apply those patterns in modeling the Wallet API.
My major consideration on this proposal is the productivity, to code easier, to fix problem easier, and protect and maintain the code easier |
ZavenArra
left a comment
ZavenArra
left a comment
There was a problem hiding this comment.
We need to address how we decide which microservices use javascript vs typescript
|
@ZavenArra I prefer to make typescript a default setting for all microservice, I think for new coming developers, projects with Typescript seems don't bring too much burden for them, by setting up all the TS configs correctly, it's easy to get started, I tried on the treetracker-query-api which using TS, junior dev starts the work easily IMO, with TS, it's easy to navigate in code, and give them more accurate warning, error messages, and the auto-fix function works well, all of them make the coding more comfortable. For the current situation, I suggest by the changes of refactoring, we can bring TS to wallet-api, for other existing ones, no need to add it, for new coming repo, we can use a TS based template. |
|
I think I might be a bit conflicted with adopting typescript for all microservices. I think we could just bring in typescript for the very complicated APIs like the wallet-api, especially given the fact that some or most of the microservices just have to do with basic CRUD endpoints. We could also start by coming up with a microservices typescript template, see how that looks and decide per each new repo whether to use it or not. |
Yes, @Kpoke no need to refactor all existing ones. just for new repo I think |
5 participants
No description provided.