Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
This would be a different question. The post is more about letting people know that there are two different ways in which you can use TS in your project.
Type-checking, documentation and type inference in Dev Time is a valuable bunch of things to have, there's no doubt on that (I guess).
Being able to get those things while working with JavaScript just by adding TS Pragma and documenting your code (which is something you should want as well in your projects by default) suits for many projects.
If I'm going to create a big service in Node RE I'll probably add TS as dependency, but I'm not adding it in frontend React or Next JS applications because this other way to get type checking in dev time suits better IMHO.
This is just my personal preference without context and I myself can review my preferences in a future.
Knowing both ways to use this, you can choose whichever suits best for your projects.
I'm currently hands on two different projects using this second option, both are usign Next JS as framework but with two different approaches.
In the first one we depend on a headless CMS so the requests goes through Next -> gateway -> microservice -> CMS to get the page structure and data to pre-render it (SSR) with React, so the Node JS part in Next is just a middleware. (The GW and the micros are built with Java Spring).
The second one has it's own services inside Next JS Node part, connected directly to a database using Sequelize as ORM and Joi for validations.
If we need to migrate to TS for any reason (it doesn't look like to me) we can do it easily as we already defined types and so on.
I can extend more the architecture explanation but with the information provided you can see that the project with the CMS does not fit well for TS (we can receive whatever structure from the CMS and we should then define all the input types which is kinda annoying when client wants the things ASAP) so we can just use types for our inner components and ignore them in the dynamic factory that loads components dynamically to just check the identifier of each, or in other words, apply responsibility delegation.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This would be a different question. The post is more about letting people know that there are two different ways in which you can use TS in your project.
Type-checking, documentation and type inference in Dev Time is a valuable bunch of things to have, there's no doubt on that (I guess).
Being able to get those things while working with JavaScript just by adding TS Pragma and documenting your code (which is something you should want as well in your projects by default) suits for many projects.
If I'm going to create a big service in Node RE I'll probably add TS as dependency, but I'm not adding it in frontend React or Next JS applications because this other way to get type checking in dev time suits better IMHO.
This is just my personal preference without context and I myself can review my preferences in a future.
Knowing both ways to use this, you can choose whichever suits best for your projects.
I'm currently hands on two different projects using this second option, both are usign Next JS as framework but with two different approaches.
In the first one we depend on a headless CMS so the requests goes through Next -> gateway -> microservice -> CMS to get the page structure and data to pre-render it (SSR) with React, so the Node JS part in Next is just a middleware. (The GW and the micros are built with Java Spring).
The second one has it's own services inside Next JS Node part, connected directly to a database using Sequelize as ORM and Joi for validations.
If we need to migrate to TS for any reason (it doesn't look like to me) we can do it easily as we already defined types and so on.
I can extend more the architecture explanation but with the information provided you can see that the project with the CMS does not fit well for TS (we can receive whatever structure from the CMS and we should then define all the input types which is kinda annoying when client wants the things ASAP) so we can just use types for our inner components and ignore them in the dynamic factory that loads components dynamically to just check the identifier of each, or in other words, apply responsibility delegation.