4 ms·

> Discussing types? Does it matter that much [?] Well, if you've decided to use TypeScript for some reason other than momentary whim, it must matter a lot...

tom_ 8y ago
I assume the point is that creating new types is very simple, so if you need a new one, then you can just make one, call it what you like, put whatever you need inside it, and start to use it. You don't need to have interminable discussions about this. If you need more stuff in the type later, you can add it. If the name turns out to be wrong, you can change it. If you need to remove something, you can do that. If you just decide that it was a bad idea, you can get rid of it entirely. In each case, you can just make the change, and the compiler will show you all the code that has to change because of it. If this is some public-facing or versioned thing then some discussion would be warranted - but you would have had to do that already, types or no! (But even if the worst happens, and some new type gets added in, and it's kind of wrong, and it gets exposed anyway: at least you know about it.)
- tekkk 8y ago
  You gave a better answer than I could have done myself :). Yes, more or less so. Sometimes there can be tricky typing issues but in those cases somebody wiser often comes in and the problem is solved together. At times it's better for individual developers to try to solve say a typing problem on their own instead of somebody else giving them an immediate answer. Maybe it decreases productivity a little bit, but in the long run it's better for developers' individual growth. Though incase the problem is too difficult, I can't emphasize enough the importance of the wisdom of experienced developers.
- deleted 8y ago
  [deleted]
tekkk 8y ago
What is your argument? If we are not "discussing with colleagues what types should be called" we are only using TypeScript for no other reason than momentary whim? For his next points, sure you have to give it a pause before you decide to implement your interfaces. I do not know what type of app he is building, but I myself and our team have clear established patterns that we use. And if something bothers someone, they'll be discussed in a code review or be refactored at some point. But without more context, I can't give a better answer.

tom_ 8y ago

I assume the point is that creating new types is very simple, so if you need a new one, then you can just make one, call it what you like, put whatever you need inside it, and start to use it. You don't need to have interminable discussions about this. If you need more stuff in the type later, you can add it. If the name turns out to be wrong, you can change it. If you need to remove something, you can do that. If you just decide that it was a bad idea, you can get rid of it entirely. In each case, you can just make the change, and the compiler will show you all the code that has to change because of it. If this is some public-facing or versioned thing then some discussion would be warranted - but you would have had to do that already, types or no! (But even if the worst happens, and some new type gets added in, and it's kind of wrong, and it gets exposed anyway: at least you know about it.)

tekkk 8y ago
You gave a better answer than I could have done myself :). Yes, more or less so. Sometimes there can be tricky typing issues but in those cases somebody wiser often comes in and the problem is solved together. At times it's better for individual developers to try to solve say a typing problem on their own instead of somebody else giving them an immediate answer. Maybe it decreases productivity a little bit, but in the long run it's better for developers' individual growth. Though incase the problem is too difficult, I can't emphasize enough the importance of the wisdom of experienced developers.
deleted 8y ago
[deleted]

tekkk 8y ago

What is your argument? If we are not "discussing with colleagues what types should be called" we are only using TypeScript for no other reason than momentary whim? For his next points, sure you have to give it a pause before you decide to implement your interfaces. I do not know what type of app he is building, but I myself and our team have clear established patterns that we use. And if something bothers someone, they'll be discussed in a code review or be refactored at some point. But without more context, I can't give a better answer.