https://github.com/ant-design/ant-design/commit/9a0d751f94a19c5b20f01165d0d47fb1ee53687b This is a commit of Ant Design refactoring their code with TypeScript. I think it will be a good reference.
On Wed, Oct 30, 2019 at 7:58 PM Yi Shen <shenyi....@gmail.com> wrote: > First of all, I want to make my point more clear: > It's not changing from one language to another. The key is bringing strong > typing system into current JavaScript code. That's what TypeScript designed > for. > > Otherwise it probably >> reduces the willing of contribution. Thus a simple language might be >> better, suppose they do not know them well. > > > Only if our developers say so. About this point. I want to quote what > author of vue says in his article about rewriting vue with TypeScript [1] > "The codebase is also now written in TypeScript. Although this will make > proficiency in TypeScript a pre-requisite for contributing to the new > codebase, we believe the type information and IDE support will actually > make it easier for a new contributor to make meaningful contributions." > > Now we have the code standard [3] code checking based on JavaScript, which >> is the guide when adding or modifying code. If part JS part TS, how to >> guide >> the contributors? > > > It will be merged to master only when all the codebase are written in > TypeScript. > > If a language feature is reliable (the spec endorse them) and benefit >> echarts a lot, we might use them. >> If it is not enough, we can wait. Do not need to be in hurry. > > > I think TypeScript has shown its relibility since it has been working well > in a bunch of large project, like Angular, for a very long time. > > >> Program language does not determines how good a program is. >> The program design, the understanding of requirements, the testing work >> does > > > A good language help us write a good program. It reduces the possiblity of > having bug in collaboration. Especially when wen need to grow our community. > And the design of code are heavlily based on the feature of programming > language. > > > [1] > https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf > > On Tue, Oct 29, 2019 at 11:50 PM SHUANG SU <sushuang0...@gmail.com> wrote: > >> I am afraid I do not agree with it. >> I like TypeScript too, but do not support to refactor echarts to >> TypeScript, >> at least do not support to start the refactor work now, >> until some more strong and reasonable arguments or points appear. >> Basically, I think it brings little benefits but has some downsides and >> brings heavy cost of a big surgery. >> >> >> *[About the bugs and issues]:* >> >> The bug [1] can be find by TypeScript. But bugs like [1] are very rare >> since echarts be born. >> And even if TypeScript can make sure the type checking for interfaces, it >> still can not ensures the content >> of the parameters is correct. Essentially, test cases and regression >> testing is what we need to cover this >> cases. If test cases cover them, this kind of bug can be found, no matter >> JavaScript or TypeScript is used. >> Testing work is annoying but worth to take the time, comparing with the >> heavy workload of refactoring to TS. >> >> Most of the typo issues in [2] are either: >> - Typo in comments, which are nothing to do with the programming language >> selection. >> - Spelling problems but the logic of the code is correct, where TypeScript >> does not help. >> - Spelling problems and cause buggy code, which can be found by code >> checking tools like ESLint. >> TypeScript is not necessarily needed. >> >> In the experience of maintaining echarts, most of the issues or bugs (in >> GitHub) are about the logic itself or >> about understanding of the user requirements or about program design. >> Changing to TypeScript can not resolve these issues. >> TypeScript can help to find some of grammar and coding problem when >> programing, but very little. >> And in most cases the code checking tools is enough for JS dev in echarts. >> I think we should better write more test cases to cover the features >> rather >> than considering change a >> programing language to improve the quality. >> >> >> *[About the developers]:* >> >> The user of echarts contains not only the well-trained "front-end >> developers", but also >> lots of developers from various technical background. echarts is just one >> of the libraries in their system or in their big work. >> If they meet some problem, some of them need to check the code to debug, >> some of them need to modify the code to >> fix some defects. And then they might wish to contribute them to echarts. >> I >> think we should not bring more burden in language >> learning or make them hesitate about the detail of the language features. >> Otherwise it probably >> reduces the willing of contribution. Thus a simple language might be >> better, suppose they do not know them well. >> Yes a programmer who have the basic knowledge of Object-orient programming >> may understand the code what ever the >> code write in JS or TS (in echarts case), but they probably have different >> willing to modify the code and feed back to echarts if they >> have to take lots of time to learn a language. In addition, JavaScript has >> been developing for twenty years and might be >> a little more worth of the time to learn it for a non-front-end developer. >> >> >> *[About the steps]:* >> >> > 1. The easiest part, create a new branch and renaming all the files from >> > .js to .ts. If everything goes well, we can use TS compiler to compile >> > these files already. >> > 2. Add typings for our fundamental modules. Like `List`, `Graph`, >> > `graphic`, `View`, `Model` etc...These modules will be used in almost >> all >> > components. >> > 3. We can add typings in our components, which has the most of the logic >> > code. >> > 4. Adjust our code structure to be more TypeScript. >> >> I am afraid I think the progressive way is not practical. The reason is: >> we can not prove it do bring benefits to echarts if just making little >> changes, >> but bring the code to a mass state in a long duration. >> Now we have the code standard [3] code checking based on JavaScript, which >> is the guide when adding or modifying code. If part JS part TS, how to >> guide >> the contributors? >> If we think that some work can be handled in future, if it is not urgency, >> it will probably not be handled for long time, where the code will keep >> part JS part TS style. >> Things change fast. >> >> >> *[About the goal]:* >> The goal of echarts is to build a good data visualization lib. I think we >> should keep focusing on that. >> >> Change a language is a huge work. If making a thorough change, it will >> bring lots of bugs. If >> only changing a little, not worth to do that. So we need to think of them >> carefully. >> If a language feature is reliable (the spec endorse them) and benefit >> echarts a lot, we might use them. >> If it is not enough, we can wait. Do not need to be in hurry. >> Program language does not determines how good a program is. >> The program design, the understanding of requirements, the testing work >> does. >> >> Now that there are so many issues and features need to be handled or >> fixed, >> I do not think changing a language >> is an important thing at the current stage. We have been using JS for more >> than four years in echarts. >> I still can not convince me that if we change the language with a great >> cost, what it really resolves? >> Is it really need to change a language to resolve them? >> >> >> [1] https://github.com/ecomfe/zrender/pull/480 >> [2] >> https://github.com/apache/incubator-echarts/search?q=typo&type=Commits >> [3] https://echarts.apache.org/en/coding-standard.html >> >> >> Thanks, >> ------------------------------ >> Su Shuang (100pah) >> ------------------------------ >> >> >> >> On Tue, 29 Oct 2019 at 15:08, Yi Shen <shenyi....@gmail.com> wrote: >> >> > Hi, >> > >> > It's a very big topic and may sound terrifying. >> > >> > I started this discussion because I'm using TypeScript a lot recently. >> And >> > realized a strong typing system really helps a lot when writing the >> code. >> > So I'm thinking about if we can refactor our code with TypeScript. >> > >> > Of course, there will be a lot of work for the whole codebase. So I >> > suggested separating the process into 4 steps, and hopefully, this can >> be >> > done progressively: >> > >> > 1. The easiest part, create a new branch and renaming all the files from >> > .js to .ts. If everything goes well, we can use TS compiler to compile >> > these files already. >> > 2. Add typings for our fundamental modules. Like `List`, `Graph`, >> > `graphic`, `View`, `Model` etc...These modules will be used in almost >> all >> > components. >> > 3. We can add typings in our components, which has the most of the logic >> > code. >> > 4. Adjust our code structure to be more TypeScript. >> > >> > Personally speaking, the first 3 steps the most needed. It looks to be >> > easy, but during the process of adding typings. We may need to rewrite a >> > lot of code to meet the purpose of strong typing. >> > >> > Here are some pros and cons of changing the code to TypeScript I can >> think >> > of: >> > >> > Pros are mostly come from strong typing: >> > 1. We can avoid bugs like argument mismatching [1], variable naming typo >> > Bugs like these easily happen when we are refactoring the code. I can >> find >> > a lot of commits about fixing the typos [2]. >> > 2. Developers know what the interfaces look like of each module, which >> > makes it easier for them to contribute. >> > 3. VSCode has a really wonderful intelligence on the TypeScript. I >> enjoy it >> > a lot when I'm writing TypeScript. >> > >> > Cons: >> > 1. Honestly speaking, it's a lot of work. And it's hard to keep the >> > TypeScript branch updated with the master branch before merging. >> > 2. Developers may need to learn TypeScript. But I think it's not a big >> deal >> > comparing to learning how echarts works. >> > >> > At last, as I said first, the word refactoring may sound terrifying. >> But I >> > believe it worth it. I hope we can all enjoy writing our code with the >> help >> > of excellent intelligence. >> > >> > Regards >> > >> > [1] https://github.com/ecomfe/zrender/pull/480 >> > [2] >> https://github.com/apache/incubator-echarts/search?q=typo&type=Commits >> > >> > -- >> > Yi Shen >> > Apache ECharts(incubating) PPMC >> > >> > > > -- > Yi Shen > Apache ECharts(incubating) PPMC > -- Yi Shen Apache ECharts(incubating) PPMC
