Introduction For basic syntax, functional programming does not feel that different from other paradigms. Sure, data and behaviour are separate, so you don’t have classes or objects or inheritance, but it feels relatively the same. This is especially true in Rescript, with the pipe-first syntax almost looking like a method lookup (comparable to the self object in Python). But if you go deeply into a study of functional languages, you start encountering bizarre words such as “monad” and “functor”.
Parsing dynamic content such as JSON in a statically typed language can be rather daunting. This article voices some opinions about schemaless design and migrates some of the messy json parsing code from the standard library to the excellent jzon library.
In a recent article I introduced rescript-zora, a library I wrote for unit testing Rescript code with lightning fast responses. One drawback of zora is that it’s very minimal. In this article, I explore some design principles and go on a bit of a rant about the definition of the word “unit”.
I wrote Rescript bindings to the zora test framework and wanted to write about how to actually use them.
Continuing my explorations of RxDB and Rescript, this article hooks up mutations to allow RxDB to automatically sync its offline-enabled changes to the graphql server.
I’ve become quite comfortable in Rescript over the course of the past few months. So far in this long-running series, I’ve implemented an RxDB powered offline-enabled application in Rescript. I’ve also written a graphql server using express. In this article, we’ll connect the two so that the RxDB frontend can sync with the graphql database.