DEV Community: Bartosz Wiśniewski

Fix your Express error handling now

Bartosz Wiśniewski — Wed, 09 Feb 2022 17:30:15 +0000

Express is probably one of the most influential packages in the Node.js world. It gave us an extremely easy-to-use interface for building REST APIs. It’s so popular that whatever can be put into middleware has probably one made for express already. Talk pino, jwt, validator, fileupload, basic-auth, http-proxy, and countless others. No wonder why people like to use it.

Promises, async, await

Promises are now the standard for async operations, especially since we also got async functions and await keyword, which totally removed the need for callbacks, thus preventing so-called callback hells.

Now you would think that one of the most popular packages in the world would just work with them, right? Well, not exactly.

When Express was initially developed Promises were not really a standard yet so instead, everyone was using callbacks. While the JS world evolved there is still a lot of callback-based APIs, especially in Node itself, like in the fs module. Luckily there is either a version with Promise API as well or we can actually use a utility called promisify.

Express kind of sucks

Express is not actively developed, which is understandable - in the end, it was meant to be unopinionated and minimalist. If something is great why bother changing that?

Except that there is actually version 5 of Express in “development”. It’s been like that for over 7 YEARS - 5.0.0-alpha1 was released in 2014 and it actually does improve a couple of things including the main problem of this post - error handling of Promises.

Yeah, if you read the documentation for error handling you would learn that error handling of promises is not done by Express - you have to do it yourself unless you are running Express 5.

So what happens when you ignore the docs? You will get the greatest exception in Node.js - unhandled promise rejection, which by default makes your process crash if you are using newer Node.js. Your Express error handler definitely will not be called and even the response will not be sent out to the client, so you won’t even see a 500 Internal Server Error. Just a timeout.

An example of how not to handle async errors:

const express = require("express");

const app = express();

app.get("/boom", (req, res) => {
  throw "This will be handled";
});

app.get("/boomasync", async (req, res) => {
  throw "This will not be handled";
});

app.use((err, req, res, next) => {
  if (res.headersSent) {
    return next(err);
  }
  console.error(err);
  res.status(500).send("Oh no!");
});

app.listen(3000, () => console.log("Listening on 3000!"));

Funny enough for a long time, I believe Node.js 14 was still like that, this unhandled promise rejection would only make an ugly log in the console. The default was not changed for a long time because people were afraid it wasn’t very user-friendly. I encourage you to check out the PR and post about it.

A brilliantly evil idea 😈

Fix

There is a lot of ways to fix this issue. You can just put .catch after every handler. You can use Express 5, the alpha version. You can use a custom router or middleware that handles this. You can use some magic patching package like express-async-errors. You can also not use Express.

All of these have some trade-offs, but I was happy with patching the express internals in existing codebases. For new projects, I rather use something better than Express.

TypeScript

Another problem I have with Express is in its TypeScript support. The definitions assume that the Request object is always the same, but the reality is completely different. Adding new fields to req is a common method for dependency injection. Take a look at how pino integrates with Express. It is adding a req.log object that you can use in your handler. However, since the definitions are constant TypeScript will scream at your code when you’ll try to use it.

Of course, you can just always declare the type yourself or you can use module augmentation, but that is not da wae.

Final words

There are many alternatives for Express - Koa, Hapi, Fastify, Hono, Nest.js are just a small sample of them. I personally like Koa. On the surface, it is very much like Express with some little modifications, but the ecosystem is much smaller. Definitely worth checking out.

I have found many senior developers not knowing about this problem so do ask your colleagues, this might be an interesting interview question. I even feel a bit stupid to post about it so late.

Happy coding!

How to test every widget in Flutter?

Bartosz Wiśniewski — Tue, 01 Feb 2022 17:16:08 +0000

I think everyone who wrote some widget tests had a moment where they didn’t know how to test their widget that uses some of the widgets from Flutter’s Material or Cupertino widgets. It’s often not obvious how to do it so it’s definitely not a reason to be ashamed asking questions like “How to test DropdownButton?”, “How to get Slider into a specific position?” or “How to test selecting a date using showDatePicker?”.

I could put here snippets on how to do it, but you probably already have them on your machine.

So in case you didn’t know, a Flutter installation requires you to download the whole Flutter repository. This repository aside from the source code also contains tests. Tests for everything inside Flutter, since they do care about tests. These tests are often tricky, non-trivial, or very specific. It’s hard to find tests like that in any tutorial.

So Flutter repository is a huuuuge source of great widget tests that you can learn from. Let’s say I want to see tests for Slider. You can find tests for that inside packages/flutter/test/material/slider_test.dart.

CupertinoTimePicker? No problem! Similar path packages/flutter/test/cupertino/date_picker_test.dart

And you don’t need to browse GitHub for that - you can open your local Flutter repository with your favorite editor. I wouldn't trust GitHub search, your VS Code or Android Studio can do much better.

Don’t Repeat Yourself

Sometimes getting something into the desired state can be a bit complex. If you find yourself having to do that often in your tests make sure to extract this logic into some function or method. like I did with my clickNextPageButton or _chooseDate. This really improves the readability of your tests, which is crucial for the idea of tests to work properly.

Hope you found this post helpful. I personally love learning from examples! Or maybe I am just copying pasting them 🤔 Anyway.

Happy coding! 💙

Dart and character encodings

Bartosz Wiśniewski — Wed, 15 Apr 2020 18:24:25 +0000

I work on an app that plans to use thermal printers. I am also a Stack Overflow user and I often hunt for interesting questions, especially regarding Flutter, so I saw this question:

How to print Asian languages to a thermal printer from Flutter?

This seemed pretty easy. The package for printers just could not implement all different charsets that printers use. Just add support and voila! Well, it’s not that simple.

Windows-1250 code page was used for languages such as Polish, Czech, Slovak, Hungarian, Slovene, Bosnian or Croatian and does not exist in Dart

Dart is missing a lot

You can love Dart, but the truth is that Dart is missing a lot of small features. We usually do get around them, but in this case — it’s really hard.
It turns out Dart does not come with support for many different encodings. It does have UTF-8, Latin1 (aka ISO-8859–1) and that’s all. Just a handful of Europeans can have their special characters encoded.

Looking for solutions

The first things I noticed were packages for GBK support, which is the character encoding for simplified Chinese. These are usually implemented with a huge map of codes, which is absolutely fine. However, this approach does not work for every language. Some, because of their complexity, need to have a couple of characters for one position in line and besides that — I am not gonna do them all.

There was also a package that used binding to C code of iconv, a program for converting encodings, a GNU project. This approach is valid, but binding is still in beta and it’s not so straightforward to do, at least for me, someone who didn’t ever work with C. I tried to use it, but I didn’t work at all 😕
I also looked at how other languages do it. The web is a perfect example with iconv-lite package, a pure JS implementation. I actually tried to port it into Dart, which isn’t that different from modern JavaScript code, but it wasn’t easy especially since iconv-lite applies many optimizations, specific to JS.

Platform

OK, a new idea, since Flutter, in the end, runs on some kind of platform, couldn’t we just use that? It turns out — yes and it’s a great option.
Android gives you Java, which has Charset class that can be used for encoding. iOS has CFStringEncoding and functions around that. Only web is actually problematic, but we can use iconv-lite package to fix that.

Of course, this solution leads to a dependency on the platform, but in this case, it’s not that bad. Charsets names are globally defined, independent on the platform, with some aliases, and all the platform has to do is to get bytes in one end and output in the other. Although it could also be convenient to get a list of all available charsets.

Solution

I got into this problem so deeply that I was encouraged to produce some results out of it. Since I had plenty of time during train travel I decided to create my first package — charset_converter. It’s not the fastest, not the best, but simple and good enough for most cases.

Since I got the thermal printer in the office I was also able to test my theory and answer mentioned Stack Overflow question and receive the bounty 😎

In the end, it was a good lesson and fun. I can also say that I somehow contributed to making Flutter more accessible for other cultures, cool isn’t?

Happy coding and stay tuned for the part where I describe how to publish your own package! 💙

Dealing with nulls in Dart

Bartosz Wiśniewski — Wed, 15 Apr 2020 15:30:21 +0000

Despite its young age and influence from other programming languages, Dart doesn’t really provide a null safety. Even classic Optional from Java doesn’t exist in Dart, even though is so simple to implement. A lot of people coming from Kotlin or Swift may see this as a huge disadvantage.

But that may change since couple days ago Dart 2.7 was released and with it — comes the preview of null safety. It drastically changes how types interact with nulls. It’s still an early preview so don’t expect too much, but the idea will probably remain the same. You can track the progress of this feature and read the docs behind it.

So let’s explore all the tricks Dart has to make your life easier when dealing with nulls!

Before we start: you can find the code executable here on DartPad

Null coalescing operator

Null coalescing operator or how Dart docs are calling it — if null operator is a double question mark ?? that checks if the object is non-null if it is — it returns its value, otherwise, it evaluates and returns the value of the second expression.

It is commonly used when applying default values or when merging objects. I will take hello world as an example:

?? operator helped us prevent ArgumentError by supplying a default string. We can even make it better with the assignment version of that operator.

But of course, this example is a bit stupid since we can just put the default value of the parameter…

Conditional member access

?? is useful, but the most common error we get with null is NoSuchMethodError. We get that because we are trying to access a member on null. To avoid that we can use ?. for accessing members, which will check if the object is null for us. If the object is null then the expression will also return null.

In case our email won’t match we would get an error, but thanks to ?. on it we will just get null, the same as if there was no group(1).

Of course, we can still stack ?. like normal member access, but we should be aware that if we want to avoid errors we need to use them on every call.

Null-aware spread operator

The last trick is so unique that it will probably become the classic job interview question.

It just doesn’t spread if the object is null.

Null safety

All the features I mentioned above don’t protect you against nulls, but rather make it convenient to handle. This changes with null safety, which will change how types work. That can be previewed in Dart 2.7, but don’t even try to use it normally yet.

So TLDR: int will become non-nullable type and new int? will be nullable, which will require a check before accessing the data. You will have to opt-in for that behavior and libraries/dependencies can opt-in separately.
You can check the examples on this special DartPad. You can also run Dart 2.7 with --enable-experiment=non-nullable to actually compile it.

Summary

Dart at this moment might not have the most secure typing system, but it is good enough. The tricks I just showed you will probably spare you many if (x != null) lines and that’s the point of this post — to avoid writing Dart like Java from 2011.

Dart is also constantly evolving and with null safety on the horizon, it seems to be a great future for Kotlin and Swift developers to move to Dart.
Happy coding!