You know that application that keeps you up at night hoping you won't have to change it? It seems like we all have one.
Mine was in JavaScript. It...
For further actions, you may consider blocking this person and/or reporting abuse
Besides the click bite title, I find the problems you're describing are not a thing that typescript itself is a solution too.
All of them are tooling and design problems.
Finding Existing 'Linking' Issues
Strongly-typed Variables
typeofis your friend heretypeofhas it strange behaviorsPromise<MyType<T>>. Is this more helpful maybe?Catching silly mistakes with ESLint
Introducing Classes
Eliminating Global State
Testability
In general, it sounds more like what the most significant difference here is that the team is more experienced and knows better what is needed. I'm not against TypeScript. It has its good things, but also it has its downsides. Like no abstract classes. Even OOP fanatics now say that composition is a better way then class inheritance (SOLID principle).
Typescript adds expressive compile time type info.
typeofdoesn't compare. I think the main point was that the extra safety from types made the other refactoring possible. That's not surprising since types are basically a kind of formal proof of program code.To say
typeofdoesn't compare is absurd. Compile-time type-checking definitely has its uses; but people seem to forget that (unless I am very much mistaken) no type checking is being carried by the compiled code at run time. In which case you absolutely must do type-checking on data coming from sources outside your application. Typescript is not a replacement for proper data validation for whichtypeofis pretty much essential.You are correct - TypeScript's checks are entirely at the transpilation level. You do occasionally need to do some checking at some boundaries, but things inside of your systems can generally be trusted to be properly typed if you have proper validation at the boundaries and rely on
tscto catch the other issues.I am not mistaken. From Typescript design goals:
I feel like you're really wanting to talk.
I still confused, for example, I create a method like this;
And backend data returns like that;
This is wrong I know. But I just imagined.
I used this data like that;
So, how can help us TypeScript in this case? I really don't have enough knowledge about TypeScript.
In the end, nobody replied to the question. You need to use a type guard for this. It is when static typing becomes dynamic. You have to manually check each field in the payload by
typeof. Check the official docs.typescriptlang.org/docs/handbook/a...
So your aTypeScriptMethod would have a strict typing of number which means it will only accept that type.
This means when you later set age from dataFromBackend.age the let would be cast as a string.
Therefore when you try to pass the function a string you would see a compilation error, that would give you feedback saying you have tried to pass a string to the method rather than a number resulting in your code not compiling until you resolve the casting of age.
Owen - Either I'm misinterpreting your answer or it is simply wrong. Typescript only does compile-time type-checking. All it knows about data coming from outside is what hypothetical type you have assigned to your input parameters; but no run-time type checking or data-validation is embedded into the compiled code that actually handles the data: it has been compiled to plain JavaScript with no type checking.
In the example given Typescript is no help at all: the application would simply crash. I've seen this happen recently in an application taking data from a PHP backend out of our control. The data didn't conform to the data type we expected and our application bombed because someone forgot to add the proper checks. This was in QA so no big deal; but could have been really problematic if it had slipped through the net.
I think it would be unfair to call this a flaw in Typescript; but it is really important that people understand this. Typescript is not a substitute for doing proper type-checking/validation on data that is outside your control.
If that was to me, you need to read it in context.
tscdoesn't generate type checking logic, it does static tranpilation analysis based on what you've told it about the types. If you tell it the Web API result returns anumber, it'll roll with it and find no issues (assuming you treat it like anumber). Since it transpiles down to JavaScript, the variable will still get assigned astringand you get the same sort of an issue down the road. That's why it's important to get your type definitions correct as well as potentially validate them at the boundaries with atypeofcheck.Also bear in mind union types and nullability are supported in TypeScript and should be considered and used. The benefits once you understand them are great, however.
Matt - my response saying the answer given was incorrect was not directed at you. I've edited it to make that clearer ;)
Great overview of the benefits of a type system (and bringing good design patterns) with an in-use code base.
Could you share your eslint rules
I unfortunately cannot share any code with this particular article due to shared ownership. Was there some specific aspect you're curious about? I could talk about that in more depth.
I've been using typescript for about 2 years now and my lint rules are defined in tslint. I'm looking to convert everything over to eslint, so I'm curious to see what rules people are using. I am aware of airbnb rules but I'm interested in seeing what other things people typically lint