Introduction:
TypeScript, built upon the foundation of ES6 and beyond, marries the power of modern JavaScript with the benefits of a sta...
For further actions, you may consider blocking this person and/or reporting abuse
Great article!
I would include "stop using the I prefix at interfaces", which is a very common pattern for TS developers. I don't know how that C# convention invaded TypeScript world. (Microsoft behind both of them probably is a coincidence since they discourage it)
Some developers make the case that not using it cause weird code like
class Dog implements Dog, but that actually shows issues with the code design (in this case, is the Dog class really necessary? If it is, than the interface Dog probably isn't).You're right that the "I" prefix convention has been a common pattern in the TypeScript world, and it's valuable to discuss its implications. I agree that avoiding it can lead to cleaner code and better alignment with TypeScript's idioms. Your example of the class Dog implementing Dog is a thought-provoking one that highlights potential code design issues.
You've given me an idea for an insightful follow-up discussion on this topic. Thank you for sharing your perspective!
Outdated function syntax? 🤨
That is what you must avoid.
Named function is not outdated at all. developer.mozilla.org/en-US/docs/W...
Alas, the function keyword is the base in all programming languages.
Using anonymous functions is a personal preference and you lose hoisting and can be harder to debug.
Thank you for taking the time to share your thoughts. You're absolutely right that the choice between arrow functions and traditional named functions is indeed a matter of preference and context. Arrow functions offer concise syntax and lexical scoping, while traditional named functions provide hoisting and possibly clearer stack traces. Both have their merits, and it's wonderful that developers have the flexibility to choose the style that best suits their needs and the project's requirements.
I think a better advise would be to not mix them in the same project/module. Sometimes I see code that has both types of declaration used in similar ways and in the same scope, probably because of different developers acting on the project. It makes the code look ugly and a bit confusing.
If you're going to use traditional named funtions, stick to it, maybe with the exception of callbacks.
Functions and Arrow Function serve their own purpose. They are not contradicting each other. Example this binding
@brunomonteiro1 @emil
I strongly agree
Amazing, good cheat sheet, thanks!
thanks