DEV Community: Kajetan Świątek

From Angular to React - switching jobs, switching technologies

Kajetan Świątek — Fri, 16 Apr 2021 13:02:38 +0000

⚡ Originally published on kajetan.dev. ⚡

TL;DR

I still like Angular, but I fell in love with React and its ecosystem (tooling and libraries), simplicity (concept of components as functions from the state to UI), and flexibility (you can set up and tune your project as you see fit).

How did this decision come to be?

After 2.5 years of working as a front-end developer, I decided to look for a new job. It was a decision driven by my desire to learn and grow.

I came to the conclusion that changing perspectives in the early stage of your career seems healthy. Participating in different projects lets you learn a lot about different approaches companies take, solutions they use, and practices they follow.

This approach is a representation of the "perspective-driven self-development" I wrote about some time ago.

From day one that I decided to look for a job I knew I wanted to work with React (and overall different technologies than before, at best) and strived towards this goal. I did that despite the number of Angular offers I was bombarded every week and companies rejecting me because of my lack of experience with this technology.

I started to learn React not long after starting working with Angular. I did it in my free time, just out of curiosity. During job interviews, it was hard to convince people that I have the abilities needed for the job. Every time I felt somewhat ashamed and tired repeating the same dialogue over and over:

Interviewer:
"So, you want to work with React, but you have no commercial experience?"

Me:
"Unfortunately not... Only the things I've learned myself."

(... And after the further elaboration on my ways of learning the technical interview started.)

That's when I thought about ways of proving myself and strengthening my knowledge even more. I decided to use the oldest trick in the world - I started a side-project. But not a typical one - a one that, by the end, will be a full-blown product. Thoroughly designed, implemented, and finally - deployed to production where everybody would see it. (I almost completed it so no announcements for now!)

But let me get to the point. I want to share with you my thoughts on the technicalities behind my decision. I want to compare Angular and React and share my point of view with you.

What I don't hate about Angular?

Let me get this straight - I still like Angular! It didn't bore or anger me in any way so that I decided to leave it behind. I don't cast aside the idea of me coming back to it one day.

What's good about Angular? It is still in the top 3 of most popular JS frameworks and not without a reason. It has a rich ecosystem of external libraries for solving problems related to web applications, enterprise or not (state management, component libraries, internationalization, etc.), tooling to make it easier and automate what's repeatable (Angular CLI, schematics, and CDK), and an active community.

Another thing is its opinionated architecture and tooling. Components, modules, services, etc. are separate "architecture pieces" by design and our projects (with its file structure) should also follow this "modularity" defined by the framework. Angular also provides solutions for solving typical problems concerning web applications - making HTTP calls, handling forms, linting, creating unit tests, etc. (Although, you can always opt-out and use other things.)

Why is it good to use something opinionated, like Angular? Because some architectural decisions are just there, already defined, ready to use. We don't have to bother making things up and worrying whether they will prove useful in the long term. I personally know a team that decided to use Angular just because of that and Angular proved to be a perfect choice for them. After a couple of years of development, they are still satisfied.

What also I absolutely adore is Angular's TypeScript integration out-of-the-box. I believe in TypeScript and like to use it in every project.

What do I love about React?

Angular and React are fundamentally different things - one is a framework, other is a library. Angular provides us tooling and certain patterns that we have to follow in order to create applications. React is different, it handles only a layer of our applications, that is responsible for rendering the UI.

So, what is the first reason why I fell in love with React so that I decided to "abandon" Angular? The reason is... That React is NOT opinionated.

Now I stirred things up! Let me explain - being "opinionated" is a power, but also a curse at the same time. It depends on perspective. Some people would find it refreshing to be stripped of some responsibilities, like coming up with a technological stack or project's architecture. On the other side of the barricade are people who enjoy the freedom of choosing their perfect and polished stack and practices, refined over the years.

How does it look with React? The structure of our project, what tooling to use, how to make HTTP calls, which testing framework to use - things like that are totally up to us. Which approach is better? That depends. (Haha.) That depends on your needs, experience and overall "beliefs".

From my point of view, after 2.5 years of working in front-end, I feel I started to mature and to establish my own ways I want to do things. There is nothing more enjoyable for me than working daily with a stack you feel the most powerful. (Recently I fell in love with a NextJS + ChakraUI + Firebase + Cloudinary combination.)

I also fell in love with React's functional components. The sheer idea of components being functions from the state to UI is very simple and powerful. React Hooks also feel like a good way to encapsulate and reuse logic throughout your applications. (Although some people that think those are bloated and incomprehensible in large projects, but I'm too inexperienced to have my own opinion about that.)

The present and the future

Like you can see, there is nothing I despise about Angular. I just happened to be enchanted by the concepts behind React so much, that it felt like a natural switch for me.

What I want to do now is to dive into React's ecosystem more and more and work with some talented people at SoftServe and Mural who'll guide me into their ways of doing things.

Perspective-Driven (Self) Development

Kajetan Świątek — Mon, 11 May 2020 15:29:26 +0000

🎓 Introduction

Perspective-Driven Self Development is a learning idea that can potentially enhance the way you acquire knowledge with increasing your confidence and sense of reliability along the way. Warning! Step with caution! The fun coming from it is highly addictive!

Why "potentially", though? Because it is a way that may not be suitable for everyone. And it's fine! This is the way I do things personally and I wanted to share the concept with you. Nevertheless, you may approach things differently. The most important thing is to find a way that suits YOU best.

The principle itself is pretty simple and let me emphasize it:

Try out new things!

That's all, folks. ✋🎤

Well, I didn't discover anything new, did I? We, developers, are constantly attracted to new, shiny ✨ things, which can be both good and bad. But I want to state it boldly here - there's nothing wrong with that! It's fun! It's educating! It's practical!

⚡ Why you (should) use it

Speaking frankly, I'm fairly certain that you are already using this idea in your career as a tech person. You being here is enough proof! Reading articles like this, means that you saw it on Twitter or you follow my articles for some time (which would be pretty weird, because I don't think I'm that popular). That, in turn, means you strive to broaden your perspective by engaging someone else's articles, tutorials, researches, etc. You obviously want to improve and that's wonderful!

Perspective-Driven Self Development is beneficial because with a wider perspective you start to see patterns. You've probably noticed by now, that practicing one OO language makes you understand another one waaay faster. The same is with libraries or frameworks that serve similar purposes. The same might be with cloud providers, databases, architectures, paradigms, languages, etc. Let's call those "learning domains" from now on.

Wider perspective boosts up your confidence - you seem to have more answers on all kinds of different questions because you've tried all kinds of different things! You won't have all the detailed knowledge in the world in your head, that's obvious. Although, there probably was a time when you came across a very difficult problem but managed to solve it by remembering, that someone, somewhere, solved the same problem. The piece of code/article/video you may have seen a couple of weeks ago while rummaging through the internet can change the game.

Another thing is, that if you're just starting your journey in tech, this idea can help you get a sense of yourself. You'll start to get a hang of what are the things that bring you joy and you can just dive deeper into them.

It's worth to mention that Perspective-Driven Development is highly compatible with the Learn in Public concepts by swyx. While trying out new things and broadening your perspective you can use your newly acquired knowledge, e.g. build something fun and share it with others. You can do it via blog posts, talk at the meetup, a tutorial video - the floor is yours.

📜 Examples of learning domains

When you start learning databases, you could start with MySQL. Then learn Oracle or PostgreSQL because... reasons. But wait, there are all sorts of databases! Non-relational, temporal, graph, client-side (those are just random examples). It may be cool to try out something different and check out what are pros and cons, use-cases, what fits you best etc.

When starting with front-end development you have an enormously wide range of things you start from. This page lets you see just how wide ("overwhelmingly" seems like a polite understatement 😨). The simplest example might just be when it comes to JavaScript frameworks. Once you've squeezed everything you can from framework X, you can try out framework Y - you might just see how much faster it takes to learn it.

My personal favorite is a paradigm-shifting because it's the most challenging of them all. After years of learning one programming paradigm, it's hard to just shift your mind in another direction. The most popular example of that is learning FP after years of writing software in OOP (or another way around). After two years of programming in OOP (mostly Java and somewhat TypeScript) and learning all those principles (classes, inheritance, encapsulation, etc.) I've heard of this mythical Functional Programming and how complex but rewarding it is. I just couldn't help myself. I felt the challenge and couldn't wait to tackle this. After a year of learning FP, I still don't get a lot 😂 But I don't stop and every step forward feels rewarding. Let me tell you, when you feel excited just by a thought of trying out new things - you are a 100% follower of Perspective-Driven Self Development.

⚠️ Mind the downsides

Something can (and probably will) go wrong when practicing this approach. There may be a time when you devote your time to something and fail. An example of that might be discovering that some X bundler isn't as simple or "automagical" as it seemed and cannot be used for your project after two weeks of trying. But don't be discouraged - there's always some knowledge coming from a failure! The next time you test another bundler you might just know what to focus on and try it out in the early stages.

Far more dangerous is taking this idea too far. If you spend too much time trying out different things, you might end up knowing too little of your main field of expertise. E.g. focusing on knowing different frameworks might end up with knowing 20% of each and that's not healthy for your career. Another, much broader, example is differentiating roles at your workplace. Should one person be a business analyst, a developer, and a tester at the same time? It's great to have knowledge of what each role is and what are their responsibilities but you probably should not do their job. That's too wide of a perspective to acquire by one person.

🧘 Conclusion

Considering the last part (the downsides) I'd love to give you some personal, concrete piece of advice - a recipe, a golden ratio, let's say.

Pick up the learning domain you want to improve (e.g. JS framework), define the main branch that you should pursuit (like framework X, because you use it at work) and use 60-70% of your time to focus on that. The rest of the time you want to devote to the learning domain can be distributed among all other possibilities (framework Y, Z, etc.). It's healthier this way. Also mind that - the more you feel confident with your main learning domain, the more this ratio can drop, finding more time to learn new things.

Hell, what else can I say, you should just try it out yourself (if you don't already)! Happy learning!

Discriminating parts of a union type

Kajetan Świątek — Mon, 09 Mar 2020 16:25:50 +0000

⚡️ Originally posted on my blog - kajetan.dev ⚡️

Within this mini-series, my goal is to convey to you my modest philosophy on how to improve both as a TypeScript developer and software engineer altogether. I decided to use a specific example for that: improving one's TypeScript code by trying out something else, not considered "mainstream", like Elm.

I started by sharing with you the idea of Elm decoders and how they can be used in TypeScript.

Now it's time to dive into other features of Elm and what can we learn from them.

Pattern matching - a million-dollar feature

If you've used TypeScript before, you most likely came across switch-case statements. It's a quite useful tool in a programmers toolkit that enables check value of an expression against a specific case.

Let's begin with a simple example and build our way up. Here's an example of a case expression in Elm:

parseRate : Int -> String
parseRate rate = 
  case rate of
    1 -> 
      "Horrible"
    2 -> 
      "Bad"
    3 -> 
      "Mediocre"
    4 -> 
      "Good"
    5 ->
      "Excellent"
    _ -> 
      "INVALID RATE"

This is the most typical example I could think of but it lets you see for yourself how the syntax looks like. At the end, you can also see a default option that is handled by using a _ wildcard.

In most imperative languages that would be all we can squeeze from the case-statement. But Elm (and most of FP languages, in fact) can take it to another level. With it, you can match against even more complicated "patterns" like lists, tuples, records, etc.

We'll start building an example for this section now.

Let's assume, that our simple application loads a response from a server and renders it. The server can respond with either a successfully processed data (here, a simple integer value) or with validation errors. For that, we would like to define messages (actions that our application reacts to) and a model.

We can discriminate three different messages and we can do it with a union of types:

type Msg
  = Ok Int
  | Err (List String)
  | HttpError String

Also, we can create a corresponding model:

type alias Model = 
  { data : Int
  , error : (List String)
  , httpError : String
  }

The application can carry an Ok message, that indicates, that data has been fetched successfully. Another one is Err that can carry a payload as a List String (list of strings) - a list of validation errors that came as a result of our server-side computation. HttpError contains data about possible HTTP error.

Another thing is a Model that our view is based on. In an ideal world that's how our web applications should behave - it should be a function that takes a model and returns a view based on that model. That's what we shall assume here (for simplicity) - that the type Model represents both data that is carried by our application and also a view.

Next, we would like to have a function, that transforms our model based on a received message. For that we would like to react to all of three possible messages available. Surprisingly, we can use the good, old case expression for that:

updateModel : Msg -> Model -> Model
updateModel msg model =
  case msg of
    Ok data ->
      { model | data = data }
    Err es -> 
      { model | error = es }
    HttpError err -> 
      { model | httpError = err }

It turns out, that case expressions in Elm can not only be used against primitive types but also against more complex ones. It is thanks to a mechanism known as the "pattern matching".

With that we discriminate elements of a union of types, that is our Msg, and return modified value of Model. On Ok we replace a data field with response payload, on Error we pass a list of error messages to the model. On HttpError we pass an error message.

Wait, that's not all! Would you like to see some cool trick? Let's just delete one case and see what happens:

-- MISSING PATTERNS -------------------------------------------- Jump To Problem

This `case` does not have branches for all possibilities:

27|>  case msg of
28|>    Ok data ->
29|>      { model | data = data }
30|>    Error es -> 
31|>      { model | error = es }

Missing possibilities include:

    HttpError _

I would have to crash if I saw one of those. Add branches for them!

The project won't even compile! Compiler reminds us (very politely 😉) that there are some missing patterns that we didn't handle and we should change that. Elm is designed like that - with a bunch of little helpers built within a compiler that watch over us and our types. With those, we are able to avoid many troublesome bugs. More than that - it was always a crucial point for Elm to have as helpful and readable error messages as possible.

Unfortunately, JavaScript and TypeScript don't have a pattern matching feature. Even Elm's pattern matching is limited compared to Haskell, in favor of simplicity. But still - it is quite powerful.

Resources: Here you can read about pattern matching proposal for TS39 which is now at stage 1. Also, find out more about pattern matching in Haskell (this is a more advanced topic though).

Nevertheless, it cannot discourage us - let's get inspired and try to simulate those concepts in TypeScript! First idea you may think of (at least I did) is to use string literal types:

type Ok = 'Ok';
type Err = 'Err';
type HttpError = 'HttpError';

type Msg
  = Ok
  | Err
  | HttpError;

type Model = {
  data: int;
  errors: string[];
  httpError: string;
};

function updateModel(msg: Msg, model: Model): Model {
  switch (msg) {
    case 'Ok':
      // Well... What now?
    case 'Err':
      // Well... What now?
    case 'HttpError':
      // Well... What now?
  }
}

Unfortunately, we quickly realize, that it's impossible for a string literal type to carry some extra payload. One of the popular ways to discriminate types that hold some payload is to define them as JS objects with an additional field (commonly named type) that lets us discriminate object over the others:

type Ok = {
  type: 'Ok';
  data: number;
};

type Err = {
  type: 'Err';
  errors: string[];
};

type HttpError = {
  type: 'HttpError';
  message: string;
};

type Model = {
  data: number;
  errors: string[];
  httpError: string;
};

type Msg
  = Ok
  | Err
  | HttpError;

With that we are able to successfully discriminate union of types with a case-statement:

function updateModel(msg: Msg, model: Model): Model {
  switch (msg.type) {
    case 'Ok':
      return { ...model, data: msg.data };
    case 'Err':
      return { ...model, errors: msg.errors };
    case 'HttpError':
      return { ...model, httpError: msg.message };
  }
}

Done! TypeScript compiler even helps us by merging possible values of a type field from the union. When we hover over msg.type we get all possible values: (property) type: "Ok" | "Err" | "HttpError". This can help us when building the list of our cases.

But wait! What about a situation when we forget one of the possible cases like we did with the Elm example?

It turns out that when you omit some cases (and do not provide a default option) we get a compilation error of: Function lacks ending return statement and return type does not include 'undefined'. undefined? We don't want that in our function! This is a message for us that we missed a case and should add one.

Look out, though! There are some cases when that magic won't work and we will expose ourselves to unexpected bugs as a result. Above will work only if you have strictNullChecks flag turned on within your tsconfig.json (which I strongly encourage you to do!) and return type of your function is not undefined or void.

Fortunately, there is one interesting solution that is universal and works in all situations. It lets us leverage never type within our case expression:

function updateModel(msg: Msg, model: Model): Model {
  switch (msg.type) {
    case 'Ok':
      return { ...model, data: msg.data };
    case 'Err':
      return { ...model, errors: msg.errors };
    case 'HttpError':
      return { ...model, httpError: msg.message };
    default:
      assertUnreachable(msg);
  }
}

function assertUnreachable(x: never): never {
    throw new Error("Supposed to be unreachable...");
}

never is a type that:

"(...) represents the type of values that never occur. For instance, never is the return type for a function expression or an arrow function expression that always throws an exception or one that never returns."
~ TypeScript docs

Here, when we remove one case, for example the HttpError one, we get a compilation error of Argument of type 'HttpError' is not assignable to parameter of type 'never'.. It's because it is impossible to assign a value to type never, which has no values at all.

There is only one more thing worth noting. Discrimination of a union of types in TypeScript works only within the top-level fields of an object!

Resources: This blog post describes interesting quirks of a TypeScript, that are all worth to know. Among them are constraints that come with discrimination of union type I mentioned above.

Conclusion

Pattern matching is a killer feature of such languages like Haskell and PureScript and most of the developers wouldn't imagine working without it. It exist also in Elm and it lets us, for example, discriminate actions that occur in our applications.

Resources: If you want to read about pattern matching in Elm, you can find more at this section of "Beginning Elm" tutorial.

This is all for this part! This series turns out to be longer than I anticipated when I started conceptualizing it. Nevertheless, I hope that it'll turn out useful to anyone that wants to learn more about TypeScript and/or consider trying out some other languages (with stronger type system).

Thanks for reading and see you next time!

Type safety at runtime with JSON decoders

Kajetan Świątek — Wed, 12 Feb 2020 16:22:02 +0000

⚡️ Originally posted on my blog - kajetan.dev ⚡️

I imagine what you may think right now after reading name of this blog series - "Dude, you're crazy! TypeScript is complex on its own and you just said that I should learn another language? Forget it! I revoke the subscription!".

Let me explain first what is the purpose of this article before you actually do that. Seriously, don't, please.

😉

What's the purpose? 🤔

I use TypeScript daily and I think it is beneficial to sharpen your tool as good and as frequently as you can. For this, I seek means to improve my work and my understanding of deep-down mechanisms. Along the way, when you have enough understanding of a tool, you may want to try another one. This way you can experience something new and compare it with your previous knowledge. The findings are often surprising!

The same goes for programming languages. When the time comes, you'd probably think about learning something new. Who knows - maybe that new tool may become your new favorite...

Basically, what I want to tell you is:

Knowing your tool is as important as developing a different perspective.

There was a time when I wanted to learn something new and enter this yet-again-hyped "functional programming train", so I decided to learn Elm. This front-end language is recommended for all people with a JavaScript background, so it suited me perfectly.

It turns out, that I didn't fall in love with Elm (I like it though!), nor I want to use it everywhere from now on. Nevertheless, I came to some interesting conclusions and gained a different perspective on the tools I was using earlier.

In just a second I'll share with you just how knowing Elm lead me to writing better TypeScript code.

Disclaimer: I don't want to promote myself as being an Elm expert. The truth is that I fiddled with it only for a couple of weeks by creating a small project. Even though, if you have any questions, you are more than welcome to ask 😊 In the worst case - I would just admit that I don't know, fairly embarrassed! 😧

Type-checking - know the quirks 🚩

How you can call yourself a true master of given language if you are not aware of its downsides? And let's be honest here - TypeScript is not perfect. It is a weird case though because a lot of its quirks come from the fact that:

In the end, TypeScript compiles down to JavaScript.

That means, that after the compilation phase, we forget about all the types, interfaces, etc. we created during our work. The powerful type system delivered by TypeScript is thrown away and that may lead to all sorts of bugs and inconsistencies during runtime.

The simplest example is handling HTTP responses from REST API. Let's imagine a simple function that returns data on a planet using Star Wars API:

function fetchFilm(filmId: number) {
  return fetch(`https://swapi.co/api/films/${filmId}`)
    .then((res => res.json());
}

Having this function written like that, the type of the function is inferred to be number -> Promise<any>. We can do better with our types!

// We create an interface for our expected value:
interface SWFilm {
  title: string;
  episode_id: number;
  opening_crawl: string;
}

// We specify the type of our output:
function fetchFilm(filmId: number): Promise<SWFilm> {
  return fetch(`https://swapi.co/api/films/${filmId}`)
    .then(res => res.json());
}

// Let's simulate some operation being done to our fetched value:
fetchFilm(1)
  .then(film => console.log(`${film.opening_crawl.substring(0, 40)...}`))
  .catch(console.error);

// OUTPUT: It is a period of civil war. Rebel spac...

Yup, we are safe now! Both TypeScipt compiler and other developers reading the code know what is the expected type of fetchPlanet's output.

Should we really feel safe, though?

What if our app runs happily on the production and the external REST API changes its model without a notice? What if we don't talk to our back-end developers anymore and they are the ones that changed the model? (No, really, talk to each other! 😏)

In our case, if the opening_crawl field may change to a camel case notation (obviously!) and we are prone to receiving everyone's favorite TypeError: Cannot read property 'substring' of undefined!

What we realize pretty quickly then, is that:

TypeScript does not provide any type-checking during runtime.

Many people starting with the language have the wrong impression of how the TS compiler works and don't know about that important fact.

What can we do then? We can do simple type checking:

fetchFilm(1)
  .then(film => {
    if (film && typeof film.opening_crawl === 'string') {
      console.log(`Opening: ${film.opening_crawl.substring(0, 40)}...`);
    } else {
      throw new Error('Wrong type, dude!');
    }
  }) 
  .catch(console.error);

In this case, it's not all that bad. But what if we have to check if the entire object is compliant with the interface we've created? That may prove to be tedious 😧

A solution to our problem may lay in the common mechanism in Elm - JSON decoders.

JSON Decoder is a function that takes data in JSON format and extracts specified fields from it. Let's see how this looks like:

import Json.Decode exposing (decodeString, int)

decodeString int "4"     
-- OUTPUT: Ok 4 

decodeString int "haw haw"     
-- OUTPUT: Err ...

Like you see, nothing to be afraid of. Firstly, in Elm, we don't use parenthesis when calling the function. decodeString is a build-in function for decoding strings in JSON format. It accepts a specific decoder and the value to be decoded. int is a primitive decoder for integers, so what we're doing above is trying to parse two strings to an integer. As you see, one attempt is successful and the second is not.

We now know how to parse primitive values. What about JSON objects? For that we have to create the appropriate decoder ourselves:

Disclaimer: We won't dive into too many details in our examples (considering that this may be your first time seeing Elm code) but if you want to check it out for yourself, I'll provide you with appropriate resources. I'll just try to keep the examples as simple as I can 😉

import Json.Decode as Decode exposing (Decoder, int, string)
import Json.Decode.Pipeline exposing (required)

type alias SWFilm =
    { title : String
    , episode_id : Int
    , opening_crawl : String
    }

swFilmDecoder : Decoder SWFilm
swFilmDecoder =
    Decode.succeed SWFilm
        |> required "title" string
        |> required "episode_id" int
        |> required "opening_crawl" string

Resources: You can find more specific information on how to use and create decoders by reading section of Beggining Elm tutorial or docs for the NoRedInk/elm-json-decode-pipeline package.

Firstly, we create type alias for SWFilm, similar to the interface created with TypeScript.

When comes to creating a decoder, in a typical manner for Elm, we first declare type and then define the body of a constant or a function.

We could interpret the body of a swFilmDecoder as listing out required fields for our SWFilm type and their types individually. By doing that we compose more primitive decoders, like string : Decoder String, to create more complex Decoders for more complex data structures.

Then, if we want to recreate our previous fetchFilm function, it would look like that:

import Http

fetchFilm : String -> Cmd Msg
fetchFilm filmId =
  Http.get
    { url = "https://swapi.co/api/films/" ++ filmId
    , expect = Http.expectJson toMsgOnSuccessOrError swFilmDecoder
    }

Resources: You can find more information on using Http module and creating HTTP requests by reading section of Beginning Elm tutorial or reading the official guide.

With this, we create command (that's the meaning of Cmd Msg in the type signature) for Elm runtime for running HTTP GET request for given URL and expecting response body to be in JSON format. We also specify that JSON we receive in the response should be compatible with SWFilm type by providing our swFilmDecoder.

The most enigmatic thing here is probably toMsgOnSuccessOrError function. I won't dive into it too deeply, because that is not the point here. Let's agree, that this custom function should create an appropriate message to the Elm runtime after parsing JSON through the decoder - whether it succeeds or fails to do so.

By creating HTTP client this way, we are basically enforced by the type system to create not only a decoder that checks our JSON structure but also a concrete function that reacts to success or failure of the decoding process (here toMsgOnSuccessOrError). And that's what is missing in our TypeScript code.

Should we build that kind of system in TypeScript by ourselves? We certainly can if we have a specific idea in our minds. But for most use cases, there already exist some packages that may suit our needs! There's a lot of them actually, for example io-ts or ts.data.json packages.

Resources: You can find more about the idea of JSON decoders in TypeScript by reading Typescript and validations at runtime boundaries article by @lorefnon.

Let's take ts.data.json as an example because it is the smallest one and brings the idea of validation of a JSON string in the simplest way (io-ts seems to be the most popular one, though). With this package we create our decoder in TypeScript like that:

import { JsonDecoder } from 'ts.data.json';

const swFilmDecoder = JsonDecoder.object<SWFilm>(
  {
    title: JsonDecoder.string,
    episode_id: JsonDecoder.number,
    opening_crawl: JsonDecoder.string
  },
  'SWFilm'
);

Then we can use it in our fetchFilm function:

function fetchFilm(filmId: number): Promise<SWFilm> {
  return fetch(`https://swapi.co/api/films/${filmId}`)
    .then(res => res.json())
    .then(film => swFilmDecoder.decodePromise(film));
}

That fits perfectly with our use case! We are now 100% sure that if something wrong will come from the REST API, we can handle it. decodePromise just returns our film wrapped in a new Promise when parsing succeeds. In case of failure, the decoder would throw an error with a pretty readable message: e.g. <SWFilm> decoder failed at key "opening_crawl" with error: null is not a valid string.

(Do you see it redundant that we create both interface and the decoder definition that looks basically the same? Yeah, me too 🙁 But don't you worry, some packages, like io-ts, provide you with a way to define decoder and create a type definition based on that decoder with only one line! 😎)

And we're done! With this solution, we don't have to worry about type errors in runtime and are able to handle them gracefully 😉

This is the end of part one of this mini-series on using Elm to improve your TypeScript! Stay tuned for another article that (hopefully 😛) will come soon!

How I started learning Functional Programming

Kajetan Świątek — Mon, 27 Jan 2020 19:43:12 +0000

There was a moment when I declared on my blog, that I’ll share with you how and why I decided to dive into Functional Programming. And that day is today! I’ll guide you along the path I took to understand basic concepts of FP.

The beginning

My first meaningful encounter with FP was during local Wrocław TypeScript meetup. There I got to hear Józef Flakus telling us about core concepts of the FP. We then got to the concept of FRP and how it is used in MarbleJS, the framework for creating server-side apps. In fact, Józef is the creator of this framework. It was really cool to hear his point of view. Those concepts were entirely new to me, because (as it turned out) I had 100% imperative programming mindset.

The second talk that day was authored by Tomasz Ducin. He showed us how we can implement functional composition in TypeScript. It was a brilliant live coding session but… I had no idea what he was talking about 😉 I was examining code created by Tomasz for the entire next day until I fully understood what was going on.

But those talks did it for me. Something clicked and I started diving into FP world step by step for the next couple of months.

My first resources

The first thing I did was looking into Awesome GitHub repository looking for some basic FP articles or videos. And I was not disappointed. I found two interesting sites: Awesome Functional Programming and Awesome FP JS. There you can find many reliable resources, but many of them seem really hardcore for people starting with FP, so tread carefully.

There are also a couple of honorable articles/videos/tutorials that I want to share with you.

>> “Don’t fear the monad” talk with Brian Beckman

To this day I remember watching the video with my jaw dropped. The hour just wasn’t enough! Brian is a brilliant man with an extraordinary skill to attract a listener. He can explain difficult concepts with a couple of words and in a fun way. Watching this video just deepened my fascination with the subject.

>> “Haskell is useless” – talk with Erik Meijer and Simon Peyton Jones

Talk with two designers of Haskell language on a position of Haskell in the programming world. There we can also get an explanation of the famous diagram of how imperative and declarative languages relate to each other.

>> LambdaCast podcast

It took me a couple of weeks of listening to all the episodes but man, it was so worth it! For around 20 episodes podcast’s hosts and guests explained the core concepts and principles of FP in an approachable way. Just a flawless way to start learning for people with no prior knowledge, like me.

>> Functors, Applicatives, And Monads In Pictures

Another way to approach the problem of learning something new – through visualization. That’s the resource I come back to most frequently due to its simplicity.

>> “Functional programming design patterns” talk by Scott Wlaschin

Insightful and fun talk on how FP relates to OOP’s principles and patterns.

>> “Mostly Adequate Guide to Functional Programming (in JS)” book by Brian Lonsdorf

That is my favorite resource on this list. If you have a JavaScript background (like me) it’s an excellent tutorial. Due to being a multi-paradigm language, it’s super easy to explain FP using JS. I took my time with this book thoroughly re-reading chapters and examining examples. I think nothing else deepened my knowledge of the topic like this book, especially due to many practical examples. I recommend reading it through GitBooks – there you can do all the exercises inside your browser, without cloning the entire repository.

Those are the most important resources I found to this day about the FP. If you know other interesting resources, don’t hesitate to share them with me and others 😊

For the last part, I would like to give you some advices, which might just save you time googling 😉

Which language to pick to start my journey with FP?

I think there is no bad answer here. You should think about what you would like to do build the language first. If you want to create some web application – maybe try Elm. I personally started with Elm and I’m creating some simple recipe app as an exercise.

If you want to create for the web you might as well use Elixir, which can handle both front-end and back-end with its own Phoenix Framework. If you want to dive deep into the theory of FP you can use PureScript (which is my next personal pick) or Haskell. (PureScript seems more attractive to me just because it compiles to JS and uses the same ecosystem.)

If you have JS background and don’t want to learn any new language you can use FP libraries for JavaScript (Ramda) or TypeScript (fp-ts). There are also JS frameworks that use FP for building for the web, e.g. MarbleJS (REST API) or CycleJS (web apps).

Why should I even be interested in FP?

There are a couple of reasons:

Functional means declarative - declare what want to do, let the compiler do the rest. I find FP programs to be much more descriptive than others.
FP ensures immutability. Once created, variables cannot be changed. With that, you can forget about constantly passing reference to an object and mutating it unknowingly along the way.
Functions are like building blocks - you can have a lot of them, with any shape you want. Just start building, like with Legos.
Pure functions help in preventing bugs. Just imagine having no unexpected behavior for your functions – isn’t that neat?
FP simplifies your unit testing. Having most of your functions pure makes simpler test scenarios and ensures test separation.
It broadens your mind and lets you try new things. It gives you a new perspective and makes you a more reliable engineer. Switching mindset like that is a great challenge for any developer.
FP technologies are growing like never before. They’re becoming popular and you can see them more in production applications. Companies are also looking for people with knowledge of FP more often.

I reviewed all the resources you provided - what should I do next?

Well, I have no idea, I just got there myself when writing this 😉 I’m sure I’ll share with you guys anything interesting I’ll learn.

⚡️ Originally posted on kajetan.dev ⚡️