Mas alla de javascript con typescript
•Descargar como PPTX, PDF•
0 recomendaciones•255 vistas
El documento habla sobre TypeScript y sus ventajas para el desarrollo de aplicaciones JavaScript. TypeScript es un superconjunto de JavaScript creado por Microsoft que agrega tipos estáticos y otras características. Esto hace que el código sea más fácil de comprender, mantener y probar, ayudando a prevenir errores y mejorar la productividad. Muchos frameworks como Angular y equipos importantes han adoptado TypeScript.
Más contenido relacionado
Similar a Mas alla de javascript con typescript
Similar a Mas alla de javascript con typescript (20)
Más de Leonardo Micheloni
Más de Leonardo Micheloni (13)
Último
Último (20)
Mas alla de javascript con typescript
- 1. @leomicheloni Más allá de Javascript con Typescript Leonardo Micheloni Developer.
- 2. @leomicheloni Hola! ■ Leonardo Micheloni ■ Slides y código de ejemplo: @leomicheloni
- 4. @leomicheloni ■ Conocer ■ Comprender ■ Decidir
- 6. @leomicheloni ■ Escalabilidad. ■ Rigidez. ■ Matenibilidad. ■ Evolución. ■ Reutilización.
- 9. @leomicheloni Microsoft 2012 ■ Respuesta al desarrollo de grandes aplicaciones ■ Estricto superset de ECMAScript 2015 ■ Una app Javascript es una app Typescript válida ■ Ir por delante de la especificación de Javascript ■ Open source (Apache) ■ Mantener la experiencia actual
- 12. @leomicheloni Any browser, any host, any OS
- 13. @leomicheloni
- 14. @leomicheloni
- 15. @leomicheloni Transpilación El código Typescript se convierte en javascript Typescript es un superset de Javascript
- 16. @leomicheloni ■ Tipificación fuerte ■ Inferencia de tipos ■ Interfaces ■ Módulos ■ Enumerados ■ Deconstrucción ■ Type assertions ■ Generics ■ Namespaces ■ Tuplas ■ Async/Await ■ POO ■ Typings ■ Optional properties Algunas features
- 17. @leomicheloni Adopción Angular Team Visual Studio Code Typescript Microsoft Ionic Aurelia Dojo toolkit Bet365 https://www.typescriptlang.org/community/friends.html
- 18. @leomicheloni Tooling ■ VSCode ■ Visual Studio ■ Sublime ■ Atom ■ WebStorm ■ Vim ■ Eclipse ■ Emacs
- 19. @leomicheloni Typos estáticos “The more type definitions I was putting into the code, the more often I was noticing that it was saving me from wasting time on manually debugging stupid bugs in the console”
- 20. @leomicheloni ¿Y esto qué nos aporta? ■ Facilidad de comprensión del código ■ Facilidad de refactor ■ Detección temprana de errores ■ Velocidad en el Desarrollo ■ Facilita los merges ■ Puedo confiar en mi código en runtime ■ Posibilidad de utilizar patrones POO ■ SOLID
- 21. @leomicheloni
- 22. @leomicheloni
- 23. @leomicheloni
- 24. @leomicheloni Código más fácil de comprender ■ ¿Qué argumentos acepta? ■ ¿Qué valores retorna? ■ ¿Qué datos requiere? ■ ¿De qué tipo son? console.log(article)
- 25. @leomicheloni Código más fácil de refactorizar ■ Renaming ∘ Find and replace ∘ Comprobación semántica ■ Promoción de tipos ■ Extracción de miembros
- 26. @leomicheloni Código más fácil de desarrollar ■ Evolución del código más segura ■ Utilización de patrones más simple ■ Definición de interfaces con otros developers
- 27. @leomicheloni Test más útiles ■ No necesitamos test que comprueben tipos ■ Nos focalizamos en el negocio ■ Podemos hacer TDD
- 28. @leomicheloni Integración más fácil ■ Merge más simple ■ Mejora la comunicación a través del Código ■ Código auto-documentado
- 29. @leomicheloni Preocupaciones ■ Si usamos Typescript no vamos a conseguir gente capacitada ■ El onboarding puede llevar más tiempo ■ React / Redux / Mi framework no soporta Typescript ■ No se puede reutilizar código Javascript en Typescript ■ No quiero atarme a una tecnología efímera
- 30. @leomicheloni
- 31. @leomicheloni ¿De dónde sale esta magia de los tipos?
- 34. @leomicheloni
- 35. @leomicheloni Conclusiones ■ Typescript me ayuda a detectar errores temprano ■ Typescript me da más herramientas para utilizar prácticas de desarrollo ■ Prácticamente todos FW soportan Typescript ■ Puedo comenzar a utilizarlo paulatinament
- 38. @leomicheloni Referencias ■ https://medium.com/@jtomaszewski/why-typescript-is-the-best-way-to-write-front-end-in-2019- feb855f9b164 ■ https://www.typescriptlang.org/ ■ https://dev.to/cooperdev/restructure-with-ease-thanks-to-typescript-path-mappings-4b0e ■ https://tutorialzine.com/2016/07/learn-typescript-in-30-minutes ■ https://redux.js.org/recipes/usage-with-typescript/ ■ https://www.electronjs.org/blog/typescript ■ https://slack.engineering/typescript-at-slack ■ https://stackshare.io/typescript ■ https://www.freecodecamp.org/news/learn-typescript-in-5-minutes-13eda868daeb/ ■ https://blog.bitsrc.io/why-and-how-use-typescript-in-your-react-app-60e8987be8de
Notas del editor
- ddddd
- ddddd
- ddddd
- hacer software es complejo Ciclos iterativos Antes usábamos cascada
- Tratamos de anticiparnos a estas cosas Aplicaciones que crecen Prácticas de desarrollo Grande libros
- Javascript no está pensando para grandes aplicaciones Nació como un lenguaje de scripting
- Se ejecuta en cualquier entorno que ejecute javascript Browser V8
- Por ejemplo Vscode es multiplataforma Está escripto con typescript
- TypeScript advantages 1. Code easier to understand Usually when you work on a piece of code, for example a function code, to understand it fully you need to grasp: What arguments does it accept? What value does it return? What external data does it require? What does it do with these arguments and external data in order to produce the return value? In dynamically typed languages, very often it is difficult to answer the first three questions. If a function receives article argument, what exactly is it? Is it an object with some article attributes? What exact attributes are there? Is there an article.title or article.name ? Can I always assume that article.title exists? How about article.isPublished? I might know that this attribute is merged into the article object in most of the places of the app, but can I be sure, that it is always present in this spot as well? To answer all of those questions, usually you’d need to do one of the following: a) put a console.log(article), run the script in your browser, (maybe click through the UI a bit), and read the log; b) see where the function is used and from there track down what data is put into all of its occurrences; c) ask your colleague that recently had been working on this code (while hoping that they are still alive, online, and remember that code); d) assume that article is like what you think it is, and just hope it works. Does that sound familiar to you? To me, that sounds like a typical web dev workflow in any dynamically typed language like JS, PHP, Ruby, Python, Elixir. In statically typed languages like TypeScript, you get answers to all of the above questions immediately from your IDE and compiler. No longer you need to look through entire code base, keep bugging your workmates with questions, or risk having bugs on production. 2. Code easier and faster to implement Typically, when you have to create a new feature or a new component, your workflow probably looks something like this: Bootstrap the component function, make up its constructor arguments, write the remaining code. If it requires any external or sophisticated data (like user or articles), guess how will it look like, keep it in your own memory and use it like that in the code. Put the component into your app and pass props into it. Test it, either manually or with unit tests. (You need to make sure that it receives the props it should have and that it works how it should work.) If something isn’t right, go back to your code, try figuring out what’s wrong with it, fix it, and go back to step no. 4. In TypeScript, it is similar, but easier and quicker: Bootstrap the component function, define its’ type definition, and implement it. If it requires any external or sophisticated data, look up their interfaces and reuse them (fully or partially). Put the component into your app and pass props into it. That’s it. (If you matched the typedefs correctly between the caller and the callee, everything should work flawlessly. The only thing you have to test now is the actual business logic of your component.) Thus, whenever you write code in TypeScript, not only it is more readable and less error-prone, but mainly, just easier to reason about. 3. Code easier to refactor There’s often quite a lot of things you’d like to refactor, but because they touch so many things and files, you’re just too afraid of changing them. In TypeScript, such things can often be refactored with just one click of “Rename Symbol” command in your IDE. In dynamically typed languages, the best thing you can get to help you with refactoring multiple files at the same time is Search & Replace with RegExp. In statically typed languages, Search & Replace isn’t that needed anymore. With IDE commands like “Find All Occurrences” and “Rename Symbol”, you can see all occurrences in the app of the given function, class, or property of an object interface. Whenever you want to improve your build system a bit, rename your components, change your user object, or remove a deprecated attribute, you don’t need to be afraid of breaking things anymore. TypeScript will help you finding all the usages of the refactored bit, renaming it, and alerting you with a compile error in case your code has any type mismatches after the refactor. 4. Less bugs Throughout many years of front-end web development, I have noticed that I could save up around ~50% of my time in bug fixing just by having somebody sitting next to me that would immediately yell at me whenever I was doing a typo, using a value that might be null, or passing an object into a place where it should be an array instead. I’m happy to say that I finally met that buddy: it is called TypeScript. Thanks to it, it is now way more difficult to write invalid code. If it compiles, you might be quite sure that it actually works. 5. Less boilerplate tests When you are sure your variables are passed correctly into all given places, you don’t need to test all of it that much anymore. Instead of writing simple boilerplate unit/integration tests, you can focus more on testing business logic of your app, instead of testing whether your function arguments are being passed between each other correctly. Less tests means shorter time to develop new features, and a smaller codebase, which in turn is less complicated, less error-prone and easier to maintain. 6. Code easier to merge New junior developer in your team has just issued a PR introducing new code. At a first glance it all looks o’right: the code looks good, the unit tests are there, everything passes green. Can you be sure at this moment that it works though? What if it doesn’t have proper unit tests? (Yeh. Let’s meet the reality folks, a lot of us still don’t write sufficient number of them.) Will you just trust the PR creator? Or will you focus your precious 5 min to actually run the code on your own and test it? If you have TypeScript in your toolchain, it gives you another assurance check: the typedef compilation check. If the code looks good, the unit tests are there, and the whole thing compiles, now you can be pretty sure, that the whole thing works. TypeScript makes it easier to trust other developers. It might improve the pace with which you review and merge PRs. (The same goes the other way: thanks to type definitions, for new developers it is easier to see what other people’s portions of code are really doing, without the need of deep diving into it or running it by themselves.) 7. Aids the developer in having the correct workflow When writing code in statically typed languages, you first need to think about the types of the data you’ll receive, and then about the type of data you want to produce. Usually only after that you sit down to the actual implementation. Many people will bet their life that this is the correct coding workflow. For example, whenever you develop an algorithm, you should first think about its’ theoretical formula, and then implement it. Or, whenever you do TDD, you first need to think how your code will work in reality (what data will it receive and what data will it produce), write it as tests, and then implement the actual code. Same thing applies to TypeScript. It encourages you to think about the interface of your code before sitting down to its’ internal implementation.
- + de 30K para las libraries más famosas
- Es un paquete node tsc