Pushing `nullable` to the edge

,
1

I currently have a type in my application layer that has some option properties. I’m using a library (Automerge) that requires that values are JSON-like, so no properties can be defined as undefined or it throws a runtime error. I have a few options (no pun intended) about what to do here, but I’m trying to get a sense of what the most idiomatic/ergonomic solution here might be:

  1. Use Js.Nullable.t instead of option in my application domain model and pass null for the nulalble properties instead of undefined.
  2. Strip the undefined keys by stringify->parse before passing to Automerge.
  3. Something else I haven’t thought of?

I guess the basic question is how much of a smell is using Js.Nullable.t “inside” of the application domain and if it’s pretty smelly, what are some common patterns to push that type closer to the JS-edge?

2

Hi @scotttrinh, another option is to write JSON encoder/decoders for your types.

ReScript has some JSON encoder/decoder functions available for primitive types.

Otherwise you might like to use a JSON encoding/decoding library:

I’m personally using Jzon.

1 Like
3

Yeah, that’s a good call, I should think about that more deeply. The way Automerge works is a little less like a traditional “backend” where you just throw JSON over a network call, so this is more that the type of data that you interact with at the application level needs to avoid objects that are not directly serializable to JSON.

There is probably still something there with being able to use something like Jzon to express that constraint when interacting with the Automerge data. I’ll have a think and poke around and report back on how that worked out.

1 Like