ReScript and EdgeDB

Interop with other JavaScript/TypeScript code is a top priority​

While ReScript is its own language entirely, it’s designed to integrate nicely into your existing JavaScript applications with little effort and a small footprint. This means it’s easy to use your ReScript code from your JavaScript/TypeScript code, and your JavaScript/TypeScript code from your ReScript code.

Because of that, the buy-in required to use ReScript is minimal. You’re up and running very fast, and you can use it for as much or as little as makes sense for your needs and your application. You don’t need to rewrite your entire app in ReScript (unless you want to of course). You can start with a single function or a single component.

Compiling to JavaScript enables interesting features​

However, since ReScript has its own syntax, type system, and compiler, it has a bunch of interesting capabilities. Things like being able to give you ergonomic and efficient syntax, tools, and concepts not expressible in regular JavaScript but that the compiler can turn into optimized, efficient (and readable!) JavaScript. In fact, ReScript code compiled to JavaScript is often faster than hand-written JavaScript because the compiler can optimize things for you automatically.

Combined with great type inference, this lets you write expressive, maintainable, and clear code.

// inferred as: string => promise<option<user>>
let getUserById = async userId => {
  switch await Api.userById(userId) {
  | Ok(user) => Some(user)
  | Error(err) =>
    Console.error(err)
    None
  }
}

An example of what ReScript looks like. Useful types like the result and option types are built in, and you don’t need type annotations but still get 100% type safety.

Cool things ReScript can do​

Here’s a list of cool things that ReScript can do that will have a large impact on your day-to-day work as a developer once you learn them:

• Pattern matching. Once you’ve experienced good pattern matching, it’s hard to go back to not having it.

• pipe operator (->) for clear and efficient function chaining.

• Labelled, optional, and unlabelled function arguments. No need to use intermediate objects as the function argument just to be able to set arguments in a non-fixed order.

• Async/await, just like in JavaScript, but you can pattern match on it, and handle errors directly in your pattern match (no need for explicit try/catch).

• Powerful data modelling with variants and records.

• Type inference! Although rarely a good idea, the ReScript type system is powerful enough for you to write entire applications without a single type annotation if you’re so inclined, but still get 100% type safety.

// You can put switches and expressions anywhere, like here where we're
// assigning a switch to a variable.
let buttonClasses = switch (buttonSize, buttonType) {
| (Large, Primary) => "btn-lg btn-primary"
| (Large, Secondary) => "btn-lg btn-secondary btn-modifier"
| (Small, Primary) => "btn-sm btn-primary-sm"
| (Small, Secondary) => "btn-sm btn-primary-sm btn-modifier-sm"
}

// And you can put expressions anywhere, like in the middle of JSX. Pattern
// matching is really good, and the compiler will make sure you always
// handle all cases.
<div>
  <button className=buttonClasses>
    {React.string(
      switch (loggedIn, productStock) {
      | (true, InStock | AlmostSoldOut) => "Order item"
      | (true, ComingSoon) => "Pre-order"
      | (false, _) => "Log in to order"
      }
    )}
  </button>
</div>

Another example of what ReScript looks like. Pattern matching is handy and you’ll use switches all the time in ReScript.

We’ve of course barely scratched the surface of ReScript here, but this short segment should be enough of a precursor to understand the rest of the article, and how ReScript and EdgeDB can fit well together.

Let’s have a look at the integration between ReScript and EdgeDB and what synergies it brings.

Minimal manual plumbing and friction​

There’s not much more to it than that. With the above, you have pretty much everything you need. You can write EdgeQL co-located with the code that uses it, the types are automatically derived for you and kept in sync, and what you see is exactly what you get — no magic.

This is the whole basis for why this integration is ergonomic: because it means you can change and evolve virtually anything in your application with minimal friction but still maintain full safety. Make breaking changes in your queries as much as you’d like, and EdgeDB + ReScript will guide you through fixing your application.

As stated in the list of what I find important, this is really at the heart of it: getting rid of manual steps and friction.

EdgeQL is powerful!​

And, perhaps the most important part is that you’re using EdgeQL, the query language that’s at the core of EdgeDB. This means that what you see is what you get — there’s no magic or indirection. You write EdgeQL, which is first class in EdgeDB, and the exact EdgeQL you wrote is what runs.

This also encourages you to let the database do more work. You can always transform and work with your data in ReScript as you get it as well, but when using EdgeQL, it’s easy to do transformations, lookups, and the like where it’s the cheapest: right next to the data itself, in the database.

In-editor errors​

Errors should be in your editor, not hidden away in a terminal somewhere. Therefore, any errors in your EdgeQL queries are propagated into your editor, so finding them and taking action on them is easy:

Modifying, running, and exploring your queries in the native EdgeDB UI​

As previously stated, one of the main benefits of staying with EdgeQL is WYSIWYG (what you see is what you get). You write EdgeQL, and exactly that EdgeQL runs when you execute your code. This also means that running, modifying, and analyzing your queries can be really easy. For that, the editor tooling has an integration for opening your queries in the native EdgeDB UI so you can run/modify/analyze the query before putting the updated query back in your code with minimal hassle:

Static analysis of unused EdgeQL selections — no more overfetching​

ReScript has some powerful static analysis tools. Thanks to that, we’ve been able to build a CLI that can analyze your entire ReScript + EdgeDB project and tell you exactly which selections in your various EdgeQL queries are never used in your application. Since ReScript’s type system is sound, this is both simple and accurate.

This is a big asset, because you’ll be able to instantly remove any overfetching you might have, down on the property level. You can even run the CLI in your CI to make sure no overfetching ever makes it to production. When the CLI catches an overfetch, it looks something like this:

Analyzing project... (this might take a while)

✘ Found 3 unused selections.

File "PageSingleCompany.res":
- descriptions.company.name
- descriptions.company
- city.id

This functionality loops back to ReScript’s ability to let you fearlessly change things. Getting rid of overfetching is notoriously hard unless you can get guarantees from something like static analysis, because you need to know with 100% certainty that nothing else in your application is depending on the fields you remove or else you’ll break things.

EdgeDB tooling in the future​

As EdgeDB ships more IDE tooling themselves, this experience will get a lot better as well. EdgeQL autocomplete, refactors, code actions, and more will all contribute to a great experience once they ship.