Forem: Resi Respati

How I accidentally built a popular tool for Trackmania streamers: the story of TMViz

Resi Respati — Wed, 02 Jun 2021 05:07:19 +0000

For developers, side projects often feel like a nuisance.

There seems to be all sorts of ideas floating around the head of a developer, but figuring out which idea to put the work in is a lot harder. And once we find the time to work on a side project, we get sidetracked by any other side project idea we came up with during our morning coffee. But sometimes, the perfect formula for a side project can arrive out of the most mundane situations.

This is the story of how I accidentally built TMViz, a tool that became popular among Trackmania streamers. This post will contain a lot of technical details. But with it, I do hope to tell a story about how I developed and still actively maintain a side project which has a decently-sized userbase.

Motivation

I've been livestreaming consistently for about 1.5 years under my own Twitch channel. I've been playing a lot of racing games on stream, and as of late I've also been streaming Trackmania almost consistently. I've played Trackmania casually ever since the Trackmania Nations Forever (TMNF) days in 2009, and with the new release of Trackmania, I want to take it a little more seriously.

As I started watching some popular Trackmania streamers on Twitch for inspiration, I've noticed that some streamers have a custom overlay which shows the current inputs on their controller/keyboard, one of them being padviz. But sadly, back then I could never find out what it's called. And I was the kind of guy who was very shy in chat, because I'm fairly new to the Trackmania community on Twitch.

I was getting frustrated that I couldn't find it. So I decided to make my own.

First iteration

To make the first iteration of my overlay, I used a technology which 1) I'm familiar with; and 2) has been tried and tested by many different apps for ages: the web. In JavaScript, we can use the Gamepad API to receive inputs from game controllers and react to it. Remember this API - it will become important later.

I'm a fan of tools that you can set up quickly and then forget about it. In padviz, you need to run a separate app in the background to provide the overlay, and you will have to do that every time you start your stream. By providing an overlay that can be included in OBS as a browser source, it's a truly set-and-forget solution.

The initial iteration of the overlay was implemented within a week. It was initially created as a module within my web-based stream overlays set, and remained that way for the first few weeks/months.

Screencap of my Twitch stream with the first iteration of TMViz on the right panel.

Second iteration

I used the first iteration of this tool on my own stream for a couple weeks. At some point during my stream, someone in the chat noticed my tool and that it's different compared to padviz. He asked whether or not it might work for another streamer's controller, since padviz won't work for this one streamer.

Turns out, since padviz was a desktop app written in Python, support for lesser-known controllers was quite flaky. The streamer in question uses a Stadia controller, which was not supported in padviz. Since the web-based Gamepad API is supported by all major browsers - including the OBS browser source - and supports any controller that you could plug into your computer, I immediately saw the need for a standalone version.

I recently read a thread by Kavaeric about the inner workings of UI/UX design, and I realised I already have a mental model of what my target users are going to be like while coming up with the standalone version of TMViz:

they're streamers
they need a set-and-forget solution that can be easily plugged into any streaming software
they use a multitude of controllers; even keyboards

So immediately, I saw the need for a usable overlay customizer. I put together a customiser UI with NextJS and Chakra UI, which generates an overlay URL.

The overlay and game logic itself is easy enough to move, although I redesigned the overlay to match the look of padviz.

The Overlay URL scheme takes some imspiration from Discord StreamKit. This way, I could build a system to create a personalised URL based on the settings saved in the customizer. None of the settings is stored in any external server, since everything is saved in the browser's local storage.

The final step was to tweak the design of the overlay to match the design of padviz's overlay.

Screenshot of the second iteration of TMViz.

Once everything is done, I worked on branding. I named it TMViz, designed a simple logo for it, and made it public.

Ship, then bite your fingernails

The second iteration of TMViz was piloted by the same streamer who used the Stadia controller. After a day, he came back to me with the word I had initially feared: the overlay is broken.

The streamer reported the overlay would be frozen after a while. When this happens, he had to hide and then show the overlay to make it work again.

At this point, I was still using the first iteration of my overlay, so I wasn't able to eat my own dogfood. I decided to transition to TMViz so that I could test this issue, and I ran into the same issue. I also realised that when I opened Task Manager, the OBS process which houses the browser source would have an unusually high memory usage.

I decided to run a memory profiler while the overlay was being used, and soon enough, I found the problem. It turns out that implementing the UI of the controller overlay in Chakra UI caused a memory leak. This will cause the overlay to freeze when the OBS browser source can't handle the memory. So I immediately rushed to rewrite the overlay part of TMViz to use CSS Modules.

So that's one issue fixed. I could also relax for a bit, knowing that I could now eat my own dogfood by using TMViz on my own channel.

How a side gig becomes a full-time job

Around this time, TMViz was also picked up by a popular streamer. He requested me to tweak the overlay so that he can also visualise his use of the D-pad at the same time. It turns out, some players sometimes switch between analog sticks and D-pads when driving on different surfaces (for example, ice).

I spent a few hours refactoring the control schemes to support multiple input methods. I also tweaked the design of the customiser to make setting up keybinds easier. I pushed the update and notified the streamer that the feature is implemented.

The next day, the same streamer reports some issues. After asking some questions, I learned that sometimes he has two controllers plugged in. It turns out, the order of when the controller is plugged in takes precedence in the overlay, and TMViz would. And through computer restarts, the order might change, because of how Windows detects USB devices during bootup. I tweaked the customiser so that users can pick which controller gets picked up by the overlay.

I pushed the fix. The next bug report that came from him completely baffled me. The overlay would crash seemingly at random. Throughout my streams and debugging sessions, I could never replicate it.

Then something dawned on me. At work, we've been using Sentry to log any errors from our users. Sentry collects detailed stack trace from any user whenever an exception is handled within the code, and it has been instrumental to us at work. So I thought it would be a great time to finally give it a spin on my side projects.

So I implemented Sentry and waited for more errors to come in. Based on the stack trace I collected, it turns out I didn't handle the case where a pressed button doesn't exist in the controller.

Oops. Rookie mistake, I know.

Fixing this issue didn't take that long. But of course, debugging and triaging this issue did take a while. I'm glad that tools like Sentry exist. Otherwise the best way of debugging this issue would be individually contacting whoever reported the issue, and asking them about technical stuff they wouldn't understand.

After this final fix, the overlay has grown more stable over time. It's still being picked up by more streamers as time goes, and it's becoming more commonly shared around amongst the Trackmania communities on Discord.

Epilogue, and what's next

So what did I learn while building this? Sometimes, the best ideas for a side project are the ones that are already in front of your eyes. Solve real problems you are having. As the best React instructor on Earth, Kent C. Dodds, would tell us:

[Don't] invent problems just so you can create solutions to them. Nobody will care. Contribute to existing solutions, and solve problems where there are no solutions or the existing solutions are lacking.

— Kent C. Dodds, in "Intentional Career Building"

I would like to personally thank all the streamers who use TMViz. It always brightens my day seeing that tiny little overlay every time I browse through Trackmania streams on Twitch, regardless of viewer count. I have never felt any more invigorated to continue maintaining any side project than ever before.

What's next for TMViz, then? The next item on the list would be keyboard support. This would be a technical feat in of itself, but I understand there's a lot of demand for this. So I'll be sure to make that a reality.

Until then, I can assure everyone that I will keep maintaining TMViz as long as I remain in the Trackmania scene. I am also open for any questions regarding the technical side of the overlay, or just to ask for technical support. You can mention me on Twitter, or you can head over to the #tmviz-support channel on my Discord server.

For those interested, the code for TMViz is also open source and is available on GitHub. If you would like to report a bug or help work on pull requests, any contribution is very much appreciated!

Please, tell us how you solved the problem.

Resi Respati — Thu, 21 Jan 2021 11:47:02 +0000

Header image by Regine Tholen on Unsplash.

There's never been a better time to start programming. With the internet at our fingertips, there are tons of resources available to learn any language, library, or framework that you so wish.

There are also online communities for the programming languages you enjoy. There you can meet like-minded people and discuss your favourite languages/libraries, share your knowledge with others, and ask for help if you're stuck.

Previously if you came across errors while programming, you would have to consult a reference specific to the programming language you're writing in — which could be hundreds of pages long — and find the exact section for the error you're having. No Google, Stack Overflow, or freeCodeCamp to help you.

Nowadays everything is available at our fingertips. If you know where to look, a quick web search would get you to your solution. Or you can jump into discussion boards of programming communities to ask for help, and get answers from people who are fluent in the languages that you use.

But there are times where we take the convenience of modern programming too much for granted. And there are times where we forget the web is a huge knowledgebase that people will come across in the future.

Too often I go on the help channels of developer communities seeing this.

Someone asks a question on a help channel in a developer community, hoping for an answer. Then, through some epiphany or otherwise, they managed to solve it. But they just wrote "solved," all whilst leaving people hanging.

This is not good etiquette for asking for help, especially for people in the future who will come across your posts. Let me explain why.

Have you experienced this?

For those who lived long enough on the internet to experience the days of online forums and bulletin board systems (BBS), we all know too well the experiences that I'm about to tell you.

You're stuck for hours on end on a certain tech problem, be it standard computer stuff, programming errors, or something similar. You decided to do a quick Google search. You carefully crafted your keywords hoping it clearly explains the problems you're having.

Jackpot. You found a thread on some random tech forum you've barely heard about, and you decided to click said search result, hoping to find a solution.

One post. Zero replies. The OP explained exactly the problem you're having, in amazing detail. But alas, nobody seem to have replied with a solution. Or even worse, nobody seemed to care.

You felt frustrated. It was so close, yet so far. Did this random person solve their problem in the end? Did they jump around into other forums, and ask the same question hoping someone will answer? Or did they just give up, and continue to throw more solutions into the problem until something works? What did they see?

Truth is, you'll never know. So you ended up finding the closest, but not-so-accurate solution for a slightly different problem, hoping it will work.

There's even a relevant XKCD to this.

"Wisdom of the Ancients" - xkcd.com

In the next section, I ask everyone in the developer communities I participate in to practice good etiquette in asking help from the internet. All you need to do is simple.

Tell us how you solved it.

The easiest way to prevent the frustrating experience above is to just tell us how you solved the problem.

If you asked for help in a community with a certain problem, and you manage to solve the problem before getting an answer, let us know you solved it, and tell us how you did it.

For example:

OK, I solved it. I turns out that [...] so I tried doing [...] and it finally works!

Even forums like Stack Overflow encourage you to do this. They encourage you to answer your own question when you figure it out by yourself, and they will even give you a shiny badge when you do so.

One recent example is this thread, where someone asked about the performance implications between retained-mode GUI and immediate-mode GUI. Years later, they used the exact same question for their master's thesis, and they went back to the thread years later to post an answer outlining the conclusions made in said thesis.

Telling the world how you solved a problem will not just help you. More importantly, it will also help other people who might encounter the same problem as you in the future.

Web Monetization API and Coil, explained for Twitch streamers

Resi Respati — Mon, 13 Jul 2020 16:09:52 +0000

If you’re a streamer and you looked into your Twitch Dashboard’s activity log lately, chances are you might have seen cheers of at least 100 bits from a user named Coil_Twitch_Bot. And you’re probably wondering to yourself who it’s from, and why it’s doing it.

Short answer, it’s from Coil. Long answer, we need to talk about the Web Monetization API.

The bot, and its donation you’re seeing is the result of an upcoming web spec called the Web Monetization API, and one of the services which have been adopting it, Coil.

In a nutshell, Web Monetization API is a new spec for the web which allows your website/app to receive a stream of small payments from the user, based on the Interledger protocol. If you connect to a Web Monetization-enabled content on the internet, through a supported browser/platform, you will support the content you’re reading by making micropayments to the content creator in the background.

This is a brand-new web API, and is still being proposed as a W3C standard at the Web Platform Incubator Community Group. However, services like Coil and a number of payment providers as well as browsers have included built-in support for this API.

To make your website/app support Web Monetization, simply add the following meta tag to your website:

<meta name="monetization" content="$YOUR_WALLET_URL" />

Using the JavaScript API, you can then make your website behave differently for users who have Web Monetization enabled on their client. For example, removing ads, or even unlocking paywalled content for them.

Or, you don’t even have to do anything! You can set up Web Monetization to provide passive monetisation for your website/app as well.

But what does this have to do with Coil though?

Well, Coil provides a way to support the content you enjoy by allowing you to make micropayments to sites which support them. And it all happens through the power of Web Monetization API.

You become a Coil member by paying a flat $5/month fee. Once a member, you can download their extension to enable the power of Web Monetization through Coil on your browser.

When a website has Web Monetization enabled, your extension will start making micropayments every second to the website owner’s wallet. Currently, the wallets that support Web Monetization are Uphold, Gatehub, Stronghold, and XRP Tipbot.

But what about Twitch streams then? How are you receiving that bits donation from Coil’s bot?

Coil works natively on Twitch, too! If you are an affiliated or partnered Twitch streamers, you don’t need to set anything up, since payouts from Coil members are provided through Twitch Bits. If you have Coil members watching your stream and they have the extension installed, it’ll collect micropayments the same way over time, and pays it out via bits periodically.

Let’s face it, monetising content on the web is broken, and the current solution available leaves the entire user experience on the web worse off. The only way you support content creators and journalists for their work nowadays is broken. They make you go into one of the web’s many walled gardens, and force you to make separate payments over many different walled gardens you go into.

But that shouldn’t be how monetisation works on the internet. It should work the same, every time, everywhere.

Web Monetization API makes monetising content on the Internet open, global, and respects your privacy. I really want this to be the future of the internet, and Coil is taking steps towards it.

I don’t want to make this seem like a sponsored post, but I really believe in Web Monetization API and I really want to see Coil succeed. If you want to support your favourite Twitch streamers as well as many other content on the internet, consider subscribing to Coil. It’s only $5 per month, which is a great deal.

Why can't we just get along?

Resi Respati — Sat, 20 Jun 2020 05:55:00 +0000

Header image by Olav Ahrens Røtne on Unsplash.

There’s been a lot of Discourse™ in the frontend landscape after this thread, announcing a new email client called HEY, was published. In it, they dove deep into HEY’s tech stack, and further boasted about its capabilities. This started further debate on the unique path HEY has taken, and whether or not “better” tech stack is a feature.

I’ve written a couple of times lamenting about the tendency of people starting framework/language wars time and time again. The reality is that your choice of frontend stack doesn’t matter that much anymore. It always frustrates me every time people write opinion thinkpieces disguised as “objective” “facts” about how one framework, or language, is better than the other.

I’ve been on the web development landscape for 6-7 years now. I’ve seen frameworks, technologies, and libraries come and go. I’ve tried all 4 of the Big Frameworks, and understood what each of their benefits are.

I’ve done a lot of framework-hopping before eventually settling on React. From Angular I became addicted to TypeScript. From Vue I learned how better developer tools can significantly improve the developer experience. And from React I could get down and dirty with business logic more comfortably.

I’ve recently tried learning Svelte, and have been doing so while livestreaming to my Twitch channel, which you can view the entire series here. Over time, I’ve seen the advantages of it, as well as some neat features that literally made my jaw drop.

As much as these frameworks benefits are useful, they’re not mutually exclusive.

Let me explain.

I’ve been working on a static website as a side project lately. Since our deployment environment is very limited, I had to be creative and include a mix of old and new tools.

For example, I’ve decided to get back to Gulp and improve the site’s build pipeline. Gulp has improved a lot since v4 came out, and this allows me to include the best of old and new in one build pipeline.

This allows me to rewrite most of the outdated ES5 code into mostly vanilla ES6. It’s not always vanilla though. Thanks to Browserify we can now include the best of the JavaScript ecosystem into our stack. For example, there’s an interactive widget that is written in Preact.

Code-splitting is done entirely manually, with each top-level styles and scripts compiled to their separate files. This forces me to actually write proper modular code, where, I split the styles/scripts between core modules and page/feature-specific modules. I’ve devised a custom file naming scheme to figure out which one is which.

This of course means that every part of the code can be included on-demand.

I haven’t written pure SCSS for a while now, and ever since then, the CSS ecosystem has improved significantly. I’ve combined the best of SCSS (nesting, mixins, etc) with the best features that are already in CSS today (custom properties, grid, etc.). I then run everything through PostCSS to down-compile these features to something that’s supported by popular browsers.

I kinda miss the old way of building websites. But I also have been spoiled by the developer experience of modern tools.

So why can’t we have the best of both?

We have been spoiled by Good Developer Experience™ with these modern frameworks, we tend to forget that in the real world, user experience always wins over developer experience. Just being able to run yarn dev and getting your new app running in a day doesn’t solve user’s pain points like user experience, accessibility, etc. All of these require attention to detail and TLC.

It’s what I’ve been realising when building that project as well. It’s that you can combine the best of old and new if it further improves the user experience.

But do take note that this does not mean that we have to force everyone to party like it’s the 90s. Different companies have different solutions, different user needs, pain points, etc. Feel free to continue on using React, Vue, Angular, and any other modern framework you like. Feel free to stick to the Old Way™️ of doing things. Just remember that choosing a stack is half the battle.

Because a tech stack is not a feature. The way you solve your users’ needs is the real feature.

"How do you use a Next.js router in a class component?"

Resi Respati — Thu, 28 May 2020 05:16:23 +0000

Recorded live on Twitch on 26 May 2020.

This video is a short clip from one of my Twitch-Driven Development sessions, when someone asked me how to use a Next.js router in a class component. Want more of these? I do live coding streams occasionally on my Twitch channel. Follow me to be notified!

Supercharging your Next.js site with getStaticProps and getStaticPaths

Resi Respati — Sat, 07 Mar 2020 15:07:00 +0000

I’ve been diving deep into Next.js lately. It has grown from just merely a framework for server-rendered React apps, to a full-fledged framework for building any React-based full-stack apps, be it server-rendered, statically-generated, or a combination of both. And with the upcoming changes, we will see some incredible new features to unlock the full potential of both server rendering and static generation.

In this post, we’ll take a quick look at these new features, and see how well it compares to all previous versions of Next.js.

The beginning: getInitialProps

The power behind Next.js always lies behind the getInitialProps API. Whilst other frameworks decide to go the extra mile by including complicated boilerplates inside of the framework itself just to pull content, Next.js provides a simple intuitive API that doesn’t care how you prerender content into your app.

In summary, getInitialProps is how you fetch content into a certain Next.js page before it is rendered.

import * as React from 'react'

function IndexPage({ posts }) {
  // render page content
}

// Gets props during prerendering (server-side or static)
IndexPage.getInitialProps = async ctx => {
  try {
    // fetch content (e.g. using a WordPress API helper
    const posts = await wp('wp/v2/posts')

    if (posts && posts.length) {
      // return your desired props
      return { posts }
    }

    throw new Error('No posts found')
  } catch (err) {
    // fallback props if necessary
    return { errors }
  }
}

export default IndexPage

It’s so freaking simple. You can always trust the good folks at ZEIT to design simple, but intuitive APIs on every library they build.

The problem? It’s hybrid. This means that despite the initial load of a site being pre-rendered, any subsequent route changes in your app will run another client-side fetch in order to get the new content. For dynamic content this is fine, but for static sites pulling static content through a headless CMS API, this can be a bit wasteful on resources.

And as a knock-on effect on how this API works, generating static pages also requires a bit of boilerplate using the exportPathMap option in your Next.js config file.

But fortunately, with changes coming to Next.js, everything’s going to be much easier.

Improved static-site generation

About a few months back, the team behind Next.js published an RFC detailing how they’re trying to improve static-site generation (SSG) within Next.js. This introduces several new Next.js lifecyle methods, including getStaticProps and getStaticPaths.

First things first, getStaticProps will render any content passed through it statically at build time. This fits well into the JAMstack workflow, since all content is generated at build time. You can do any types of content fetching in this lifecycle, just as you would with getInitialProps and it will still work as it has been. The difference? Your content will now be pre-generated by Next.js as a static JSON, and any subsequent client-side routing will fetch from these files.

// pages/index.jsx

// getStaticProps is only called server-side
// In theory you could do direct database queries
export async function getStaticProps(context) {
  return {
    // Unlike `getInitialProps` the props are returned under a props key
    // The reasoning behind this is that there's potentially more options
    // that will be introduced in the future.
    // For example to allow you to further control behavior per-page.
    props: {}
  }
}

Note that we pass in all of the props inside a props key. This is to make room for any additional configurations that may be added in the future.

To alleviate the burden of exportPathMap, the getStaticPaths lifecycle is also introduced. This allows you to return a list of pages to render with certain parameters. This will then be used by Next.js to prerender any static pages from dynamic routes.

// pages/blog/[slug].jsx

function BlogPage() {
  // render posts content here
}

// `getStaticPaths` allows the user to return a list of parameters to
// render to HTML at build time.
export async function getStaticPaths() {
  return {
    paths: [
      // this renders /blog/hello-world to HTML at build time
      { params: { slug: 'hello-world' } }
    ]
  }
}

export default BlogPage

Note that we return all the path parameters inside a paths key. Just like in getStaticProps this is to make room for any additional configurations that may be added in the future. For example, we can add in fallback: false to disable the default fallback behaviour within Next.js, which were described in the RFC document.

This also works with catch-all dynamic routes, for example:

// pages/blog/[...slug].jsx

function BlogPage() {
  // render posts content here
}

// `getStaticPaths` allows the user to return a list of parameters to
// render to HTML at build time.
export async function getStaticPaths() {
  return {
    paths: [
      // this renders /blog/2020/03/hello-world to HTML at build time
      { params: { slug: ['2020', '03', 'hello-world'] } }
    ]
  }
}

export default BlogPage

So, how do we hook it up with, say, the WordPress API? Here’s a quick example:

// pages/blog/[slug].tsx

function BlogPage() {
  // render posts content here
}

export async function getStaticPaths() {
  // fetch content (e.g. using a WordPress API helper...
  const posts = await wp('wp/v2/posts')

  // then return all of the rendered paths here:
  if (posts && posts.length) {
    return {
      // put the slugs in with /blog/[slug] format
      paths: posts.map(({ slug }) => ({ params: { slug } }))
    }
  }

  // fallback to empty path if no posts found
  return {
    paths: []
  }
}

export default BlogPage

If you still want the full capabilities of dynamic content, you can also look into the getServerSideProps lifecycle. This is beyond the scope of this post, though you can still look into the full RFC document for its implementation detail.

These new features have been implemented in the canary version of Next.js for everyone to try. You can install the canary version of Next.js by running the following commands:

# npm
npm i next@canary

# yarn
yarn add next@canary

The results

Over the past week, I’ve been helping the team at Kawal COVID-19 to build their website. We’re a group of volunteers from many backgrounds (including, but not limited to, medical practicioners, technologists, and data scientists), helping to provide accurate and factual information regarding the recent outbreak of the coronavirus COVID-19, which has hit several countries, including Indonesia. Our channels so far include Facebook, Twitter, and as of recently, our website.

We initiated the project the day before the first confirmed case of COVID-19 hit Indonesia, so we had to move fast. Everything from the architectural decision, to development and deployment of our website took 3-4 days.

The architecture we decided to go with is a statically-generated Next.js site which pulls content from a WordPress backend. If that sounded familiar to you, I tried a similar architecture where I work. The difference is we’re running a new version of Next.js, therefore we can utilise new features like dynamic routes.

Going static helps us unlock the true possibilities of a JAMstack site, and improves the speed, stability, and security of our website from back to front. However, over the past couple days, we started to notice bottlenecks. As users start to roll in once we announced the website’s launch, we’re starting to see increased response time in our WordPress backend.

Since getInitialProps is hybrid, and only the first load of the page is pre-rendered, every client-side fetching triggered by route changes includes additional roundtrip into our WordPress backend. This causes WordPress REST API response times to increase as more people from across the country access our site.

So we had to figure out another way to keep API roundtrips to a minimum. Fortunately, I remembered about the upcoming SSG improvements in Next.js, so I made the call to switch to the canary version and implement these new features.

It didn’t take a long time to migrate everything from getInitialProps to getStaticProps. However, converting from exportPathMap to getStaticPaths might have to depend on the complexity of your routes, and we’re lucky to have made the call to switch when there’s not much content yet.

The result? I’ll let the following GIF speak for itself.

The first load remains as fast as it used to be, but every subsequent route changes now loads from pre-generated data from our local build, therefore reducing API roundtrip and making the content load much faster.

This also helps us reduces dependency on our WordPress API to zero, therefore reducing its load resulting from any API calls.

Give it a try!

As mentioned earlier, you can try these features before they are included by installing the Next.js canary build. You can install the canary build of Next.js here:

# npm
npm i next@canary

# yarn
yarn add next@canary

Currently, the docs for it resides only in the RFC document, but the ZEIT team will publish the necessary docs for it once it’s ready.

No, TypeScript is not a waste of time.

Resi Respati — Mon, 29 Jul 2019 17:27:00 +0000

Header image by Chris Leggat on Unsplash.

Another day, another heated “discussion” about how static typing in JavaScript is both the single greatest thing since sliced bread and the worst thing to have happened to humanity as a whole.

Let’s look into a recent dev.to post that has been stirring this debate back up again. I’ll try to clear out some misconceptions, and hopefully, take things in a level-headed manner.

Before I start, I want to change up some terms I used, especially the one in the title. Instead of referring to TypeScript specifically, I’d like to use the term “typed JavaScript”. Because there’s also another tool in the typed JS land, Flow, and I don’t want to leave Flow users out. After all, we have the same goal of enforcing type soundness/safety in our apps.

Another term that I would like to throw into the glossary is “dynamically-typed” JS, or “dynamic” for short. Despite what the original post wanted to make you believe, writing JS code without type annotations doesn’t mean that your code doesn't have types. A string written in dynamic JS still has a type of string. So is a number, boolean, you get the point. You just don't have to explicitly express said types.

Yes, it’s longer to start writing statically-typed JS short-term…

I’m going to level with you: writing dynamically-typed JS is faster in the short-term. You might be surprised hearing that from a TypeScript advocate, but I’m being serious here. Really!

Let’s say you’re writing a Node.js library. If you’re writing it in dynamically-typed JS, you can write your library and publish it, all without going through any build tools. It’s that fast! For tiny libraries that do one thing, writing it like this is the most effective way because of the speed.

But now, let’s say you’re writing an entire backend in Node.js. It’s just a tiny API service with a couple endpoints. You have written your authentication system, middleware, and controllers in JavaScript. And since it’s a small endpoint with minor functionalities, you went with plain ol’ JavaScript.

Now, imagine that tiny API service balooned into a full-fledged platform API with thousands of code. Probably tens of thousands of lines of code. Then you realised that you found a bug in one of your endpoints. Oh dear! Unit testing didn’t catch it, so you had to spend hours to trace around your app, looking for the issue. Maybe even setting up breakpoints, or even doing the old-fashioned console.log-driven debugging.

Then, you found the issue. Remember that one time you refactored that one middleware? You also changed the name of the exported function along with it. Sure, you had that middleware unit-tested, but your unit tests were only isolated to that middleware.

Then your eyes came across a file where you had that middleware imported. Of course. You changed the exported function name, but you forgot to rename the imports.

Hours of productivity lost just because of a typo or missing file!

…but the long-term effects are real!

Sure, you can also check mismatched imports with linting tools. But you might also want to rename a function — as well as updating the function name on all the files that import said function — all in the click of a button. After all, humans make mistakes, and missing things like this is not uncommon. TypeScript’s support for quick refactoring and find-and-replace support helps you deal with this. Therefore you can focus more on writing code instead of doing pointless find-and-replace by hand.

Static type checkers like TypeScript and Flow also help reduce the amount of bugs in your code by detecting errors like this during compile time. There’s some statistical proof to this, too. In general, using static typing in your JavaScript code can help prevent about 15% of the bugs that end up in committed code.

Sure, this will make starting out a project with TypeScript much slower, because you’ll need to define types, interfaces, and the like, in the very early stages of your app. But I’d argue that having you write implementation models, in the form of types and/or interfaces, makes you think about your app’s data structure early in the day.

This greatly improves confidence of your app in the long run. And when you use these types well, in many cases you don’t even need types, thanks to TypeScript’s control-flow based type analysis. The benefits of TypeScript on large-scale apps outweighs the trade-offs of the longer time to kickstart your TypeScript project.

Is this an investment that you would take in the future? It sure is for me, but I wouldn’t make any prior judgement for your apps. It’s still up to you to decide whether that investment is worth it.

You can adopt TypeScript incrementally

Maybe you’re already maintaining a medium to large-scale app that’s already written in plain ol’ JavaScript. And you want to migrate to TypeScript, but are afraid that the red squiggly lines will haunt you in your sleep. How would you go about migrating your code?

There are various guides in migrating to TypeScript. There’s one in Basarat Ali Syed’s awesome TypeScript Deep Dive handbook. I have also written a comprehensive guide here.

Another neat part of TypeScript is being able to infer types of normal JS files through JSDoc annotations, so if you write valid JSDoc annotations, and have JS typechecking turned on, it’ll be easy for you to migrate down the road.

Although admittedly, the migration experience is where TypeScript falls short. The reason I linked to third-party guides is — well — TypeScript does have an official migration guide, although it’s horribly outdated. The official documentation also makes hard assumptions that the user know something about statically-typed languages, so I wouldn’t recommend them to newcomers.

Though rest assured, the TypeScript team has been working on reworking the documentation, as well as a new handbook that will hopefully teach TypeScript a lot more progressively.

But what about dynamic, runtime values?

Admittedly, the TypeScript team has explicitly stated that extending static type-checking to the runtime is a non-goal for the TypeScript compiler itself. But in reality, we still have to handle these runtime boundaries. A common example to this would be reading a JSON output from an API, or consuming an HTTP request payload.

Since there’s a strong community backing towards TypeScript, the community has developed elegant solutions to this issue. There are tools like io-ts which you can use to determine runtime representations in TS. A suitable alternative to Flow would be flow-runtime.

Static typing and testing go hand-in-hand!

So far we’ve done a lot in making sure the type safety of our app with static types. Despite that, there are certain bugs static typing cannot catch. For a quick example, testing whether that toggle button displays its opposite state the right way when clicked.

I’m a fan of the Testing Trophy model by Kent C. Dodds. In his model, both linting/static analysis/static type checking and unit testing are located in the “base” of the trophy. This means that they’re both integral parts into building a testing experience that evokes confidence in your code. Hence I’d like to argue that both static typing and unit testing go hand-in-hand in helping you write code with less bugs!

Let’s put the toggle button example above into code. We’re using TypeScript as our static typing, and Jest + react-testing-library to test our code.

Here’s an example of said component, implemented in React.

import * as React from 'react'

interface ToggleButtonProps {
  enabledText: string
  disabledText: string
}

function ToggleButton({ enabledText, disabledText }: ToggleButtonProps) {
  const [toggle, setToggle] = React.useState(false)

  const handleToggle = () => {
    setToggle(!toggle)
  }

  return (
    <div>
      <span>{toggle ? enabledText : disabledText}</span>
      <button onClick={handleToggle}>Toggle</button>
    </div>
  )
}

export default ToggleButton

On the surface, it looks like static typing has done its job. However, if we take a look closer, we’re able to set a custom state text for our toggle button. Sure, TypeScript can check if the string we passed to the enabledText and disabledText props is a string. But that’s just half of the battle.

After all, if we’ve set our button’s enabled and disabled state is set to 'On' and 'Off' respectively, we want it to correctly show 'Off' when it’s disabled, and 'On' when it’s enabled. Not the other way around.

Since we already checked the types of our component and its props through TypeScript, we can focus on testing the behaviour of the button.

The following example uses Jest as our test runner, and react-testing-library as our React testing utility.

import * as React from 'react'
import { render, cleanup, fireEvent } from '@testing-library/react'
import ToggleButton from './ToggleButton'

describe('ToggleButton', () => {
  afterEach(cleanup)

  test('correctly renders the state of button', () => {
    const { getByText, queryByText } = render(<ToggleButton enabledText="on" disabledText="off" />)
    // Test the initial state of the button.
    expect(getByText('Off')).toBeDefined()
    expect(queryByText('On')).toBeNull()

    // Fires a click event to the button.
    fireEvent.click(getByText('Toggle'))

    // Test if toggle state is correctly modified.
    expect(getByText('On')).toBeDefined()
    expect(queryByText('Off')).toBeNull()
  })
})

Two things are happening here.

Static typing provides soundness and improves the developer experience by detecting type errors and allowing developers to refactor confidently through great IDE tools.
Unit testing provides confidence that our code behaves the way that it’s supposed to be used.

Try it out in CodeSandbox

Let’s clear our heads

The original post contained a lot of subjective points, which was a shame because I’d love some objective reasoning as to why static types aren’t worth the time.

My rebuttal to the original post… also contains a lot of subjective points. But that’s fine! Because my goal in writing this post isn’t about going off about how one technology is “objectively better” than the other. I was trying to outline how one technology might benefit the users more than the other, and vice versa. And also find a commonality shared between both of them. Or at least, I tried to.

Instead of building inflammatory, subjective opinions disguised as “objective” “fact”, let’s approach things in a level-headed manner and understand that certain tools exists for certain reasons. Constructive criticism is a great power to improve all of us, regardless of which side you’re in on this debate.

Since I’m a front-end developer myself, a good example I’d like to pick would be the endless debates between the Big Three frameworks (Angular, React, and Vue), and why one is better than the other.

For example, Vue and React developers often went up in arms, writing senseless Medium thinkpieces about how one is better than the other. I’m a React guy myself, but I still understand that Evan You had his own issues to tackle with Vue, hence the issues that he solved being his framework’s key selling point. The most prominent ones being the learning curve and how easy it is to adopt.

The people behind TypeScript and Flow are smart enough to tackle one of their pain points in writing JavaScript. They want to write JavaScript code that scales in large-scale projects. And the way they approach that is to provide a static typing superset that ensures type soundness and safety, as well as improving productivity through developer tools that are enabled thanks to the power of static types. And for some people, it worked well. TypeScript and Flow are both running many medium to large-scale projects out there (including where I work), and I could imagine all the ways they enabled engineers to write code with less bugs.

TypeScript might be a waste of time for you, but it certainly isn’t a waste of time for me.

Don’t get me wrong, there’s nothing wrong in writing plain JS as well! Maybe you want to iterate faster on the early stages of the project, so you opted for plain JS instead of jumping into TS straight away. Maybe you want to get down and dirty with TypeScript right from the get-go. Both of these are fine. After all, it’s only you knows how to best develop your app. It’s only you who knows how to serve a better user/developer experience.

Because regardless of our choices of tools, languages, and frameworks (or lack thereof), it all ends up with a working app.

Right?

Using TypeScript's absolute paths in Create React App 2.0 without ejecting

Resi Respati — Wed, 13 Mar 2019 02:37:00 +0000

Header image: Ejection seat test at China Lake with F-4B cockpit (1967), public domain (US).

Update 2019-05-15: Starting from version 3.0, Create React App will respect the baseurl settings that you have in your tsconfig.json. If you already use CRA 3.0 and above, this guide is no longer necessary.

Create React App (CRA) 2.0 allows for drop-in support for TypeScript. This means we can finally use TypeScript from the core CRA package without having to rely on community-maintained forks like create-react-app-typescript. Thanks to Babel 7’s TypeScript support, the TypeScript integration to CRA 2.0 is seamless. Although this means that slight differences from create-react-app-typescript apply.

One TypeScript feature that lacks from create-react-app and TypeScript is the ability to use absolute imports. This allows importing from an absolute path based on the project’s root source directory. It means you can import modules without having to resort to relative paths. Nothing wrong with them, but when your folders are deeply nested, they can sometimes go ugly. (../../../../../../../, anyone?)

Unfortunately, with CRA 2.0 making use of Babel for transpilation, this feature is rather limited. And they made it clear by forcing some defaults on this behaviour. For instance, CRA 2.0 automatically removes the baseUrl and paths options from the tsconfig.json any time we run its scripts. This means for some people wanting to make use of this feature, ejecting is the only option.

Not anymore. Thanks to some clever little hacks and using CRA rewiring tools, we can now set up CRA 2.0 to respect TypeScript’s absolute imports without ejecting.

Before we start

Please note that rewiring CRA scripts is a slightly-advanced technique. Proceed with caution!

By rewiring your scripts, your’re breaking the “guarantees” that React provides. You now accept that you “own” your configs, which means that the CRA team cannot give support for your rewired config.

“Stuff can break” — Dan Abramov

But fortunately, with tools like craco, we can easily revert back to the default CRA config should things go wrong. It’s still a better option over ejecting CRA entirely.

Set up `craco`

craco is a wonderful tool which allows us to extend CRA 2.0 configs without ejecting. It’s the spiritual successor for react-app-rewired, which has ceased development.

# yarn
$ yarn add @craco/craco

# npm
$ npm install @craco/craco

After craco is installed, create an empty craco.config.js file. We’ll touch this later.

// craco.config.js

module.exports = {
  // ...
}

And finally, change the npm scripts in the package.json to the following:

   "scripts": {
- "start": "react-scripts start",
+ "start": "craco start",
- "build": "react-scripts build",
+ "build": "craco build"
- "test": "react-scripts test",
+ "test": "craco test"
   }

This will run the CRA scripts through craco which will inject the rewires set in craco.config.js to the scripts.

Extend `paths` option from a separate file

CRA 2.0 will automatically override the paths config on the base tsconfig.json every time we run npm start. So we’ll have to work around it by defining it from a separate file.

Name this file whatever you’d like. This file exists solely because CRA 2.1 overwrites our base tsconfig every time we run npm start. Always define paths in this file!

tsconfig.paths.json

{
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "//": "Define absolute imports path mappings.",
      "//": "Don't forget to add these to `resolve.alias` on `craco.config.js`.",
      "*": ["src/*"]
    }
  }
}

This allows us to set our absolute imports relative to the src folder, e.g. components/Container. If you prefer to use wildcard characters like ~, you can also use that:

{
  "//": "Allows you to import modules with the `~/components/Container` format.",
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "~/*": ["src/*"]
    }
  }
}

Then, we can extend the config above in our main tsconfig.json file.

tsconfig.json

{
  "//": "Extend the config we just created",
  "extends": "./tsconfig.paths.json",
  "compilerOptions": {
    "//": "the rest of the tsconfig"
  }
}

Rewire webpack aliases using `craco`

Now it’s time to tell the transpiler to alias a root module directory to its correct path. There are two ways to do this, one through Babel using babel-plugin-module-resolver, and the other by setting webpack aliases. We’ll do the latter.

Open your craco.config.js file and add the webpack config rewire.

// craco.config.js
const { paths } = require('@craco/craco')

module.exports = {
  webpack: {
    alias: {
      // Add the aliases for all the top-level folders in the `src/` folder.
      assets: `${paths.appSrc}/assets/`,
      components: `${paths.appSrc}/components/`,
      interfaces: `${paths.appSrc}/interfaces/`,
      modules: `${paths.appSrc}/modules/`,
      utils: `${paths.appSrc}/utils/`,

      // Another example for using a wildcard character
      '~': `${paths.appSrc}/`
    }
  }
}

Start the development server again, and now your absolute imports should work!

Configure Jest’s `moduleNameMapper`

If you use Jest, you should also let it know how to handle absolute imports. We can, of course, do this through craco.

module.exports = {
  webpack: {
    alias: {
      // Add the aliases for all the top-level folders in the `src/` folder.
      assets: `${paths.appSrc}/assets/`,
      components: `${paths.appSrc}/components/`,
      interfaces: `${paths.appSrc}/interfaces/`,
      modules: `${paths.appSrc}/modules/`,
      utils: `${paths.appSrc}/utils/`,

      // Another example for using a wildcard character
      '~': `${paths.appSrc}/`
    }
  },
  jest: {
    configure: {
      moduleNameMapper: {
        // Jest module mapper which will detect our absolute imports.
        '^assets(.*)$': '<rootDir>/src/assets$1',
        '^components(.*)$': '<rootDir>/src/components$1',
        '^interfaces(.*)$': '<rootDir>/src/interfaces$1',
        '^modules(.*)$': '<rootDir>/src/modules$1',
        '^utils(.*)$': '<rootDir>/src/utils$1',

        // Another example for using a wildcard character
        '^~(.*)$': '<rootDir>/src$1'
      }
    }
  }
}

And that’s it!

Your CRA 2.0 setup now respects TypeScript’s absolute imports. Pretty simple, right?

Enjoy the power of TypeScript in your React app! If you want to learn more about how TypeScript can help you in React, check out the React TypeScript Cheatsheet. It also includes cheatsheets for common React patterns in TypeScript.

Migrating to TypeScript, Part 2: Trust the compiler!

Resi Respati — Mon, 25 Feb 2019 08:53:00 +0000

Header image by Irina Iriser on Unsplash.

In part 1, we explored how to initialise a project with the TypeScript compiler and the new TypeScript Babel preset. In this part, we’ll go through a quick primer of TypeScript’s features and what they’re for. We’ll also learn how to migrate your existing JavaScript project gradually to TypeScript, using an actual code snippet from an existing project. This will get you to learn how to trust the compiler along the way.

Thinking in TypeScript

The idea of static typing and type safety in TypeScript might feel overwhelming coming from a dynamic typing background, but it doesn’t have to be that way.

The main thing people often tell you about TypeScript is that it’s “just JavaScript with types”. Since JavaScript is dynamically typed, a lot of features like type coercion is often abused to make use of the dynamic nature of the language. So the idea of type-safety might never come across your average JS developer. This makes the idea of static typing and type safety feel overwhelming, but it doesn’t have to be that way.

The trick is to rewire our thinking as we go along. And to do that we need to have a mindset. The primary mindset, as defined in Basarat’s book, is Your JavaScript is already TypeScript.

But why is TypeScript important?

A more appropriate question to ask would be “why is static typing in JavaScript important?” Sooner or later, you’re going to start writing medium to large-scale apps with JavaScript. When your codebase gets larger, detecting bugs will become a more tedious task. Especially when it’s one of those pesky Cant read property 'x' of undefined errors. JavaScript is a dynamically-typed language by nature and it has a lot of its quirks, like null and undefined types, type coercion, and the like. Sooner or later, these tiny quirks will work against you down the road.

Static typing ensures the correctness of your code in order to help detect bugs early. Static type checkers like TypeScript and Flow help reduce the amount of bugs in your code by detecting type errors during compile time. In general, using static typing in your JavaScript code can help prevent about 15% of the bugs that end up in committed code.

TypeScript also provides various productivity enhancements like the ones listed below. You can see these features on editors with first-class TypeScript support like Visual Studio Code.

Advanced statement completion through IntelliSense
Smarter code refactoring
Ability to infer types from usage
Ability to type-check JavaScript files (and infer types from JSDoc annotations)

Strict mode

TypeScript’s “strict mode” is where the meat are of the whole TypeScript ecosystem. The --strict compiler flag, introduced in TypeScript 2.3, activates TypeScript’s strict mode. This will set all strict typechecking options to true by default, which includes:

--noImplicitAny - Raise error on expressions and declarations with an implied ‘any’ type.
--noImplicitThis - Raise error on ‘this’ expressions with an implied ‘any’ type.
--alwaysStrict - Parse in strict mode and emit “use strict” for each source file.
--strictBindCallApply - Enable strict ‘bind’, ‘call’, and ‘apply’ methods on functions.
--strictNullChecks - Enable strict null checks.
--strictFunctionTypes - Enable strict checking of function types.
--strictPropertyInitialization - Enable strict checking of property initialization in classes.

When strict is set to true in your tsconfig.json, all of the options above are set to true. If some of these options give you problems, you can override strict mode by overriding the options above one by one. For example:

{
  "compilerOptions": {
    "strict": true,
    "strictFunctionTypes": false,
    "strictPropertyInitialization": false
  }
}

This will enable all strict type-checking options except --strictFunctionTypes and --strictPropertyInitialization. Fiddle around with these options when they give you trouble. Once you get more comfortable with them, slowly re-enable them one by one.

Linting

Linting and static analysis tools are one of the many essential tools for any language. There are currently two popular linting solutions for TypeScript projects.

TSLint used to be the de-facto tool for linting TypeScript code. It has served the TS community well throughout the years, but it has fallen out of favour as of late. Development seems to have stagnated lately, with the authors even announcing its deprecation recently in favour of ESLint. Even Microsoft themselves have noticed some architectural and performance issues in TSLint as of late, and recommended against it. Which brings me to the next option.
ESLint - yeah, I know. But hear me out for a second. Despite being a tool solely for linting JavaScript for quite some time, ESLint has been adding more and more features to better support TS. It has announced plans to better support TS through the new typescript-eslint project. It contains a TypeScript parser for ESLint, and even a plugin which ports many TSLint rules into ESLint.

Therefore, ESLint might be the better choice going forward. To learn more about using ESLint for TypeScript, read through the docs of the typescript-eslint project.

A quick primer to TypeScript types

The following section contains some quick references on how TypeScript type system works. For a more detailed guide, read this 2ality blog post on TypeScript’s type system.

Applying types

Once you’ve renamed your .js files to .ts (or .tsx), you can enter type annotations. Type annotations are written using the : TypeName syntax.

let assignedNumber: number | undefined = undefined

assignedNumber = 0

function greetPerson(name: string) {
  return `Hello, ${name}!`
}

You can also define return types for a function.

function isFinishedGreeting(name: string): boolean {
  return getPerson(name).isGreeted()
}

Primitive & unit types

TypeScript has a few supported primitive types. These are the most basic data types available within the JavaScript language, and to an extent TypeScript as well.

// Boolean
let isDone: boolean = false

// Number
let decimal: number = 6
let hex: number = 0xf00d
let binary: number = 0b1010
let octal: number = 0o744

// string
let standardString: string = 'Hello, world!'
let templateString: string = `Your number is ${decimal}`

These primitive types can also be turned into unit types , where values can be their own types.

// This variable can only have one possible value: 42.
let fortyTwo: 42 = 42

// A unit type can also be combined with other types.
// The `|` turns this into a union type. We'll go through it in the next section.
let maybeFalsey: 0 | false | null | undefined

Intersection & union types

You can combine two or more types together using intersection and union types.

Union types can be used for types/variables that have have one of several types. This tells TypeScript that “variable/type X can be of either type A or type B.”

function formatCommandline(command: string[] | string) {
  var line = ''
  if (typeof command === 'string') {
    line = command.trim()
  } else {
    line = command.join(' ').trim()
  }

  return line
}

Intersection types can be used to combine multiple types into one. This tells TypeScript that “variable/type X contains type A and B.”

type A = { a: string }
type B = { b: string }

type Combined = A & B // { a: string, b: string }

// Example usage of intersection types.
// Here we take two objects, then combining them into one whilst using intersection types
// to combine the types of both objects into one.
function extend<T, U>(first: T, second: U): T & U {
  // use TypeScript type casting to create an object with the combined type.
  let result = {} as T & U

  // combine the object.
  for (let id in first) {
    result[id] = first[id]
  }
  for (let id in second) {
    if (!result.hasOwnProperty(id)) {
      result[id] = second[id]
    }
  }
  return result
}

const x = extend({ a: 'hello' }, { b: 42 })

// `x` now has both `a` and `b` property
console.log(x.a)
console.log(x.b)

`type`s and `interface`s

For defining types of objects with a complex structure, you can use either the type or the interface syntax. Both work essentially the same, with interface being well-suited for object-oriented patterns with classes.

// Types
type ComponentProps = {
  title?: string
}

function ReactComponent(props: ComponentProps) {
  return <div>{props.title}</div>
}

// Interfaces
interface TaskImpl {
  start(): void
  end(): void
}

class CreepTask implements TaskImpl {
  state: number = 0

  start() {
    this.state = 1
  }

  end() {
    this.state = 0
  }
}

Generics

Generics provide meaningful type constraints between members.

In the example below, we define an Action type where the type property can be anything that we pass into the generic.

interface Action<T = any> {
  type: T
}

The type that we defined inside the generic will be passed down to the type property. In the example below, type will have a unit type of 'FETCH_USERS'.

// You can also use `Action<string>` for any string value.
interface FetchUsersAction extends Action<'FETCH_USERS'> {
  payload: UserInfo[]
}

type AddUserAction = Action<'ADD_USER'>
const action: AddUserAction = { type: 'ADD_USER' }

Declaration files

You can let TypeScript know that you’re trying to describe a some code that exists somewhere in your library (a module, global variables/interfaces, or runtime environments like Node). To do this, we use the declare keyword.

Declaration files always have a .d.ts file extension.

// For example, to annotate Node's `require()` call
declare const require: (module: string) => any

// Now you can use `require()` everywhere in your code!
require('whatwg-fetch')

You can include this anywhere in your code, but normally they’re included in a declaration file. Declaration files have a .d.ts extension, and are used to declare the types of your own code, or code from other libraries. Normally, projects will include their declaration files in something like a declarations.d.ts file and will not be emitted in your compiled code.

You can also constrain declarations to a certain module in the declare module syntax. For example, here’s a module that has a default export called doSomething().

declare module 'module-name' {
  // You can also export types inside modules so library consumers can use them.
  export type ExportedType = { a: string; b: string }

  const doSomething: (param: ExportedType) => any
  export default doSomething
}

Let’s migrate!

Alright, enough with the lectures, let’s get down and dirty! We’re going to take a look at a real-life project, take a few modules, and convert them to TypeScript.

To do this, I’ve taken upon the help of my Thai friend named Thai (yeah, I know). He has a massive, web-based rhythm game project named Bemuse, and he’s been planning to migrate it to TypeScript. So let’s look at some parts of the code and try migrating them to TS where we can.

From `.js` to `.ts`

Consider the following module:

Here we have your typical JavaScript module. A simple module with a function type-annotated with JSDoc, and two other non-annotated functions. And we’re going to turn this bad boy into TypeScript.

To make a file in your project a TypeScript file, we just need to rename it from .js to .ts. Easy, right?

Oh no! We’re starting to see some red! What did we do wrong?

This is fine, actually! We’ve just enabled our TypeScript type-checking by doing this, so what’s left for us is to add types as we see fit.

The first thing to do is to add parameter types to these functions. As a quick way to get started, TypeScript allows us to infer types from usage and include them in our code. If you use Visual Studio Code, click on the lightbulb that appears when your cursor is in the function name, and click on “Infer parameter types from usage”.

If your functions/variables are documented using JSDoc, this gets much easier as TS can also infer parameter types from JSDoc annotations.

Note that TypeScript generated a partial object schema for the function at the bottom of this file based on usage. We can use it as a starting point to improve its definition using interfaces and types. For example, let’s take a look at this line.

/**
 * Returns the accuracy number for a play record.
 */
export function formattedAccuracyForRecord(record: { count: any; total: any }) {
  return formatAccuracy(calculateAccuracy(record.count, record.total))
}

We already know that we have properties count and total in this parameter. To make this code cleaner, we can put this declaration into a separate type/interface. You can include this within the same file, or separately on a file reserved for common types/interfaces, e.g. types.ts

export type RecordItem = {
  count: any
  total: any
  [key: string]: any
}

import { RecordItem } from 'path/to/types'

/**
 * Returns the accuracy number for a play record.
 */
export function formattedAccuracyForRecord(record: RecordItem) {
  return formatAccuracy(calculateAccuracy(record.count, record.total))
}

Dealing with external modules

With that out of the way, now we’re going to look at how to migrate files with external modules. For a quick example, we have the following module:

We’ve just renamed this raw JS file into .ts and we’re seeing a few errors. Let’s take a look at them.

On the first line, we can see that TypeScript doesn’t understand how to deal with the lodash module we imported. If we hovered over the red squiggly line, we can see the following:

Could not find a declaration file for module 'lodash-es'. '/Users/resir014/etc/repos/bemusic/bemuse/node_modules/lodash/lodash.js' implicitly has an 'any' type.
  Try `npm install @types/lodash` if it exists or add a new declaration (.d.ts) file containing `declare module 'lodash';`

As the error message says, all we need to do to fix this error is to install the type declaration for lodash.

$ npm install --save-dev @types/lodash

This declaration file comes from DefinitelyTyped, an extensive library community-maintained declaration files for the Node runtime, as well as many popular libraries. All of them are autogenerated and published in the @types/ scope on npm.

Some libraries include their own declaration files. If a project is compiled from TypeScript, the declarations will be automatically generated. You can also create declaration files manually for your own library, even when your project is not built using TypeScript. When generating declaration files inside a module, be sure to include them inside a types, or typings key in the package.json. This will make sure the TypeScript compiler knows where to look for the declaration file for said module.

{
  "main": "./lib/index.js",
  "types": "./types/index.d.ts"
}

OK, so now we have the type declarations installed, how does our TS file look like?

Whoa, what’s this? I thought only one of those errors would be gone? What’s happening here?

Another power of TypeScript is that it’s able to infer types based on how data flows throughout your module. This is called control-flow based type analysis. This means that TypeScript will know that the chart inside the .orderBy() call comes from what was passed from the previous calls. So the only type error that we have to fix now would be the function parameter.

But what about libraries without type declaration? On the first part of my post, I’ve come across this comment.

Vignesh D • Jan 9 '19

I was trying to use Typescript with react and Evergreen-Ui react library. But Evergreen-ui doesn't have typescript support. It's asking for declaration file which I couldn't understand. How to proceed with it?

Some packages include their own typings within the project, so oftentimes it will get picked up by the TypeScript compiler. But in case we have neither built-in typings nor @types package for the library, we can create a shim for these libraries using ambient declarations (*.d.ts files).

First, create a folder in your source directory to hold ambient declarations. Call it types/ or something so we can easily find them. Next, create a file to hold our own custom declarations for said library. Usually we use the library name, e.g. evergreen-ui.d.ts.

Now inside the .d.ts file we just created, put the following:

declare module 'evergreen-ui'

This will shim the evergreen-ui module so we can import it safely without the “Cannot find module” errors.

Note that this doesn’t give you the autocompletion support, so you will have to declare the API for said library manually. This is optional of course, but very useful if you want better autocompletion.

For example, if we were to use Evergreen UI’s Button component:

// Import React's base types for us to use.
import * as React from 'react'

declare module 'evergreen-ui' {
  export interface ButtonProps extends DimensionProps, SpacingProps, PositionProps, LayoutProps {
    // The above extended props props are examples for extending common props and are not included in this example for brevity.

    intent: 'none' | 'success' | 'warning' | 'danger'
    appearance: 'default' | 'minimal' | 'primary'
    isLoading?: boolean

    // Again, skipping the rest of the props for brevity, but you get the idea.
  }

  export class Button extends React.PureComponent<ButtonProps> {}
}

And that’s it for part 2! The full guide concludes here, but if there are any more questions after this post was published, I’ll try to answer some of them in part 3.

As a reminder, the #typescript channel on the Reactiflux Discord server has a bunch of lovely people who know TypeScript inside and out. Feel free to hop in and ask any question about TypeScript!

Phoenix with React: The Right Way™

Resi Respati — Mon, 21 Jan 2019 06:27:06 +0000

This is a long-awaited rewrite of my original post on the perfect setup to use Phoenix with React, originally posted on my website. Phoenix 1.4 ships with Webpack by default, therefore making the setup much more straightforward than before. The long-overdue rewrite has been finished, and has also been made up-to-date following recent updates to Phoenix. The sample repo has also been updated.

For those looking for Part 2 of my Migrating to TypeScript guide, rest assured! It will be finished within the next week.

I've been playing around with Elixir a lot lately. Recently a friend showed me this blog post by the Discord engineering team about how they could scale their platform through the power of Elixir, and after reading it I was convinced to give it a try. If you're about to learn the language, and you came from Node.js like me, I suggest you go watch this introductory video.

If Ruby has Rails, and PHP has Laravel, then Elixir has Phoenix. If you've ever used Rails before, you'll feel right at home. It has the bare essentials of your typical web framework, although it has some neat additional features like Channels, which makes building web apps with sockets much easier.

My ideal stack for a web app usually includes a React frontend. So naturally, I wanted to know how I could build a Phoenix app with a React frontend. Unfortunately, setting up React with Phoenix isn't as straightforward as many people think. Almost every guide that I came across on the internet only goes as far as rendering a single React component and doesn't cover essential things like routing and API fetching. It took me a while, but finally, I found a setup that Actually Works™.

So if you're like me and have been wondering how the heck do you actually get it to work, I'm going to show you how. Hopefully this will answer this question once and for all.

TL;DR

If reading's not your thing, I have prepared the end result of this guide here. Once you're all set up, you should have a working Phoenix setup with the following stack:

Elixir (^1.7.4)
Node.js (^10.15.0)
npm (^6.4.1)
Phoenix (^1.4.0)
React (^16.7.0)
TypeScript (^3.0.0)
Webpack (^4.0.0)

Getting started

In this guide, I will assume that you already have Elixir, Phoenix, and Node.js installed. If you haven't already, open the links above in a new tab and do it. Don't worry, I'll wait.

We're also going to use Phoenix 1.4, the latest version available at the time of writing.

The boilerplate

We're going to set up a new Phoenix project, complete with the build environment we're going to use.

As of version 1.4, Phoenix ships with Webpack by default. By running the following command we'll have a Phoenix setup with built-in support for JS bundling.

$ mix phx.new phoenix_react_playground

When you're asked if you want to fetch and install dependencies as well, answer No. We'll get to it later.

By default, the package.json file, the Webpack config, and the .babelrc file are located in the assets/ folder instead of the project root. This is not ideal, since it could fuck up with IDEs like Visual Studio Code. So let's move them to the project root instead.

$ cd phoenix_react_playground
$ mv assets/package.json .
$ mv assets/webpack.config.js .
$ mv assets/.babelrc .

This means we'll need to change some of the defaults provided by Phoenix:

.gitignore

@@ -26,7 +26,7 @@ phoenix_react_playground-*.tar
 npm-debug.log

 # The directory NPM downloads your dependencies sources to.
-/assets/node_modules/
+node_modules/

 # Since we are building assets from assets/,
 # we ignore priv/static. You may want to comment

package.json

@@ -6,8 +6,8 @@
     "watch": "webpack --mode development --watch"
   },
   "dependencies": {
-    "phoenix": "file:../deps/phoenix",
-    "phoenix_html": "file:../deps/phoenix_html"
+    "phoenix": "file:deps/phoenix",
+    "phoenix_html": "file:deps/phoenix_html"
   },
   "devDependencies": {
     "@babel/core": "^7.0.0",
@@ -18,7 +18,7 @@
     "mini-css-extract-plugin": "^0.4.0",
     "optimize-css-assets-webpack-plugin": "^4.0.0",
     "uglifyjs-webpack-plugin": "^1.2.4",
-    "webpack": "4.4.0",
-    "webpack-cli": "^2.0.10"
+    "webpack": "4.28.4",
+    "webpack-cli": "^3.2.1"
   }
 }

webpack.config.js

@@ -13,11 +13,11 @@ module.exports = (env, options) => ({
     ]
   },
   entry: {
-      './js/app.js': ['./js/app.js'].concat(glob.sync('./vendor/**/*.js'))
+    app: './assets/js/app.js'
   },
   output: {
     filename: 'app.js',
-    path: path.resolve(__dirname, '../priv/static/js')
+    path: path.resolve(__dirname, 'priv/static/js')
   },
   module: {
     rules: [
@@ -36,6 +36,10 @@ module.exports = (env, options) => ({
   },
   plugins: [
     new MiniCssExtractPlugin({ filename: '../css/app.css' }),
-    new CopyWebpackPlugin([{ from: 'static/', to: '../' }])
-  ]
+    new CopyWebpackPlugin([{ from: 'assets/static/', to: '../' }])
+  ],
+  resolve: {
+    // Add '.ts' and '.tsx' as resolvable extensions.
+    extensions: ['.ts', '.tsx', '.js', '.jsx', '.json']
+  }
 });

The above Webpack configuration works for the ideal Phoenix setup of placing unbundled assets on the assets/ folder. We need to make sure that Phoenix correctly runs the Webpack command as our watcher. To do so, modify config/dev.exs as follows:

-  watchers: []
+  watchers: [
+    {"node", [
+      "node_modules/webpack/bin/webpack.js",
+      "--watch-stdin",
+      "--colors"
+    ]}
+  ]

To make sure everything works, run the following commands:

$ mix deps.get
$ npm install

Does everything work? Good! Next, we'll set up our TypeScript environment.

First, we'll install the TypeScript + React preset for Babel, and put it into our .babelrc.

$ yarn add --dev @babel/preset-react @babel/preset-typescript @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread typescript

@@ -1,5 +1,10 @@
 {
-    "presets": [
-        "@babel/preset-env"
-    ]
-}
+  "presets": [
+    "@babel/preset-env",
+    "@babel/preset-react",
+    "@babel/preset-typescript"
+  ],
+  "plugins": [
+    "@babel/plugin-proposal-class-properties",
+    "@babel/plugin-proposal-object-rest-spread"
+  ]
+}

Then, we'll create a standard tsconfig.json file and fill it up with the following.

{
  "compilerOptions": {
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "isolatedModules": true,
    "lib": ["dom", "esnext"],
    "jsx": "preserve",
    "target": "es2016",
    "module": "esnext",
    "moduleResolution": "node",
    "preserveConstEnums": true,
    "removeComments": false,
    "sourceMap": true,
    "strict": true
  },
  "include": ["./**/*.ts", "./**/*.tsx"]
}

And finally, modify our Webpack config so that the babel-loader accepts JS and TS files. Don't forget to change the extension of your Webpack entry file too!

@@ -13,7 +13,7 @@ module.exports = (env, options) => ({
     ]
   },
   entry: {
-    app: './assets/js/app.js'
+    app: './assets/js/app.tsx'
   },
   output: {
     filename: 'app.js',
@@ -22,7 +22,7 @@ module.exports = (env, options) => ({
   module: {
     rules: [
       {
-        test: /\.js$/,
+        test: /\.(js|jsx|ts|tsx)$/,
         exclude: /node_modules/,
         use: {
           loader: 'babel-loader'

Once you've got your boilerplate set up, your Phoenix project's folder structure should now look like this.

phoenix_react_playground/
├── assets/
│   ├── js/
│   │   ├── ...
│   │   └── app.tsx
│   ├── scss/
│   │   ├── ...
│   │   └── app.scss
│   └── static/
│       ├── images/
│       │   └── ...
│       ├── favicon.ico
│       └── robots.txt
├── config/
│   └── ...
├── lib/
│   └── ...
├── priv/
│   └── ...
├── test/
│   └── ...
├── .gitignore
├── mix.exs
├── package.json
├── README.md
├── tsconfig.json
└── webpack.config.js

Setting up React

Let's now hook up React with Phoenix the right way. First, of course, we'll need to install React.

$ yarn add react react-dom react-router-dom
$ yarn add --dev @types/react @types/react-dom @types/react-router-dom

Then, we can set up our base React boilerplate. In our assets folder, rename app.js to app.tsx, and rewrite the file as follows.

assets/js/app.tsx

import '../css/app.css'

import 'phoenix_html'

import * as React from 'react'
import * as ReactDOM from 'react-dom'
import Root from './Root'

// This code starts up the React app when it runs in a browser. It sets up the routing
// configuration and injects the app into a DOM element.
ReactDOM.render(<Root />, document.getElementById('react-app'))

assets/js/Root.tsx

import * as React from 'react'
import { BrowserRouter, Route, Switch } from 'react-router-dom'

import Header from './components/Header'
import HomePage from './pages'

export default class Root extends React.Component {
  public render(): JSX.Element {
    return (
      <>
        <Header />
        <BrowserRouter>
          <Switch>
            <Route exact path="/" component={HomePage} />
          </Switch>
        </BrowserRouter>
      </>
    )
  }
}

assets/js/components/Header.tsx

import * as React from 'react'

const Header: React.FC = () => (
  <header>
    <section className="container">
      <nav role="navigation">
        <ul>
          <li>
            <a href="https://hexdocs.pm/phoenix/overview.html">Get Started</a>
          </li>
        </ul>
      </nav>
      <a href="http://phoenixframework.org/" className="phx-logo">
        <img src="/images/phoenix.png" alt="Phoenix Framework Logo" />
      </a>
    </section>
  </header>
)

export default Header

assets/js/components/Main.tsx

import * as React from 'react'

const Main: React.FC = ({ children }) => (
  <main role="main" className="container">
    {children}
  </main>
)

export default Main

assets/js/pages/index.tsx

import * as React from 'react'
import { RouteComponentProps } from 'react-router-dom'
import Main from '../components/Main'

const HomePage: React.FC<RouteComponentProps> = () => <Main>HomePage</Main>

export default HomePage

That should do it.

Now, open our project's router.ex folder, and modify our routes in the "/" scope as follows.

-    get "/", PageController, :index
+    get "/*path", PageController, :index

Then, modify our template files so that it properly loads up our React code. In the base layout template, we can everything inside the <body> tag with our script.

templates/layout/app.html.eex

  <body>
    <%= render @view_module, @view_template, assigns %>
    <script type="text/javascript" src="<%= Routes.static_path(@conn, "/js/app.js") %>"></script>
  </body>

And now the Index page template. Be sure you set the id attribute to the one you set as the application entry point specified on app.tsx.

templates/page/index.html.eex

<div id="react-app"></div>

Sanity check

Now we're going to check if everything works. Run mix deps.get and npm install once again just to make sure, then run mix ecto.setup to build our database (if we have any set up). Then run mix phx.server, wait until the Webpack process is complete, then head over to localhost:4000.

If it works and you can see your webpage loading up, congratulations! Let's move on to the fancy part.

Creating additional pages with `react-router`

Now that we have our basic Phoenix server running, let's create several examples of the nifty things you could do with React. The most common example that people make when demonstrating the capabilities of React is a Counter app.

First, we're going add the Counter route to our Root.tsx file.

 import * as React from 'react'
 import { BrowserRouter, Route, Switch } from 'react-router-dom'

 import Header from './components/Header'
 import HomePage from './pages'
+import CounterPage from './pages/counter'

 export default class Root extends React.Component {
   public render(): JSX.Element {
     return (
       <>
         <Header />
         <BrowserRouter>
           <Switch>
             <Route exact path="/" component={HomePage} />
+            <Route path="/counter" component={CounterPage} />
           </Switch>
         </BrowserRouter>
       </>
     )
   }
 }

Then, we'll add the Counter component.

assets/js/pages/counter.tsx

import * as React from 'react'
import { Link } from 'react-router-dom'

import Main from '../components/Main'

// Interface for the Counter component state
interface CounterState {
  currentCount: number
}

const initialState = { currentCount: 0 }

export default class CounterPage extends React.Component<{}, CounterState> {
  constructor(props: {}) {
    super(props)

    // Set the initial state of the component in a constructor.
    this.state = initialState
  }

  public render(): JSX.Element {
    return (
      <Main>
        <h1>Counter</h1>
        <p>The Counter is the simplest example of what you can do with a React component.</p>
        <p>
          Current count: <strong>{this.state.currentCount}</strong>
        </p>
        {/* We apply an onClick event to these buttons to their corresponding functions */}
        <button className="button" onClick={this.incrementCounter}>
          Increment counter
        </button>{' '}
        <button className="button button-outline" onClick={this.decrementCounter}>
          Decrement counter
        </button>{' '}
        <button className="button button-clear" onClick={this.resetCounter}>
          Reset counter
        </button>
        <br />
        <br />
        <p>
          <Link to="/">Back to home</Link>
        </p>
      </Main>
    )
  }

  private incrementCounter = () => {
    this.setState({
      currentCount: this.state.currentCount + 1
    })
  }

  private decrementCounter = () => {
    this.setState({
      currentCount: this.state.currentCount - 1
    })
  }

  private resetCounter = () => {
    this.setState({
      currentCount: 0
    })
  }
}

Now go to localhost:4000/counter and test your creation. If it works, we can continue to the next part.

Fetching APIs - a painless example

As mentioned earlier, almost every React + Phoenix tutorial that I ever found on the internet only went as far as rendering a single React component. They never seem to explain how to make both React and Phoenix properly so that they could communicate with each other. Hopefully this will explain everything.

Before you start, please please please make sure that on router.ex, you have the "/api" scope declared on top of the /*path declaration. Seriously. I spent a whole week figuring why my API routes aren't working, and then only recently realised that I had the routing declarations the other way around.

router.ex

  # ...

  scope "/api", PhoenixReactPlaygroundWeb do
    pipe_through :api

    # ...your API endpoints
  end

  # ...

  scope "/", PhoenixReactPlaygroundWeb do
    pipe_through :browser # Use the default browser stack

    # This route declaration MUST be below everything else! Else, it will
    # override the rest of the routes, even the `/api` routes we've set above.
    get "/*path", PageController, :index
  end

When we have them all set, create a new context for our sample data.

$ mix phx.gen.json Example Language languages name:string proverb:string

router.ex

    scope "/api", PhoenixReactPlaygroundWeb do
      pipe_through :api

+     resources "/languages", LanguageController, except: [:new, :edit]
    end

You can also create a database seed to pre-populate the data beforehand. More information on how to do that is available on this Elixir Casts course.

Time for another sanity check! Run the Phoenix server and go to localhost:4000/api/languages. If everything works correctly, you should see either a blank or populated JSON (depending on whether you preloaded the database first or not).

If everything works well, we can now proceed to our component.

Root.tsx

 import * as React from 'react'
 import { BrowserRouter, Route, Switch } from 'react-router-dom'

 import Header from './components/Header'
 import HomePage from './pages'
 import CounterPage from './pages/counter'
+import FetchDataPage from './pages/fetch-data'

 export default class Root extends React.Component {
   public render(): JSX.Element {
     return (
       <>
         <Header />
         <BrowserRouter>
           <Switch>
             <Route exact path="/" component={HomePage} />
             <Route path="/counter" component={CounterPage} />
+            <Route path="/fetch-data" component={FetchDataPage} />
           </Switch>
         </BrowserRouter>
       </>
     )
   }
 }

pages/fetch-data.tsx

import * as React from 'react';
import { Link } from 'react-router-dom';

import Main from '../components/Main';

// The interface for our API response
interface ApiResponse {
  data: Language[];
}

// The interface for our Language model.
interface Language {
  id: number;
  name: string;
  proverb: string;
}

interface FetchDataExampleState {
  languages: Language[];
  loading: boolean;
}

export default class FetchDataPage extends React.Component<
  {},
  FetchDataExampleState
> {
  constructor(props: {}) {
    super(props);
    this.state = { languages: [], loading: true };

    // Get the data from our API.
    fetch('/api/languages')
      .then(response => response.json() as Promise<ApiResponse>)
      .then(data => {
        this.setState({ languages: data.data, loading: false });
      });
  }

  private static renderLanguagesTable(languages: Language[]) {
    return (
      <table>
        <thead>
          <tr>
            <th>Language</th>
            <th>Example proverb</th>
          </tr>
        </thead>
        <tbody>
          {languages.map(language => (
            <tr key={language.id}>
              <td>{language.name}</td>
              <td>{language.proverb}</td>
            </tr>
          ))}
        </tbody>
      </table>
    );
  }

  public render(): JSX.Element {
    const content = this.state.loading ? (
      <p>
        <em>Loading...</em>
      </p>
    ) : (
      FetchData.renderLanguagesTable(this.state.languages)
    );

    return (
      <Main>
        <h1>Fetch Data</h1>
        <p>
          This component demonstrates fetching data from the Phoenix API
          endpoint.
        </p>
        {content}
        <br />
        <br />
        <p>
          <Link to="/">Back to home</Link>
        </p>
      </Main>
    );
  }
}

All good! Now go to localhost:4000/fetch-data and give it a try.

The result

If you're still here, congratulations, your setup is complete! Run mix phx.server again and go through everything. If everything works, double congratulations!

You can now use this knowledge to build your next React + Phoenix application. The end result of this guide is available here for everyone to try out.

Good luck! Feel free to tweet at me if you have any questions.

Thanks to ~selsky for their help on proofreading this post!

Migrating to TypeScript, Part 1: Introduction and getting started

Resi Respati — Wed, 09 Jan 2019 09:48:00 +0000

Header image by Franz Harvin Aceituna on Unsplash.

TypeScript (TS) is a language which has seen quite a meteoric rise lately. It’s gone some favourable results on the 2018 State of JavaScript (JS) survey. It has even come to the point where big names like Kent C. Dodds started migrating into it.

To learn more about how the TypeScript type system works, and how it can help you, watch this talk by Anders Hejlsberg, the creator of TypeScript.

For many of us already using TypeScript, we could never imagine writing JS without it anymore. And with newly-added support for Babel compilation, it gets much easier to integrate with the rest of the JS ecosystem. But for many people looking to migrate their apps into it, it could feel a little too overwhelming. This gets further out of control when you’re looking at a medium/large-sized app, all already written in JavaScript.

A lot of TypeScript learning materials out there never seem to dive deep on migrating a well-matured app to TypeScript. Worse still, TypeScript does have their own, official migration guide - but it’s horribly outdated.

So in this series of posts, I try to outline my personal steps on how to migrate an existing codebase to TypeScript. The first part will go through the steps on preparing your project for the Big Rewrite. This includes setting up the TS compiler, and the basic essentials of the TypeScript compiler.

So what is TypeScript, exactly?

TypeScript is a superset of JavaScript that compiles to plain JavaScript code. It enables great tooling and developer experience through the power of static typing. Some of the improved JS experience being unlocked by static typing includes better refactoring tools, statement completion, and more.

TypeScript was authored by Anders Hejlsberg, known for being the lead architect of C# and creator of Turbo Pascal. TypeScript 2.0 was released on September 2016, with much-improved Node.js modules support and stricter null checking. Since then, the language is continuously improved with features like object rest/spread, --strict mode, conditional types, and more. TypeScript 3.0, released in July 2018, even has support for monorepos through project references.

To read more about TypeScript, I recommend the TypeScript Deep Dive book by Basarat.

Getting started with TypeScript

So to start off, we will need to set up our environment for TypeScript. There are two ways to set this up:

You use Babel 7 + TypeScript preset to compile, and have the TypeScript compiler only do the type-checking.
You use the TypeScript compiler to both type-check and compile your code.

Since we’re migrating from JavaScript, we can assume that we’re already using Babel in our development toolchain, so we can go with the first option. You can also run the second option and chain with Babel. But the first option is still better if we want to have finer control over the Babel presets/plugins we use as well.

Initialising the compiler

This guide will make use of TypeScript 3.2. It should work as well on any versions starting from 3.0+.

To get started with TypeScript, install the TypeScript compiler CLI by running:

$ npm install -g typescript

Then run tsc --init to initialise a tsconfig.json file with the default options. It lists out all the options available as well as an explanation, with the non-essential options commented out. The number of options may overwhelm you, but let’s break the config down to just the essentials.

tsconfig.json

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": false,
    "esModuleInterop": true,
    "downlevelIteration": true,
    "lib": ["esnext", "dom"],
    "module": "commonjs",
    "noUnusedLocals": true,
    "outDir": "dist",
    "skipLibCheck": true,
    "strict": true,
    "target": "esnext"
  },
  "include": ["src"]
}

This setup will take everything from the src and compile it into the dist folder. There are some other essential compiler options here, but we’ll go through them in the next section. To compile, run the tsc command.

Note: If you use webpack to compile things, you don’t need the outDir option!

Setting up build tasks

Now that the TypeScript compiler works, we can include it as a script in our package.json file!

{
  "scripts": {
    "build": "tsc"
  }
}

This way, you can simply run yarn build (or npm run build if you’re running npm) to build your project.

Wiring up the TypeScript Babel preset (Optional)

If you already use Babel to compile your ES6+ JS code, you can use the TS preset for Babel. Note that you need Babel 7 and above to use this.

{
  "presets": ["@babel/preset-env", "@babel/preset-typescript"],
  "plugins": [
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"
  ]
}

The TypeScript compiler supports all modern ES2015 features, as well as next-generaton ES features. Though one common pitfall is that you can’t use next-generation syntax newer than stage-3 , since TS doesn’t support it. This means that using proposed syntax like the pipeline will give you type errors. The proposal plugins should include the stage-3 features required for TypeScript transpilation.

Note that the Babel compiler only removes the types from your code. It does not do any extra type-checking! Make sure to run type-checking separately with tsc --noEmit. Or better yet, add it as a compiler option into your tsconfig.json:

{
  "compilerOptions": {
    "noEmit": true
  }
}

This option will run the TypeScript compiler without outputting any code, so it only runs type-checking. You can then add the tsc command to your package.json scripts, which will help if you use a CI system as well.

{
  "scripts": {
    "type-check": "tsc"
  }
}

Note: If you use Flowtype, you can’t use the Flowtype Babel preset together with the TypeScript preset. You have to choose one or the other!

`tsconfig.json` essentials

The above tsconfig.json file already contains the essential compiler options when working with TypeScript. Let’s go through the essentials one by one.

TS/JS interoperability

The TypeScript compiler can also be set up to type-check and compile JS files alongside TS files. allowJs allows regular JavaScript files to be compiled. If you want to also enable type-checking in JavaScript files, you can also enable checkJs. If you’re just getting started, it’s recommended to disable checkJs and manually enable per-file type checking. To do that, add a // @ts-check comment on the top of the JS file you’d like to type-check.

Another compiler option to take note of is esModuleInterop. This allows you to do default imports with CommonJS modules (e.g. import React from 'react';). For TS veterans, this option is similar to allowSyntheticDefaultImports. The only difference is that it added some helpers during compile time for improved Babel interoperability.

Libraries and compile targets

There are three options that define how your TS code is interpreted by the compiler.

lib outlines the TS library files used for compilation. Some libraries that are commonly used are:

esnext - Modern ESnext features (up to stage-3 recommendations)
es201x - Yearly ES specifications. Note than including one year will include all of the yearly specs before it (e.g. es2018 will also include es2017, es2016 and es2015).
dom - DOM-specific APIs.
webworker - APIs for Web workers.

target defines the target version of ES.

module defines the module type the TS compiler will generate. If you set target to es5 or below, it will default to commonjs (standard CommonJS modules for Node.js compatibility). Otherwise, it will default to esnext (ES Modules).

And that’s it for this part. In part 2, we’ll go through how to make your TypeScript migration painless by adding types gradually. We’ll also go through the quirks of TypeScript’s type system, as well as changing your way of thinking to write TypeScript apps.

Once again, I really recommend the TypeScript Deep Dive book by Basarat. His book on TypeScript has helped me a lot on learning this amazing language. Should you ever get stuck, the #typescript channel on the Reactiflux Discord server has a bunch of lovely people who know TypeScript inside and out. Feel free to hop in and ask questions!

Redux 4 + TypeScript: A type-safe approach

Resi Respati — Fri, 06 Jul 2018 16:09:40 +0000

This post is also published on my personal website.

Even when the JavaScript community is slowly growing mixed opinions about it, I couldn't help but continue using Redux. Its patterns on immutable state management has become all too familiar to us, and is especially useful when building large apps. Its TypeScript support is exceptional too, with much-needed improvements to its type declarations arriving in Redux 4.

I wrote a guide on it a few months ago, and it has received some amount of attention. The feedback has helped me improve beyond what I normally would've done, and I couldn't thank you enough for that.

In spirit of that, I finally took the time to update said guide based on the feedbacks I've received, making everything up to date with the latest version of React, Redux, and TypeScript, as well as introducing some neat new tricks.

Note that the following guide is tested on:

react@^16.4.0
redux@^4.0.0
react-redux@^6.0.0
typescript@^3.3.0

What we're building

To demonstrate this post, we're going to build a simple app. We're going to create a website which pulls data from the OpenDota API, and display information about certain heroes and professional teams. This will also demonstrate how to structure your stores for each feature/module in a Redux-enabled app.

TL;DR

If you want to jump straight to the examples, I've also published a sample project in GitHub, based on the feedback from my previous post. Click here to go there.

Updates

2018-12-08: Updated Dispatch to be imported from redux instead of react-redux. The guide is also now tested to work on TypeScript ^3.0.0. (Thanks cancerberoSgx!)
2019-01-05: Changed const enums to enums due to Babel not supporting it. (Thanks Kyle Gillen!)
2019-03-09: The latest version of react-redux broke the typings for the"children-props-as-redux-container" approach I mentioned in the previous version of this post. I would suggest against using this pattern nowadays, but if you still want to use it, I've upgraded the corresponding section in this article to have the same pattern, making use of the newly-introduced ReactReduxContext.
2019-09-22: The above pattern breaks on a Create React App setup. The entire LayoutContainer is now rewritten using built-in react-redux hooks.

Directory structure

I'll level with you, one of the hardest steps in getting started with working on React + Redux for me is figuring out how to structure your project. There's really no de facto way to do this, but it's still important to get this right so to not cause further distractions down the road. Here's how I normally do it.

Use a dedicated `store/` directory

A lot of the guides/projects out there structure their store separately inside a root actions/ and reducers/ directory, to mimic the patterns in Redux architecture.

(Note that the following directory trees assume that your code is placed inside a src/ directory.)

.
|-- actions
|   |-- chat.ts
|   |-- index.ts
|   `-- layout.ts
|-- components
|   |-- Footer.tsx
|   `-- Header.tsx
|-- containers
|   `-- ChatWindow.tsx
|-- reducers
|   |-- chat.ts
|   |-- index.ts
|   `-- layout.ts
|-- ...
|-- index.tsx
`-- types.d.ts

However, I personally find this to be distracting. When your codebase grows larger, you would end up scattering code which shares the same context across a great length of the directory tree, which wouldn't be intuitive for newcomers who wanted to take a quick glance at your code. Therefore, roughly following the Redux pattern in this case is less advantageous in terms of code readability.

So I decided to dedicate a store/ directory for all my Redux actions/reducers. This method is mostly borrowed from this guide made by Tal Kol of Wix, with a few adjustments.

.
|-- components
|   |-- Footer.tsx
|   `-- Header.tsx
|-- containers
|   `-- LayoutContainer.tsx
|-- pages
|   |-- index.tsx
|   |-- matches.tsx
|   `-- heroes.tsx
|-- store
|   |-- heroes
|   |   |-- actions.ts
|   |   |-- reducer.ts
|   |   `-- types.ts
|   |-- layout
|   |   |-- actions.ts
|   |   |-- reducer.ts
|   |   `-- types.ts
|   `-- index.ts
|-- ...
|-- index.tsx
`-- types.d.ts

Group stores by context

As an extension to the guides above, the state tree should be structured by context.

.
`- store
    |-- heroes // Handles application states inside the `/heroes` page.
    |   |-- actions.ts
    |   |-- reducer.ts
    |   `-- types.ts
    ├── layout // Handles global layout settings, e.g. theme, small/large text.
    |   |-- actions.ts
    |   |-- reducer.ts
    |   `-- types.ts
    `-- index.ts

Combine reducers inside `store/index.ts`

Include an index.ts file at the root of the store/ directory. We'll use this to declare the top-level application state object type, as well as exporting our combined reducers.

// ./src/store/index.ts

import { combineReducers, Dispatch, Reducer, Action, AnyAction } from 'redux'
import { connectRouter, RouterState } from 'connected-react-router'
import { LayoutState, layoutReducer } from './layout'

// The top-level state object.
//
// `connected-react-router` already injects the router state typings for us,
// so we can ignore them here.
export interface ApplicationState {
  layout: LayoutState
  router: RouterState
}

// Whenever an action is dispatched, Redux will update each top-level application state property
// using the reducer with the matching name. It's important that the names match exactly, and that
// the reducer acts on the corresponding ApplicationState property type.
export const createRootReducer = (history: History) =>
  combineReducers({
    layout: layoutReducer,
    router: connectRouter(history)
  })

Store types

Include a types.ts file inside each store module. This is where we hold our state types, as well as any other types related to this Redux store module.

// ./src/store/heroes/types.ts

// Response object for GET /heroes
// https://docs.opendota.com/#tag/heroes%2Fpaths%2F~1heroes%2Fget
export interface Hero {
  id: number
  name: string
  localized_name: string
  primary_attr: string
  attack_type: string
  roles: string[]
  legs: number
}

// This type is basically shorthand for `{ [key: string]: any }`. Feel free to replace `any` with
// the expected return type of your API response.
export type ApiResponse = Record<string, any>

// Use `enum`s for better autocompletion of action type names. These will
// be compiled away leaving only the final value in your compiled code.
//
// Define however naming conventions you'd like for your action types, but
// personally, I use the `@@context/ACTION_TYPE` convention, to follow the convention
// of Redux's `@@INIT` action.
export enum HeroesActionTypes {
  FETCH_REQUEST = '@@heroes/FETCH_REQUEST',
  FETCH_SUCCESS = '@@heroes/FETCH_SUCCESS',
  FETCH_ERROR = '@@heroes/FETCH_ERROR',
  SELECTED = '@@heroes/SELECTED'
}

// Declare state types with `readonly` modifier to get compile time immutability.
// https://github.com/piotrwitek/react-redux-typescript-guide#state-with-type-level-immutability
export interface HeroesState {
  readonly loading: boolean
  readonly data: Hero[]
  readonly errors?: string
}

Typing actions

Now that we have everything scaffolded, time to set up our actions!

Writing typesafe actions with `typesafe-actions`

Piotrek Witek created the typesafe-actions library, which provides useful helper functions to create type-safe Redux actions. We'll use this to write our Redux actions.

// ./src/store/heroes/actions.ts

import { action } from 'typesafe-actions'
import { HeroesActionTypes, Hero } from './types'

// Here we use the `action` helper function provided by `typesafe-actions`.
// This library provides really useful helpers for writing Redux actions in a type-safe manner.
// For more info: https://github.com/piotrwitek/typesafe-actions
export const fetchRequest = () => action(HeroesActionTypes.FETCH_REQUEST)

// Remember, you can also pass parameters into an action creator. Make sure to
// type them properly as well.
export const fetchSuccess = (data: Hero[]) => action(HeroesActionTypes.FETCH_SUCCESS, data)
export const fetchError = (message: string) => action(HeroesActionTypes.FETCH_ERROR, message)

Typing reducers

Typing reducers is a lot more straightforward with Redux 4.

// ./src/store/heroes/reducer.ts

import { Reducer } from 'redux'
import { HeroesState, HeroesActionTypes } from './types'

// Type-safe initialState!
const initialState: HeroesState = {
  data: [],
  errors: undefined,
  loading: false
}

// Thanks to Redux 4's much simpler typings, we can take away a lot of typings on the reducer side,
// everything will remain type-safe.
const reducer: Reducer<HeroesState> = (state = initialState, action) => {
  switch (action.type) {
    case HeroesActionTypes.FETCH_REQUEST: {
      return { ...state, loading: true }
    }
    case HeroesActionTypes.FETCH_SUCCESS: {
      return { ...state, loading: false, data: action.payload }
    }
    case HeroesActionTypes.FETCH_ERROR: {
      return { ...state, loading: false, errors: action.payload }
    }
    default: {
      return state
    }
  }
}

// Instead of using default export, we use named exports. That way we can group these exports
// inside the `index.js` folder.
export { reducer as heroesReducer }

Handling actions asynchronously with `redux-saga`

If your action dispatcher involves making numerous asynchronous tasks, it's better to include a library which handles side-effects on Redux. The two commonly-used libraries for this are redux-thunk and redux-saga. We're going to use redux-saga due to its cleaner API, which makes use of generator functions.

// ./src/store/heroes/sagas.ts

import { all, call, fork, put, takeEvery } from 'redux-saga/effects'
import { HeroesActionTypes } from './types'
import { fetchError, fetchSuccess } from './actions'
import callApi from '../../utils/callApi'

const API_ENDPOINT = process.env.REACT_APP_API_ENDPOINT || ''

// Here we use `redux-saga` to trigger actions asynchronously. `redux-saga` uses something called a
// "generator function", which you can read about here:
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*

function* handleFetch() {
  try {
    // To call async functions, use redux-saga's `call()`.
    const res = yield call(callApi, 'get', API_ENDPOINT, '/heroes')

    if (res.error) {
      yield put(fetchError(res.error))
    } else {
      yield put(fetchSuccess(res))
    }
  } catch (err) {
    if (err instanceof Error) {
      yield put(fetchError(err.stack!))
    } else {
      yield put(fetchError('An unknown error occured.'))
    }
  }
}

// This is our watcher function. We use `take*()` functions to watch Redux for a specific action
// type, and run our saga, for example the `handleFetch()` saga above.
function* watchFetchRequest() {
  yield takeEvery(HeroesActionTypes.FETCH_REQUEST, handleFetch)
}

// Export our root saga.
// We can also use `fork()` here to split our saga into multiple watchers.
export function* heroesSaga() {
  yield all([fork(watchFetchRequest)])
}

To include them in our root store, we add a rootSaga() generator function which collects all of our store sagas.

// ./src/store/index.ts

import { all, fork } from 'redux-saga/effects'

// We `fork()` these tasks so they execute in the background.
export function* rootSaga() {
  yield all([
    fork(heroesSaga),
    fork(teamsSaga),
    // `fork()` any other store sagas down here...
  ])
}

Initialising Redux store

Initialising the Redux store should be done inside a configureStore() function. Inside this function, we bootstrap the required middlewares (including redux-saga) and combine them with our reducers.

// ./src/configureStore.ts

import { Store, createStore, applyMiddleware } from 'redux'
import createSagaMiddleware from 'redux-saga'
// `react-router-redux` is deprecated, so we use `connected-react-router`.
// This provides a Redux middleware which connects to our `react-router` instance.
import { connectRouter, routerMiddleware } from 'connected-react-router'
// We'll be using Redux Devtools. We can use the `composeWithDevTools()`
// directive so we can pass our middleware along with it
import { composeWithDevTools } from 'redux-devtools-extension'
// If you use react-router, don't forget to pass in your history type.
import { History } from 'history'

// Import the state interface and our combined reducers/sagas.
import { ApplicationState, createRootReducer, rootSaga } from './store'

export default function configureStore(
  history: History,
  initialState: ApplicationState
): Store<ApplicationState> {
  // create the composing function for our middlewares
  const composeEnhancers = composeWithDevTools({})
  // create the redux-saga middleware
  const sagaMiddleware = createSagaMiddleware()

  // We'll create our store with the combined reducers/sagas, and the initial Redux state that
  // we'll be passing from our entry point.
  const store = createStore(
    createRootReducer(history),
    initialState,
    composeEnhancers(applyMiddleware(routerMiddleware(history), sagaMiddleware))
  )

  // Don't forget to run the root saga, and return the store object.
  sagaMiddleware.run(rootSaga)
  return store
}

Connecting with React

Now let's hook everything up with React.

Container components

Update: The latest version of react-redux broke the typings for the"children-props-as-redux-container" approach I mentioned in the previous version of this post. I would suggest against using this pattern nowadays, but if you still want to use it, here's a way to upgrade, using the brand-new useDispatch and useSelector hooks:

// ./src/containers/LayoutContainer

import * as React from 'react'
import { useDispatch, useSelector } from 'react-redux'

import { ApplicationState } from '../store'
import { ThemeColors } from '../store/layout'
import * as layoutActions from '../store/layout/actions'

// Redux-specific props.
interface LayoutContainerProps {
  theme: ThemeColors
  setTheme: (theme: ThemeColors) => void
}

// Wrapper props for render/children callback.
interface LayoutContainerRenderProps {
  render?: (props: LayoutContainerProps) => React.ReactElement
  children?: (props: LayoutContainerProps) => React.ReactElement
}

// ...

const LayoutContainer: React.FC<LayoutContainerRenderProps> = ({ render, children }) => {
  // We can use Hooks to call in our selector/dispatch functions.
  const { theme } = useSelector((state: ApplicationState) => state.layout)
  const dispatch = useDispatch()

  // Create the `setTheme` handler. We use the `dispatch` we got from `useDispatch()` to create said selector.
  const setTheme = (color: ThemeColors) => dispatch(layoutActions.setTheme(color))

  // Create a render/children props wrapper with the above variables set as a callback.
  if (render) {
    return render({ theme, setTheme })
  }

  if (children) {
    return children({ theme, setTheme })
  }

  return null
}

export default LayoutContainer

This way, we can use the Redux store linking from any component!

// ./src/components/layouts/Header.tsx

import * as React from 'react'
import LayoutContainer from '../../containers/LayoutContainer'

const Header: React.SFC = ({ children }) => (
  <LayoutContainer>
    {({ theme, setTheme }) => (
      <React.Fragment>
        <CurrentTheme>Current theme: {theme}</CurrentTheme>
        <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>Switch theme</button>
      </React.Fragment>
    )}
  </LayoutContainer>
)

export default Header

Page components

When connecting pure React components, it's a good idea to connect them at the page level. As a reminder, when mapping states/action dispatcher to a component, we need to combine the state/action dispatcher prop types of the store we're mapping to our component prop types as well.

// Separate state props + dispatch props to their own interfaces.
interface PropsFromState {
  loading: boolean
  data: Hero[]
  errors: string
}

// We can use `typeof` here to map our dispatch types to the props, like so.
interface PropsFromDispatch {
  fetchRequest: typeof heroesActions.fetchRequest
}

// Combine both state + dispatch props - as well as any props we want to pass - in a union type.
type AllProps = PropsFromState & PropsFromDispatch & ConnectedReduxProps

const API_ENDPOINT = process.env.REACT_APP_API_ENDPOINT || ''

class HeroesIndexPage extends React.Component<AllProps> {
  public componentDidMount() {
    this.props.fetchRequest()
  }

  public render() {
    const { loading } = this.props

    return (
      <Page>
        <Container>
          <TableWrapper>
            {loading && <LoadingOverlay />}
            {this.renderData()}
          </TableWrapper>
        </Container>
      </Page>
    )
  }

  private renderData() {
    const { loading, data } = this.props

    return (
      <HeroesTable columns={['Name', 'Legs']} widths={['auto', '120px']}>
        {loading &&
          data.length === 0 && (
            <HeroLoading>
              <td colSpan={2}>Loading...</td>
            </HeroLoading>
          )}
        {data.map(hero => (
          <tr key={hero.id}>
            <HeroDetail>
              <HeroIcon src={API_ENDPOINT + hero.icon} alt={hero.name} />
              <HeroName>
                <Link to={`/heroes/${hero.name}`}>{hero.localized_name}</Link>
              </HeroName>
            </HeroDetail>
            <td>{hero.legs}</td>
          </tr>
        ))}
      </HeroesTable>
    )
  }
}

Using `react-redux`'s `connect()`

The react-redux connect() function is what connects our React component to the redux store.

// ./src/pages/heroes.tsx

import { Dispatch } from 'redux'
import { connect } from 'react-redux'
import { ApplicationState } from '../store'

// ...

// It's usually good practice to only include one context at a time in a connected component.
// Although if necessary, you can always include multiple contexts. Just make sure to
// separate them from each other to prevent prop conflicts.
const mapStateToProps = ({ heroes }: ApplicationState) => ({
  loading: heroes.loading,
  errors: heroes.errors,
  data: heroes.data
})

// mapDispatchToProps is especially useful for constraining our actions to the connected component.
// You can access these via `this.props`.
const mapDispatchToProps = (dispatch: Dispatch) => ({
  fetchRequest: () => dispatch(heroesActions.fetchRequest())
})

// Now let's connect our component!
// With redux v4's improved typings, we can finally omit generics here.
export default connect(
  mapStateToProps,
  mapDispatchToProps
)(HeroesPage)

Additional helper type

We can also add a helper type for our connected Redux components.

// Additional props for connected React components. This prop is passed by default with `connect()`
export interface ConnectedReduxProps<A extends Action = AnyAction> {
  // Correct types for the `dispatch` prop passed by `react-redux`.
  // Additional type information is given through generics.
  dispatch: Dispatch<A>
}

So now on any Redux-connected component, we can extend its props interface with the interface above

// Extend the interface (for example).
interface ComponentProps extends ConnectedReduxStore {}

class Component extends React.Component<ComponentProps> {
  public componentDidMount() {
    // We can use the extended interface above as follows.
    this.props.dispatch(layoutActions.fetchRequest())
  }
}

Sample code

Hope you've found this guide useful! Based on your feedback as well, I've also published a sample project following the guides above on GitHub. Click here to go there.

References

To learn more about React, Redux, and TypeScript, the following guides are a good read:

Forem: Resi Respati

How I accidentally built a popular tool for Trackmania streamers: the story of TMViz

Motivation

First iteration

Second iteration

Ship, then bite your fingernails

How a side gig becomes a full-time job

Epilogue, and what's next

Please, tell us how you solved the problem.

Have you experienced this?

Tell us how you solved it.

Web Monetization API and Coil, explained for Twitch streamers

Why can't we just get along?

"How do you use a Next.js router in a class component?"

Supercharging your Next.js site with getStaticProps and getStaticPaths

The beginning: getInitialProps

Improved static-site generation

The results

Give it a try!

No, TypeScript is not a waste of time.

Yes, it’s longer to start writing statically-typed JS short-term…

…but the long-term effects are real!

You can adopt TypeScript incrementally

But what about dynamic, runtime values?

Static typing and testing go hand-in-hand!

Let’s clear our heads

Using TypeScript's absolute paths in Create React App 2.0 without ejecting

Before we start

Set up craco

Extend paths option from a separate file

Rewire webpack aliases using craco

Configure Jest’s moduleNameMapper

And that’s it!

Migrating to TypeScript, Part 2: Trust the compiler!

Thinking in TypeScript

But why is TypeScript important?

Strict mode

Linting

A quick primer to TypeScript types

Applying types

Primitive & unit types

Intersection & union types

types and interfaces

Generics

Declaration files

Let’s migrate!

From .js to .ts

Dealing with external modules

Phoenix with React: The Right Way™

TL;DR

Getting started

The boilerplate

Setting up React

Sanity check

Creating additional pages with react-router

Fetching APIs - a painless example

The result

Migrating to TypeScript, Part 1: Introduction and getting started

So what is TypeScript, exactly?

Getting started with TypeScript

Initialising the compiler

Setting up build tasks

Wiring up the TypeScript Babel preset (Optional)

tsconfig.json essentials

TS/JS interoperability

Libraries and compile targets

Redux 4 + TypeScript: A type-safe approach

What we're building

TL;DR

Updates

Directory structure

Use a dedicated store/ directory

Group stores by context

Combine reducers inside store/index.ts

Store types

Typing actions

Writing typesafe actions with typesafe-actions

Typing reducers

Handling actions asynchronously with redux-saga

Initialising Redux store

Set up `craco`

Extend `paths` option from a separate file

Rewire webpack aliases using `craco`

Configure Jest’s `moduleNameMapper`

`type`s and `interface`s

From `.js` to `.ts`

Creating additional pages with `react-router`

`tsconfig.json` essentials

Use a dedicated `store/` directory

Combine reducers inside `store/index.ts`

Writing typesafe actions with `typesafe-actions`

Handling actions asynchronously with `redux-saga`

Using `react-redux`'s `connect()`