Timetables are expanding for me like crazy lately. Last month we did a major release, that of course meant a lot of work to do. I also volunteered to prepare JavaScript workshops at my workplace and hosted them a week ago. I had a blast presenting and learning other people about building REST APIs with NodeJS 😉 At the same time I feel relieved, that I finally emptied my calendar and have some time to rest.
Of course, being busy resulted in learning new stuff, so I want to share them with you, as always 😊
This is one of those “JavaScript, the weird parts” type of articles. Nevertheless, I love those little quirks of the language. I like presenting them to my co-workers and watch their baffled reactions 😊
It’s worth reading because the conclusion gives you really meaningful insight into how you should manage your data and what to watch for.
Nothing more misleading. We still have boundaries in our application, where unexpected data can slip in and destroy our delusion of safety. I experienced those situations myself. Those boundaries may be for example your services, that communicate with external REST API.
Lately, I found two solutions (libraries) to solve that problem. One of them is “io-ts”, that enables us to create runtime types, that decodes our objects and checks, whether they have the right structure during runtime.
The article explains just how severe our problem might be and gives us a thorough example of how to use a custom JSON Decoder to our advantage.
I wonder just how we could use those concepts in Angular. Leveraging Functional Programming concepts in Angular may result in something really interesting.
Of course, being busy resulted in learning new stuff, so I want to share them with you, as always 😊
1. JavaScript
>> “Why (! + [] + [] + ![]).length is 9” by Tomas Forsman
Tomas presents us with one of the unexpected behaviors of JavaScript. “Unexpected”, compared with other languages, of course. Firstly, I wouldn’t even expect the above code to even run without errors (that exclamation mark next to a “plus” sign was eerie). The author presents us a step by step explanation to the final solution. After thinking for a while about it, it’s really simple 😉This is one of those “JavaScript, the weird parts” type of articles. Nevertheless, I love those little quirks of the language. I like presenting them to my co-workers and watch their baffled reactions 😊
>> “Performance vs Readability” by Riccardo Polacci
Here Riccardo presents us with a really interesting remark – just how performant are all Array methods that enable us to transform data in a readable way?It’s worth reading because the conclusion gives you really meaningful insight into how you should manage your data and what to watch for.
>> “4 Types of Memory Leaks in JavaScript and How to Get Rid Of Them” by Sebastian Peyrott
Sebastian presents us with basic concepts of memory leaks in our applications and what are the dangers when dealing with JS. We get to know how the memory is managed internally and what are the most common sources of memory leaks in JS. There we can also find a thorough tutorial on how to detect and track memory leaks with Chrome’s DevTools.>> “shepherd.js” library
I was recently interested in finding a technology that enables creating interactive tour guides through your app. Shepherd.js is exactly that. Above link gives us a little demo of the library’s functionalities. You can use it with plain JS and with popular frameworks using corresponding wrapper library.2. TypeScript
>> Using “io-ts” library to make a runtime validation in TypeScript [ 1 ] [ 2 ]
I think one of the most important things TS users are forgetting, that it is still a JavaScript underneath. During TS to JS compilation, we basically throw out everything that is TS and enter JS world. That may be tricky. We feel safe, because we provided necessary static typing to our objects, so nothing unexpected can happen with our data.Nothing more misleading. We still have boundaries in our application, where unexpected data can slip in and destroy our delusion of safety. I experienced those situations myself. Those boundaries may be for example your services, that communicate with external REST API.
Lately, I found two solutions (libraries) to solve that problem. One of them is “io-ts”, that enables us to create runtime types, that decodes our objects and checks, whether they have the right structure during runtime.
>> “Decoding JSON with Typescript” by Joan Llenas Masó
Here we have another solution for the above problem – “ts.data.json” library. It introduces JSON Decoders concepts known from Elm. It allows us to manage a set of decoders for primitive data types and compose our own for decoding (validate) our data.The article explains just how severe our problem might be and gives us a thorough example of how to use a custom JSON Decoder to our advantage.
>> “Union types in TypeScript: modeling state” by Matias Klemola
Matias shows us an interesting concept of how to model an application’s state with TypeScript’s union types. It’s inspired by how The Elm Architecture works.I wonder just how we could use those concepts in Angular. Leveraging Functional Programming concepts in Angular may result in something really interesting.
Comments