I have seen that code in Stackoverflow. Someone was asking something about it. I do not have the link, just grabbed the snippet some long time ago. The point is not where does that come from, the point is it can exist and if I need to deal with it I need to do a deep dive in something that I do not have interest nor energy to invest on and in the mean time slows me down considerably.
> A nested partial, as the name of the type helpfully suggests...
Ok, good for you that you can proficiently understand it! Note that I'm not saying this in an arrogant way, honestly good for you that you have another tool in your belt, which is something always valuable.
I just do not want to deal with that (same that I do not want to deal with type hints in Python, I don't need it) but I increasingly see the industry (in general terms) praise for it. I prefer to stick to: "If it walks like a duck and it quacks like a duck, then it must be a duck".
Think about TypeScript the other way round. What if TypeScript wouldn't be out there? What can you do to bring more stability to your FE code?
> Think about TypeScript the other way round. What if TypeScript wouldn't be out there? What can you do to bring more stability to your FE code?
Luckily, we don't have to conduct this thought experiment, we lived it from the release of JavaScript in 1995 to the release of TypeScript in 2012. The result was a decade and a half of spaghetti JS scripts and JQuery and unstable frontends. Universally true? No, of course not, it's always been possible to write good frontend code, but people who do that have been exceptions, not the rule.
> The point is not where does that come from, the point is it can exist and if I need to deal with it I need to do a deep dive in something that I do not have interest nor energy to invest on and in the mean time slows me down considerably.
Look, I completely disagree with you about the value of types, I think they're an incredible tool that rules out the existence of an entire class of bugs which are incredibly common in JavaScript frontends. But you don't have to agree. You don't have to like types, and you don't have to like or use TypeScript. But it's a tool that allows me to reinforce the basic structure of a webapp so that it's reasonably stable with far less work than vanilla JS. You seem to object to the existence of TypeScript and don't realize you can just... not use it?
> Luckily, we don't have to conduct this thought experiment...
You're implying that with TypeScript you will get your codebase spaghetti free which is obviously not true. You can have a code base that hasn't a single type error and yet be full spaghetti. This also holds true when working with any framework, backend or frontend.
> TypeScript and don't realize you can just... not use it?
I don't but the places I've seen TypeScript code bases still suffered from much more critical issues than type issues. Like using wrong ideas, wrong patterns, no tests, spaghetti code, but hey you know what? We use TypeScript and is great, and believe it or not that is becoming the rule, not the exception.
TypeScript solves one single problem and is pretty good at it given the dynamic complexity of JS language. Trying to justify its usage as "fix-all band-aid" and then not liking the tool because it can't do that is not very productive. You can use wrong ideas, wrong patterns, no tests and have spaghetti code in literally every other language, that's not something for TypeScript to handle.
> You're implying that with TypeScript you will get your codebase spaghetti free
I am not. I'm saying I don't have to imagine a world without TypeScript, I've lived it.
> You can have a code base that hasn't a single type error and yet be full spaghetti. This also holds true when working with any framework, backend or frontend.
Sure. I don't disagree. I'd still rather have the codebase without the type errors.
Types make expectations on behavior explicit instead of implicit. They nay not feel needed when you feel like you master the language, but they sure do help communicate and quickly grok some aspects of the code without having to interpret it in your head(which might be easy when you've just written it but less so in many situations).
I have seen that code in Stackoverflow. Someone was asking something about it. I do not have the link, just grabbed the snippet some long time ago. The point is not where does that come from, the point is it can exist and if I need to deal with it I need to do a deep dive in something that I do not have interest nor energy to invest on and in the mean time slows me down considerably.
> A nested partial, as the name of the type helpfully suggests...
Ok, good for you that you can proficiently understand it! Note that I'm not saying this in an arrogant way, honestly good for you that you have another tool in your belt, which is something always valuable.
I just do not want to deal with that (same that I do not want to deal with type hints in Python, I don't need it) but I increasingly see the industry (in general terms) praise for it. I prefer to stick to: "If it walks like a duck and it quacks like a duck, then it must be a duck".
Think about TypeScript the other way round. What if TypeScript wouldn't be out there? What can you do to bring more stability to your FE code?