DEV Community: Tomasz Cichocinski

How Trying New Programming Languages Helped Me Grow as a Software Engineer

Tomasz Cichocinski — Sat, 22 Oct 2022 23:13:13 +0000

When you use one programming language daily in your job as a Software Engineer, it's easy to fall into the trap of that language bubble. I want to show you how stepping outside your comfort zone and learning new languages and paradigms helped me grow as a Software Engineer.

Over the years I've transitioned from frontend developer to full-stack developer and even tried professional game development! In that time, I managed and mentored developers at different stages of experience.

Let's get right into it!

Your primary programming language

There are dozens of programming languages out there. In a lot of the cases we, as programmers, get fluent in one. Every so often, it's the first language we were taught in college or bootcamp. Maybe a more experienced friend recommended his favorite language to us. Or perhaps we had dreamt about making a specific type of software like video games and picked the most popular technology in the specialization. Once we land our first job, experience skyrockets.

For me, JavaScript became my primary language and stays to this day. It wasn't my first language, but it was the most accessible for me during high school when I could write and run it on basically every computer without any special compiler or IDE.

Stepping outside comfort zone

When still in high school, I got more and more experience creating many toy projects. From simple games to more complicated ones like "2d game engine" as an Electron application.

Because of some of my programming teachers, I had a feeling that JavaScript is not a “real” programming language. In addition, it was JavaScript in the frontend environment, so you know, moving divs and buttons around, not algorithms.

Around that time, I got introduced to Elixir by one of my close friends. I remember I was binge-watching conference talks about it for a week straight. It got me so inspired. It's a backend language and frontend was my natural environment, so it wasn't an easy thing to grasp for me at that time.

Fortunately, functional programming, stuck with me.

It started a spiral of new languages' fascination. Over the years I had programmed as a hobby or professionally with Elm, ReScript (formerly known as ReasonML or BuckleScript), OCaml, Haskell, Scala.

I was still working with JavaScript almost daily, but learning so many new concepts like immutability, statelessness, monads, algebraic data types or actor model, made solving problems easier. It even helped me give a lightning talk at international conference!

And because certain concepts are more popular in different communities, it exposed me to so many programming architectures and patterns found in different kinds of systems like DDD (Domain-Driven design) or Category Theory.

Going back to junior level

Fast-forward to March 2022, when I left my job at jam.dev as an Engineering Lead.
I decided I need a break to figure out what's the next thing I want to pursue in life.

Since my early days with programming, I was always fascinated with video games and computer graphics. Back in high school I was experimenting with OpenGL, later with ray tracing and during last year's Christmas I started implementing Physically Based Renderer in Vulkan and Rust as a side project.

During my first month off, I got back to that Vulkan and Rust project. Working on it, I came to conclusion what I want my next job to be: Graphics Programmer. But it's not an entry-level job if you don't have experience in this field. And because game development is the closest thing I could think of, I decided I'm doing to recruit to the local game dev company in Kraków where I live.

I asked my friends about learning materials, and immediately dove into the world of C++ and Unreal Engine! It took my two weeks to complete Tom Looman's Unreal Engine C++ course (which is incredible, I highly recommend it if you want to level up with Unreal Engine). I did a lot of reading about C++ and game development environment, made some simple game with SDL and after 2,5 months after quitting my Engineering Lead job I started my journey as Unreal Engine C++ programmer.

Tomasz Cichociński

@_cichocinski

I’m dropping web development and going into game development soon! 🤞🎉

12:22 PM - 27 May 2022

I was expecting landing in junior position, and I wasn't concerned about salary. Surprisingly, I met requirements for a regular level 🤯. It turns out, general programming knowledge and years of experience with different technologies build up quite nice job profile 😅

I'm no longer working at that company. I haven't renewed my contract after probation period. Therefore, I'm also not pursuing graphics programming as a career. But that's a story for a different time.

Try something new!

It's completely fine to deepen one technology or one programming language knowledge. It's totally fine to just have a 9-5 job that pays the bills.
But if you aim to level up, I'm highly recommending trying something new to broaden your perspective.

If you're writing JavaScript, try some functional language like Elixir or ReScript. If you're already familiar with high level, garbage collected languages, try something low level like Rust or even C/C++. Play with different concurrency model like coroutines or actor model.

You don't need to change your job, you don't need to ship products with it. Try to create something fun. You'll thank yourself later.

If learning new programming language gave you a new perspective or opened some doors, don't hesitate to share your story on Twitter!

I'm available for a free mentorship!

Tomasz Cichocinski — Thu, 13 Oct 2022 22:29:13 +0000

Hi! I'm Tomasz Cichociński 👋

I have over 7 years of professional software engineering experience.

I want to share my knowledge to empower juniors to become remarkable seniors! I'm offering a free mentorship, no hidden costs, it's my voluntary work!

Do you feel you need help with your career? Or maybe you're stuck with some technical challenges?

Learn more at: cichocinski.dev/mentorship

Using Default Exports Makes JavaScript Harder to Read!

Tomasz Cichocinski — Wed, 12 Oct 2022 19:52:25 +0000

In this blog post, I would like to show you how using JavaScript export default hurts your codebase readability and refactorability. I'll also share some tips for using named exports!

I like to treat my code as a clay, it's constantly evolving when I'm adding new features or changing existing ones. But using default exports not only makes it harder, it also adds complexity when using already existing code!

Allow me to explain my reasoning!

You can export anonymous functions and values

The first major problem with default exports is naming. You have to think about name import every time you include it. Not only that, but you're not forced to come up with a good name when creating a new function, as it's allowed to export anonymous values.

Let's take a look at this simple JavaScript file:

// cookies.js
export default () => {
  // baking 🍪 cookies logic
};

// app.js
import makeChocolateChipCookies from "./cookie.js";

You have no idea what your default exported function from cookies.js does. Of course, you can peek into the implementation or count on documentation, but it's definitely adds way more cognitive load. You cannot spot right on what's that function is supposed to do.

That forces you to think about naming that function in every place you want to use it. And naming things is hard. Maybe you wrote that function yourself, you know exactly what it's doing. But if you have a new team member joining, it's much harder for them to understand what this function is doing.

That can also leads to other team members picking up different name when working on new features or refactoring existing code. And consistency and convention is a key for high performing teams! You can suggest a different name in the code review, but it's adding that complexity which could be easily avoided in the first place by using named exports.

It's awkward when importing all from module

JavaScript's import allows you to import everything from the module using import * as X syntax. And default export is just available under default.

// app.js
import * as Cookies from "./cookie.js";

// usage - yikes
Cookies.default();

Of course, if you export one thing it's not that important as you most likely won't use import * as X. But you may want to group multiple things you import by module name for readability.

While I really love grouping module functions, and I think it's really
excellent practice for readability, it may not always be optimal for tree
shaking and may increase your bundle size!

Default exports and folder-based routing

Frameworks like Next.js or Remix force you to use default exports to define components with the folder-based routing. I'm not a big fan of forcing default exports in any case.

TypeScript is lacking at this point some kind of support for "template" style exports, where a single file can export a predefined set of optional named exports in addition to the main default export. I would love to see something like that included in the language in the future, based on the popularity of previously mentioned frameworks.

Using named exports

Export each function individually, or export everything at once?

Syntax allows you to use export keyword before each function, type or value.

export function makeCookies() {
  // baking 🍪 cookies logic
}

It's also possible to have export multiple things at the same time:

function makeCookies() {
  // baking 🍪 cookies logic
}

function eatCookies() {
  // eating 🍪 cookies logic
}

export { makeCookies, eatCookies };

I tend to prefer first approach as you clearly see whether the function you're reading is exported or not.

Named export alias to the rescue

When you really need to use a different name, named exports allow named export aliases.

// cookies.js
export function makeCookies() {
  // baking 🍪 cookies logic
}

// app.js
import { makeCookies as makeCookiesWithStyle } from "./cookie.js";

Conclusion

Even though we have ES2015 (ES6) for quite some time already, I see a lot of default exports in all types of applications. They were introduced for CommonJS interoperability, and there is not much reason to use them in the internal code. I hope this post will help you convince your team not to use default exports when it's possible.

If you have some default exports refactoring horror stories, don't hesitate to share them on Twitter!

Resources

List of resources I used when researching this blog post:

Improve your TypeScript with union types!

Tomasz Cichocinski — Tue, 11 Oct 2022 12:13:04 +0000

TypeScript's unions are a powerful feature. Let's dive into what they are and how you can use them to your advantage!

What is union type?

Union type is a set of types that are mutually exclusive. The name union (or sum type) comes from type theory. According to Wikipedia definition:

The sum type is a “tagged union”. That is, for types “A” and “B”, the type “A + B” holds either a term of type “A” or a term of type “B” and it knows which one it holds.

And in TypeScript it's similar to type theory (as programming has a lot in common with set, type, and category theory). Let's look how official documentation defines union type:

A union type is a type formed from two or more other types, representing values that may be any one of those types. We refer to each of these types as the union’s members.

The most basic union type consists of two primitive types:

type Union = number | string;

// defined as inline type
function getUserById(id: number | string) {
  // ...
}

This allows to handle value which can be either number or a string. This is great to prove code is type safe for all possible cases!

In this guide, I'm not going to discuss null and undefined and how by default they are assignable to anything. Please do yourself a favor and start using strict or at least strictNullChecks.

When to use union type?

Union types are perfect to express a finite number of known options, either primitive literals or objects (as discriminated union which we'll discuss those later), where single logic has to handle all the possible cases. A few great examples where union types shine are:

finite state machines (like React's useReducer)
event names
object fields (using keyof keyword)

You shouldn't use union types where the amount of possible options is too large, for example, a person's name as there is basically infinite number of options. Also keep in mind, they exist only at type level. They are striped out during compilation.

How to narrow union type?

If your function logic can work most of the time on union type, it's great. But sooner or later you'll need to narrow it down to a specific union member. There are few common patterns when narrowing union type.

Using `typeof` keyword

typeof Keyword is the most basic TypeScript tool. Unfortunately, it will work only with string, number or function

function getDateFullYear(date: number | Date) {
  if (typeof date === "number") {
    return new Date(date).getFullYear();
  }

  return date.getFullYear();
}

Using `instanceof` keyword

While typeof works great with primitives, instanceof is great for the OOP feature of TypeScript — classes.

class Developer {
  public develop() {
    // ...
  }
}

class Manager {
  public manage() {
    // ...
  }
}

function work(person: Developer | Manager) {
  if (person instanceof Developer) {
    person.develop();
  } else if (person instanceof Manager) {
    person.manage();
  }
}

There is more OOP way of implementing work function, but above example should do the job as well.

Using `if` or `switch` statement

Because union types can also consist of literal type members, not generic types but specific values, it's easy to use switch or if statements on them.

function getTextColor(theme: "dark" | "light") {
  switch (theme) {
    case "dark":
      return "#ffffff";
    case "light":
      return "#000000";
  }
}

const textColor = getTextColor("darkk");
// 🛑 Argument of type '"darkk"' is not assignable to parameter of type '"dark" | "light"'.(2345)

String literals are really helpful for specifying a limited set of possible options, similar to enum
being a great replacement for them, as there is not that much of added complexity as in enum's case. Using union type of string literals will help not make typos or passing generic string.

When you need to narrow type down from string to string literal, you can use a type guard function, we'll discuss later in this post!

Using “pattern match” object

When talking about string or number literals, there is great trick allowing to achieve "pattern matching" in TypeScript:

function getTextColor(theme: "dark" | "light") {
  return {
    dark: "#fff",
    light: "#000",
  }[theme];
}

At first, it may look noisy, but the advantage of this solution is the fact it's an expression not statement, which may be sometimes required in places like in JSX.

Using type guard function

One nice but advanced feature TypeScript provides us is the ability to define a custom type guard function. By default, TypeScript provides us with built-in type guards like typeof, instanceof keywords we discussed earlier. There is also Array.isArray() which is really handy when we need to handle either a single value or multiple values of the same type.

But sometimes it's required to write something more specific to our business logic.
Let's take a look at a simple function that narrows any string to either dark or light:

type Theme = "dark" | "light";

function isTheme(value: string): value is Theme {
  return value === "dark" || value === "light";
}

function getTheme(value: string): Theme {
  if (isTheme(value)) {
    return value;
  }

  // default case
  return "dark";
}

This is helpful when your value is coming from outside world (API or used provided) and you cannot be sure it will be always within your expected range.

Not only primitive types

Union types are not limited to primitive types or type literals. They can as well be objects. I'm using the following pattern all the time as a TypeScript's equivalent of algebraic data type (ADT). It's a great pattern to express values which may contains different payload or same payload interpreted in different way.

type Event = Credit | Debit;
type Credit = { type: "credit"; amount: number };
type Debit = { type: "debit"; amount: number };

let account = 0;
function handleAccountEvent(event: Event) {
  switch (event.type) {
    case "credit":
      account += event.amount;
      break;
    case "debit":
      account -= event.amount;
      break;
  }
}

handleAccountEvent({ type: "credit", amount: "10" }); // account == 10
handleAccountEvent({ type: "debit", amount: "5" }); // account == 5

Conclusion

I hope you understand union types better! With all that knowledge and all the TypeScript features now under your belt, you can take advantage of them when working on the next great feature!

Resources

List of resources I used when researching this blog post:

5 reasons why destructuring and inline types hurt your TypeScript codebase

Tomasz Cichocinski — Sun, 09 Oct 2022 19:42:34 +0000

Recently I've seen a tweet by Jamie Kyle about using destructuring, default params, and inline types:

Jamie Kyle 🏳️‍🌈

@buildsghost

Maybe this is controversial, but this is why I don't use destructuring, default params, inline types, etc.

All this or:

enqueueMessageForSend(
message: MessageDetails,
options: MessageOptions,
): Promise<Message> {...}

20:18 PM - 03 Oct 2022

That tweet and a few React components I have seen recently in my day job inspired me to write this blog post. I want to show you how using destructuring and inline types makes your TypeScript less readable!

How TypeScript function definition look like?

In JavaScript and TypeScript, you can define a function either using function keyword or lambda/arrow-function. Both ways are valid, but have their differences. Let's take a look at the simple sendMessage function. Implementation logic is not relevant to us.

// sendMessage function written using `function` keyword
function sendMessage(message: string) {
  // function logic
}

// same sendMessage written as arrow function
const sendMessage = (message: string) => {
  // function logic
};

When function definition is quite simple, the function accepts a few params of a different type. If they are primitives like strings or numbers, everything is readable.

Let's say you want to pass some additional information alongside your message content to the sendMessage function.

function sendMessage(message: {
  content: string;
  senderId: string;
  replyTo?: string;
}) {
  // you can assess content using `message.content` here
}

As you can see, TypeScript allows you to write an inline type definition for the message object you want to pass without specifying the type using type or interface keyword.

Let's add destructuring. When you pass a large message object to your function, TypeScript allows breaking apart passed arguments to reduce the code boilerplate of repeating message variable many times.

function sendMessage({
  content,
  senderId,
  replyTo,
}: {
  content: string;
  senderId: string;
  replyTo?: string;
}) {
  // you have access to `content` directly
}

Why I think it's a bad idea and how you can make it better

It may look like a nice idea, after all, you don't need to write message that many times, right? It turns out it's not that great. Let's talk about 5 reasons why I think it's an antipattern.

1. You're not sure where your data is coming from

When you're reading the function body, and you see senderId you have to double-check to be sure from where that function comes. Is it passed as an argument or calculated somewhere in the function?

2. It's hard to write documentation

There is no natural place to write documentation comments when all the types are cramped with destructuring in the function definition. You could write comments between each type field, but that makes the whole function definition even longer. It's actively discouraging you from writing a quick summary of the data you're passing.

3. It's hard to pass that data forward

When your data is destructured you need to structure it again into a new object if you want to pass it forward. This discourages creating smaller helper functions and relying on composition to build up your main function logic.

4. You cannot reuse argument types outside this function

If you need to reuse your function arguments in helper functions when composing your main function logic, you must type the same set of types repeatedly. This makes it easier not to write types at all.

5. It just takes a lot of space

Let's face it. It's just a lot of lines of code that take up a lot of screen space. And in addition, it focuses on implementation detail – the inner type of the arguments you are passing to a function, which is most of the time not relevant when you're looking at that function.

Just create type for it

Extracting the type and placing it right above the function makes it much more readable. There is a place for documentation comments, you can reuse that type in some other helper function and change the type definition in one place if needed.

/**
 * Message to send using XYZ API
 */
export type MessageToSend = {
  /**
   * Markdown string of the user's message
   */
  content: string;
  /**
   * Id of the sender user
   */
  senderId: string;
  /**
   * Other message ID if this is a reply
   */
  replyTo?: string;
};

function sendMessage(message: MessageToSend) {
  // function logic
}

function getUserIdsToNotify(message: MessaageToSend) {
  // function logic
}

Resources

List of resources I used when researching this blog post:

https://www.typescriptlang.org/docs/handbook/variable-declarations.html#object-destructuring

Types of devs

Tomasz Cichocinski — Mon, 25 Jan 2021 23:20:08 +0000

There are few types of developers I've encountered throughout my programming career:

over-engineering devs

They care only about engineering, system architecture but not really about the business of the created application. They like to talk about using advanced patterns like event sourcing, actor model, using message broker or message queue just to implement a simple to-do list.

happy path = done devs

They care only about the happy path. Making PM/CEO/client happy, especially if the person they are reporting to has no idea about the technical side of building things. They copy-paste existing code, add new fields to data models, and don't bother thinking twice about the consequences of their changes. What matters is just covering one simple case they have in their task.

let's try that new shiny OSS library devs aka hype devs

As soon as there is a possibility to add a new dependency or blame slow performance/bugs on not so trendy library the project currently uses you know they will be the first to jump to rewrite existing code and burn old to the ground. Especially if the new library is few days old and just blows up on Twitter gaining few hundred/thousands stars in the first few days.

so we're creating user-facing application devs

This is a special breed of backend developers that only care about data, security, system architecture, system resilience, fault tolerance, containers, and Kubernetes. Super happy when writing new services to cover business logic (the more complex the better) but they are disgusted when asked to expose API for "frontend" or implementing something even remotely close to user-facing UI.

let's write that ourselves devs

Screw that OSS library everyone uses. Sure it has hundreds of contributors is used by a lot of companies in their core products but we should write that ourselves to have 100% control. Yeah, sure...

we should have eslint for that devs

This special kind of developer creates the most impossible eslint rules to fix the JS. Ban half of the language, force conventions, have 10 times more eslint config than actual code.

endofunctor devs

Freshly after reading about category theory just have to use that Kleisli composition in your codebase. And not forget about using all of the possible custom operators to express even the simplest business logic.

We all probably know some of those developers and can recognize our colleagues among them. We can even make fun of them, but the truth is - we all should take the good parts from each one of the above and balance it. This is what makes us better developers.

TIL: React Server Components

Tomasz Cichocinski — Wed, 30 Dec 2020 02:04:07 +0000

After being late to the party I've finally watched the React Server Components introduction from the React team. Here are my thoughts.

In recent months I felt a need to explore more "traditional" ways of doing web apps. More server rendering, less client-side logic. In my case mostly the Phoenix framework and Phoenix LiveView (it's great). It's really good to see more and more movement in that direction in the React community (with recent additions to Next.js) and from the React Core team itself.

I think current React development is really complex and requires a lot of work with separate backend and frontend "services" and REST/GraphQL API to connect both. If you're using a framework like Next.js and/or your team is full-stack it's much easier because you probably share the same codebase and technology you work in. But that doesn't reflect your application. Still, only the first render of the page happens on the server. With React Server Components you'll get more tools at your disposal to create a better experience for your users.

Knowing that I'm also kind of worried about the complexity of those things. "With great power comes great responsibility" right? For example, React Hooks were a great addition to React and made hard things easy, but also made easy things hard. With React Server Components we won't be talking only about React components and their state or effects but also about their runtime. If this is a shared/server/client component? Will there be a different behavior on server and client? And I'm 100% sure devs will do weird things with direct Node access inside server components. For sure TypeScript and the ungodly amount of Eslint config will make it work great but that's a good thing to keep in mind.

ReasonML – My Best Practices

Tomasz Cichocinski — Sat, 25 Jan 2020 22:51:04 +0000

Programming is constant learning. Improving your skills, learning new things, establishing best practices. I want to share a few best practices I developed based on my experience in various Reason projects. Some of those are BuckleScript specific and some of them apply to Native ReasonML development as well.

This post contains only a list of few that I find important in my projects but Leandro Ostera collected a great set of design patterns and best practices: https://github.com/ostera/reason-design-patterns - definitely check them out!

In this article I want to focus on the following patterns and best practices:

Project structure
Creating data modules to hide your implementation details and place your logic in one place
Always defaulting to Belt
Using Pipe first

Project structure

It's an adoption of Yavar Amin's Project structure but adjusted to my needs and project size. I highly recommend reading the mentioned article.

My setup is very similar. I try to divide my application into business entities and build folders structure around them. Let's take a basic blog application as an example. First thing every blog application needs are posts. Because of that src/post would be my first folder with a single Post.re in it. ReasonML module system is folder agnostic so I don't have to import it in any of my other modules - Post is available globally. That module would have one main purpose - providing a clear list of all submodules that are available for use outside of src/post.

Alongside Post.re I would have Post_Query.re reexporting all my GraphQL queries like Post_Query_Single.re or Post_Query_List.re. If you're using REST instead of GraphQL the same applies. My React component could be Post_View_Single.re containing single post logic. It would be reexported in Post_View.re and then in Post.re for usage in other parts of the application.

In the future, when the application would grow I could add comments functionality with src/comment and Comment.re reexporting all my other modules: Comment_View.re, Comment_View_List.re and Comment_View_Single.re.

I found this structure work well in medium size with projects - between 200-300 files and 20-30k lines of code. None of my applications surpassed that numbers so far. If any of them will get bigger and this structure will become hard to maintain, I'll think about changing it. There is no need for prematurely optimizing it as ReasonML gives us strong guarantees when refactoring 😎. For me, it's also important to remember that this is only a framework. You don't have to follow this religiously. Try it and adjust to your needs and your application requirements.

Create data modules to hide your implementation details and place your logic in one place

I also wrote about creating modules hiding your implementation details in my previous post: about lessons learned creating a first Reason production app: First ReasonML production app - lessons learned.

As we covered folders and file structure it's important to think about what would be in them. When I started programming in JavaScript I had no idea how to structure my projects. I randomly created React components when they were required and objects in random places with random shapes. Over time I paid greater attention to my React code structure and this part improved. Later, when I learned about Flow I started caring more about types and where they are located in my project. But my logic tended to be scattered in random places. It was painful.

I haven't always had type definition for data, a lot was relying on type inference
When I moved my React components, a lot of functions defined in the same place changed place as well thus requiring import fixes
I had random functions scattered across all my codebase doing random stuff with my data. Not everything was wrong (like mutating data or firing side effects) but it was a mess.
Code discoverability was super hard - to find if the logic I need is already implemented or do I have to write everything from scratch, I had to browse through dozens of files and rely strongly on my memory. I don't recommend anyone joining a team working on such codebase 😅

When we started using Reason, a lot of bad practices migrated with us from JavaScript into our new Reason code. More powerful language doesn't mean you automatically write better code. It takes time to learn how to use this power correctly.

In functional programming languages, you usually have two most important constructs you can use to create bigger abstractions: functions and modules. Functions are the basic logic primitives you can combine into larger pieces of logic and modules which are a collection of your functions.

Let's dive into a simple example. Imagine we have a refund policy in our application. Communication between our client and server is done via GraphQL thus our refund policy will be GraphQL Enum type - in Reason, it will be a polymorphic variant.

If you want to better understand the difference between different types of variants in Reason I highly recommend this article by Dr. Axel Rauschmayer about polymorphic variants.

What we want is basicly 1 Module 1 Thing pattern. Our basic module can look as follows:

/* RefundPolicy.re */
type t = [ | `FullRefund | `NoRefund];

Great, we have our type defined now we can move to our functions. Because we're working on frontend application, sooner or later we will have to show refund policy to the user. Let's introduce the toMessage function. It takes our type t (following OCaml convention for definition leading type in the module) and outputs i18n message our UI can display:

/* RefundPolicy.re */
type t = [ | `FullRefund | `NoRefund];

/* Using bs-react-intl for i18n */
let messages =
  [@intl.messages]
  {
    "fullReturn": {
      "id": "refundPolicy.fullReturn",
      "defaultMessage": "Full return",
    },
    "noReturn": {
      "id": "refundPolicy.noReturn",
      "defaultMessage": "No return",
    },
  };

let toMessage = fun
  | `FullRefund => messages##fullRefund
  | `NoRefund => messages##noRefund

Great, we have a way to display our refund policy to the user! But what if the user needs the ability to select the option? Well, we need more functions.

Usually, React select components work on string values so it would be nice to convert our refund policy to string and from a string. This is where BuckleScript converters come handy, one in particular: jsConverter. It gives us the ability to convert our polyvariant into a string and from a string. It's also a great option if only part of your system is written in Reason and other in Flow/TypeScript where enums are usually represented as strings. Let's use that!

/* RefundPolicy.re */
[@bs.deriving jsConverter]
type t = [ | `FullRefund | `NoRefund];

let default = `NoRefund;

let toString = tToJs;

let fromString = value =>
  value
  ->tFromJs
  ->Belt.Option.getWithDefault(default);

This way you can safely convert your polyvariant to and from a string. tFromJs returns option(t) so you can unwrap that early or return option(t) and handle such case later. It all depends on your use-case. As many BuckleScript interoperability helpers jsConverter have few handy features. One of them is [@bs.as]. It allows you to customize how each case is converted to a string. By default they are all converted as-is: FullRefund will become "FullRefund" and myOtherCase will become "myOtherCase". You can use [@bs.as "full-refund"] if you need different output:

/* RefundPolicy.re */
[@bs.deriving jsConverter]
type t = [
  /* will output "full-refund" */
  | [@bs.as "full-refund"] `FullRefund
  | `NoRefund
];

When we have a way to put it into select, it would be great to provide variable providing all available options. Of course, you can get this data from backend if it's not constant and rely on your business logic but let assume this list is constant:

/* RefundPolicy.re */
let all = [| `FullRefund, `NoRefund |];

let options = all->Belt.Array.map(policy => {
  "key": toString(policy),
  "message": toMessage(policy)
});

Now you have a pretty nice module containing all your logic. In the future, when your business logic changes and available refund policies change, you only have to change code in one place to match new requirements.

Of course, the above functions are trivial but this example is to illustrate the concept. You can create as complex modules as your business requires and restrict access to internals using interface files exposing only public API. It all depends on the size of your team and your codebase.

Always default to Belt

Belt is a BuckleScript standard library. It provided a set of data structures and modules to interact with them. Modules like Belt.List, Belt.Array, Belt.Option and Belt.Result are compatible with built-in Reason types but provide functions that have consistent API and great performance in JavaScript runtime. When I started using Reason, I had few problems with Belt. Mainly because I loved pipe last operator |> and all Belt functions have pipe first -> API (I'll explain differences between |> and -> in-depth in next chapter) and good documentation was lacking (now there is ongoing process of creating better documentation for ReasonML ecosystem).

As of today, Belt comes with BuckleScript compiler and people starting with Reason are confused about what they should use: Array or Belt.Array module? It's probably ok to mix that up when you're working on a toy project but the problem starts when you have a team of few developers working on a bigger project.
Some of them use open Belt on top of a file, some don't. Some use Belt.Array and some Array module. In general, it gets quite messy fast. You can enforce code style in code reviews but it gets tedious. What I started doing is adding -open Belt flag to bsc-flags in bsconfig.json. It implicitly opens Belt in all your modules. Some people may agree, some may not but I think it helps keep certain conventions in a project.

If you don't like Belt and want to use other libraries like tablecloth or relude you can do the same. It works perfectly fine. Problem with Belt can be versioning reliable on bs-platform release, the slow pace of adding functions and modules required by community. There are plans for extracting it from BuckleScript.

Use Pipe first

Yeah, right. One of those great battles in functional programming and BuckleScript took that to the extreme.

Pipe operators, at this point, exist in quite a lot of languages: F#, Elm, Elixir, Reason. A lot of people debate about the "data" place. Some languages like Elm use data last approach, where data is the last argument of a function, and other languages like Elixir prefer the data-first approach - data is the first argument.

Here comes Reason - exactly BuckleScript, distorting well-established practices used in OCaml. In OCaml, where pipe operator is not shipped in the standard library (Yavar Amin corrected me that OCaml std skips with a pipe last operator - thanks 😅) people are implementing it in userland as it's just a one-line infix function:

let ( |> ) x f = f x

Native Reason comes with |> by default. It's data last because of currying and partial application. When you create a function, you sometimes want to omit data passed and create a partially applied function with a logic you created. Let's take List.map as an example.

let doubleElements = collection => List.map(x => x * 2, collection);

It allows you to double every element in the list. With data last approach and partial application you can shorten it as follows:

let doubleElements = List.map(x => x * 2);

It means the same thing and is preferred by some people.

Using the pipe last approach you can use it as follows:

[1,2,3] |> List.map(x => x * 2)
/* or */
[1,2,3] |> doubleElements

It's great because you have a nice flow of how your data is transformed.

[1,2,3]
  |> List.map(x => x * 2)
  |> List.keep(x => x mod 2 == 0)
  |> List.head
  |> Option.map(string_of_int)
  |> Option.map(number => "You happy numer is: " ++ number)

The problem started when BuckleScript introduced -> (pipe first) operator. It behaves similarly but inserts the left side of the operator as the first argument of a right side function:

[1,2,3]
  ->Belt.List.map(x => x * 2)
  ->Belt.List.keep(x => x mod 2 == 0)
  ->Belt.List.head
  ->Belt.Option.map(string_of_int)
  ->Belt.Option.map(happyNumber => "You happy numer is: " ++ happyNumber)

And now all your existing libraries, including OCaml/Reason standard library which is data last, are not working with BuckleScript pipe first operator.

Why is that you may ask? There are a few reasons:

-> unlike |> is just a syntax sugar - it's removed during compilation. Pipe last is just a function and it's not so easy to remove. So in the above example, you have more function calls.
Pipe first has higher associativity than pipe last, thanks to that you can do things like this.

/* without -> */
event => ReactEvent.Form.target(event)##value
/* with -> */
event => event->ReactEvent.Form.target##value

It's something JS API specifics and BuckleScript tries to optimize such cases.

Pipe first works better with BuckleScript bindings: [@bs.send], [@bs.set], etc where data is required to be first

type myComplexClass;

[@bs.new]
external makeComplexClassInstance: unit => myComplexClass = "ComplexClass"

[@bs.send]
external callMeMaybe: (myComplexClass, option(string)) => unit = "callMeMaybe"

myComplexClassInstance->callMeMaybe(None)
myComplexClassInstance->callMeMaybe(Some("911"))

Few more things, all mentioned in the issue in BuckleScript repo: https://github.com/BuckleScript/bucklescript/issues/2463#issuecomment-361863485

My rule of thumb is using pipe first. When it's not possible BuckleScript supports pipe placeholder which makes it compatible with data last collections:

[1,2,3]->List.map(x => x * 2, _);

Reason community seems divided because the pipe first doesn't work on Native. But I think people working with JavaScript as Reason target are embracing pipe first approach. Some libraries like darklang/tablecloth are using labeled arguments to support both pipe first and pipe last approach:

[1,2,3] |> List.map(~f=x => x * 2);
[1,2,3]->List.map(~f=x => x * 2);

If you want to read more about the differences between those two approaches, there is a great article by Javier Chávarri which goes into details about differences between pipe first and pipe last in BuckleScript.

Summary

I hope those few things will help you in the current and future projects and allow you to ship great features! If you have some other practices you follow - share and discuss them with the community!

Many thanks to @zth, @jfrolich and @Faliszek for proofreading!

First ReasonML production app - lessons learned

Tomasz Cichocinski — Wed, 06 Mar 2019 00:00:00 +0000

Over the last 5 months, we at Codeheroes had a chance to work on a mobile application for both iOS and Android as well as web-based panel providing "admin" functionality for a mobile app. We always want to push our skills further and create better and more reliable software with every next project so we went with ReasonML for both applications.

If you want to learn more about Reason I highly recommend official documentation and a great book by Dr. Axel Rauschmayer - Exploring ReasonML and functional programming

I had prior experience with Reason but the rest of the team (one junior and two developers with about two years experience each) had only worked with typed JavaScript using Flow, React and React Native. This project was not only our first Reason project as a team (previously I was writing parts of another app in Reason to test if it suits our needs) but also I had to learn and support other developers on their Reason path.

I want to share our experience and lessons learned from creating mobile and web apps in ReasonML!

Why Reason?

We believe in a statically typed and functional approach as we worked with Flow previously. We also try to write software in an as much functional way as it makes sense in JavaScript. Additionally, our backend is written in Scala so our Backend Developers influence our way of thinking a lot.

I was thinking a lot about introducing Elm to our projects. The language is very hermetic and in my opinion, it would be impossible to create a project using all our previous React experience and technology we developed over the years.

When I learned about Reason somewhere in 2017 it was not mature enough to use it in production then. But in 2018 a lot of Reason community effort with tooling, bindings, talks, blog posts made the language mature enough to test it as a part of our existing JavaScript application. After that, as it went well it convinced us it's reasonable to go with Reason for the whole project.

In case of some real problems, we knew we can go back to JavaScript to finish the project on time. Fortunately, we hadn't had to do so. The last 5 months only convinced us it was a really good decision.

One of the things we were afraid of was interoperability with JavaScript...

1. Don't be afraid of bindings

The core functionality of the application is a medical Bluetooth device for women. They can connect the device to application and "play" simple games using their pelvic muscles.

We knew we had to use a few libraries that don't have existing bindings. The two most significant were: react-native-ble-plx which we used for Bluetooth connection and react-native-game-engine which provides nice API we used for creating games controlled by Bluetooth device.

Bindings forced us to define types for every function we used. It's the same story as Flow or Typescript type definitions but it gives us much more!

In Flow you can omit types, you can do whatever you want and if you decide to write types (or use already existing types from flow-typed) they can lie to you not reflecting the real API. They are not implementation they just type annotations. In Reason, you have to create bindings which are both type annotations and actual implementation of how we want to connect to existing JavaScript code. Of course, you can create bindings that lie about the API but it comes a lot quicker during development in Reason than in Flow.

You can disagree with me 😉.

Another cool Reason feature are abstract types. Those are types that don't have an internal structure. You define them as follows:

/* abstract type */
type someComplexJavaScriptType;

/* normal record type */
type person = {name: string, age: int};

You can create a type that is only passed from function to function. You don't have to care if it's a string, int or some complex object, and what field it has. It exists only in bindings. Here is an example of react-native-ble-plx bindings using abstract types:

type bleManager;
[@bs.module "react-native-ble-plx"] [@bs.new]
external createBleManager: unit => bleManager = "BleManager";

type subscription;
[@bs.send] external removeSubscription: subscription => unit = "remove";

[@bs.send]
external onStateChange:
  (bleManager, string => unit, bool) => subscription = "onStateChange";

First, we define bleManager type and don't care about its internals. Then we have a function to create it from thin air. Great. The same goes with subscription type. We know onStateChange function returns subscription but we don't have to care what it is. We need only to know there is removeSubscription function to remove a subscription.

Once we're forced to create those bindings (and the process of writing them is not hard nor time-consuming) we have a nice place to slightly adjust the library to our needs. We can create an intermediate layer in which we can, for example, rearrange function arguments order for fast-piping or make them labeled, we can compose one or more functions together, we can model the API for our application use case. Without bindings, API we created around those libraries would be much worse.

Of course, this makes it harder to share bindings as an open-source project but I think it should never be the primary goal if you're forced to create bindings in your application code.
It's great to do that so others can benefit but I believe it's the second step. First, create bindings for any functionality you need, then write your application using them so you can validate if they are any good, then publish it as open-source and share with the community to gather feedback from other developers.

2. Render props, using let-anything and bs-epitath, are awesome

Render props is popular React pattern. It allows you to reuse component logic in multiple places. A popular use case is react-apollo query component allowing you to create GraphQL queries. The problem is it makes your component bigger and harder to read. If you have one such component it's ok but if you have two or more you are creating that nested callback monster.

PPX to the rescue! PPX is something called a syntax rewriter. It's OCaml/ReasonML compiler extension which allows you to create compile-time macros.
One of such is let-anything - created by Jared Forsyth. Together with bs-epitath from Astrocoders, it gives us real superpower. Let's look at React Context render props example:

/* without let-anything and bs-epitath */
let component = ReasonReact.statelessComponent(__MODULE__);
let make = _ => {
  ...component,
  render: _ => {
    <Context.Consumer>
      ...{context =>
        <BsReactNative.Text>
          {ReasonReact.string("Logged as: " ++ context.user)}
        </BsReactNative.Text>
      }
    </Contect.Consumer>
  },
};

/* with let-anything and bs-epitath */
let component = ReasonReact.statelessComponent(__MODULE__);
let make = _ => {
  ...component,
  render: _ => {
    let%Epitath context = children =>
      <Context.Consumer>
        ...children
      </Contect.Consumer>;

    <BsReactNative.Text>
      {ReasonReact.string("Logged as: " ++ context.user)}
    </BsReactNative.Text>;
  },
};

Sweet, right?

But be aware! We fall in the trap of overusing it in large components with not only data render props components but combined with view components.

Latest changes to bs-epitath will make it almost impossible to write such code as presented below. But since they want to support old and new syntax please be cautious!

/* don't do this, please */
let component = ReasonReact.statelessComponent(__MODULE__);
let make = _ => {
  ...component,
  render: _ => {
    let%Epitath context = children =>
      <Screen>
        <Section>
          <Card>
            <Context.Consumer>
              ...children
            </Contect.Consumer>
          </Card>
        </Section>
      </Screen>;

    /* real part of the component */
  },
};

While it's valid to do so, I think it introduces a lot of indirection and makes things harder to read. If you want to learn more, Gabriel Rubens Abreu wrote a great post - Render Props composition for ReasonML is here that describes the concept in details.

When starting with a new language, it's often difficult to learn best practices and deeply understand how to model your application. It was true for us, and we learned about it when working on the core functionality of the app...

3. Create more modules hiding your implementation details.

When we created functionality around Bluetooth connection we had to gather samples send by the device. We used them for controlling games and for sending them to our backend for further analysis. While sending samples to the backend is rather easy and requires little or no interaction with samples, the game part is rather complex as we want to process samples in various ways.
Iterate over samples applying some transformation to part of the samples, get samples in some timeframe, find spikes in a list of samples and much, much more.

We failed but not creating a dedicated Sample module. It should have sample type and all functions we would like to use across the whole application. It was a really bad decision that impacted the development of every part relying on that data. We had functions in many modules, many implementations of the same or similar function made by different developers. In general, it was a mess.

Lesson learned here - create modules for your data types to hide the implementation. Let's assume you have a simplified sample that consists of a timestamp and some value gathered in that time. Example module would look something like this:

/* Sample.re */

type t = (float, float);
type samples = list(t);

let make = (time, value) => (time, value);

let getTime = sample => sample->fst;
let getValue = sample => sample->snd;

let mapTime = (sample, fn) => {
  let (time, value) = sample;
  (fn(time), value);
};

let mapValue = (sample, fn) => {
  let (time, value) = sample;
  (time, fn(value));
};

/* more complex functions... */

Later, you decide that tuple is not a suitable data structure for your use case and you want to change it. Let's assume record because you have more than two elements tuple. You change only lower-level functions interacting with the type t and everything works as expected. No need for going through every module using Sample. One file, one commit. Done.

/* Sample.re */

type t = {time: float, value: float};
type samples = list(t);

let make = (time, value) => {time, value};

let getTime = sample => sample.time;
let getValue = sample => sample.value;

let mapTime = (sample, fn) => {
  {...sample, time: fn(sample.time)};
};

let mapValue = (sample, fn) => {
  {...sample, value: fn(sample.value)};
};

/* other functions... */

This is a simple example that was most significant to us and was probably the worst decision in the whole development but we learned a lot from that and wouldn't make the same mistake twice.

4. react-navigation is hard, but with Reason, it's not that hard

In our previous React Native application, we had a hard time around react-navigation. It's really hard to make it statically typed and sound in Flow. Making refactor to screen names and props passed between screens caused us a lot of headaches during the development of a previous application.

When we started work on this application I was a little worried about how it would go. There were no good bindings to react-navigation at a time. But thanks to initial work on bs-react-navigation by guys at Callstack we had something we could work on.

Here are three parts making whole navigation a lot easier.

Explicitly passed navigation to every screen which wants to change currently active screen

Variant describing all available screens and their params

getScreen function rendering currently active screen based on screen variant

A simplified version looks something like this:

/* our screen type */
type screen =
  | Products
  | Product(string);

/* get screen function rendering currently active screen */
let getScreen = (route, navigation) => {
  switch(route) {
    | Products =>
      (
        <ProductsScreen navigation />,
        screenOptions(~title="Products", ())
      )
    | Product(id) =>
      (
        <ProductScreen id navigation />,
        screenOptions(~title="Product", ())
      )
  };
};

/* example screens creating our application */
module ProductsScreen = {
  let component = ReasonReact.statelessComponent(__MODULE__);
  let make = (~navigation, _) => {
    ...component,
    render: _ =>
      <BsReactNative.ScrollView>
        <Product onPress={id => navigation.push(Product(id))} />
        /* other products... */
      </BsReactNative.ScrollView>
   };
};

module ProductScreen = {
  let component = ReasonReact.statelessComponent(__MODULE__);
  let make = (~id, ~navigation, _) => {
    ...component,
    render: _ =>
      /* product query */
      <BsReactNative.View>
        /* product details... */
      </BsReactNative.View>
   };
};

It makes it almost impossible to pass wrong params, forgot about something and in the process of adding more params or changing existing routes
you know every place you have to adjust. And if you make them, the compiler tells you what's wrong and as soon as it compiles - in 99% of cases it works as expected.

5. Don't be afraid of polymorphic variants.

We used graphql_ppx and reason-apollo for GraphQL client-server communication. In our schema, we have a lot of GraphQL Enum types. From things like application locale to things like available games and their configurations. In graphql_ppx generated code enums are polymorphic variants.

When we started writing application we were "scared" of polymorphic variants and decides to create normal variant types for each enum we use in our GraphQL schema. We created a module for each one with a bunch of functionality for converting them back and forth. We had to convert them to every place of the application. From polymorphic variant to variant, from variant to string, from variant to i18n message. It was a lot of duplicated logic only because we were afraid to use polymorphic variants. And what about adding or removing something in API? We had to change our types twice, both polymorphic variants and normal variants.

We learned polymorphic variants are just as fine as normal variants. They give you fewer guarantees and code is harder to debug since compilation errors can pop up in strange places not directly related to please when you use them. Despite all that you shouldn't be afraid. But remember, they are more expensive than normal variants, so use them with caution after all 😉.

My rule of thumb is - if you only pass some variant from the API to the view, it's totally fine to use a polymorphic variant. If they live only in your application (like in navigation) it's better to use normal variants.

Community is great, open-source is great!

Without great projects like bs-react-native, re-formality, graphql_ppx and reason-apollo, reason-apollo, bs-react-navigation and bs-react-intl our work would be much harder or maybe even not possible. We wouldn't choose to go with Reason without those libraries. I want to thank everyone involved in making those libraries and other open-source libraries we used.

If you want to talk more about our work or Reason, DM me on Twitter!

DEV Community: Tomasz Cichocinski

How Trying New Programming Languages Helped Me Grow as a Software Engineer

Your primary programming language

Stepping outside comfort zone

Going back to junior level

Try something new!

I'm available for a free mentorship!

Using Default Exports Makes JavaScript Harder to Read!

You can export anonymous functions and values

It's awkward when importing all from module

Default exports and folder-based routing

Using named exports

Export each function individually, or export everything at once?

Named export alias to the rescue

Conclusion

Resources

Improve your TypeScript with union types!

What is union type?

When to use union type?

How to narrow union type?

Using typeof keyword

Using instanceof keyword

Using if or switch statement

Using “pattern match” object

Using type guard function

Not only primitive types

Conclusion

Resources

5 reasons why destructuring and inline types hurt your TypeScript codebase

How TypeScript function definition look like?

Why I think it's a bad idea and how you can make it better

1. You're not sure where your data is coming from

2. It's hard to write documentation

3. It's hard to pass that data forward

4. You cannot reuse argument types outside this function

5. It just takes a lot of space

Just create type for it

Resources

Types of devs

over-engineering devs

happy path = done devs

let's try that new shiny OSS library devs aka hype devs

so we're creating user-facing application devs

let's write that ourselves devs

we should have eslint for that devs

endofunctor devs

TIL: React Server Components

ReasonML – My Best Practices

Project structure

Create data modules to hide your implementation details and place your logic in one place

Always default to Belt

Use Pipe first

Summary

First ReasonML production app - lessons learned

Why Reason?

1. Don't be afraid of bindings

2. Render props, using let-anything and bs-epitath, are awesome

3. Create more modules hiding your implementation details.

4. react-navigation is hard, but with Reason, it's not that hard

5. Don't be afraid of polymorphic variants.

Community is great, open-source is great!

Using `typeof` keyword

Using `instanceof` keyword

Using `if` or `switch` statement