[Question] What's mean `{..}` in rescript

I had meet {..} in https://github.com/tinymce/rescript-webapi/blob/main/src/Webapi/Dom/Webapi__Dom__MutationObserver.res#L5.

And when I try to use mutationObserver->Webapi__Dom__MutationObserver(node, xxx), I don’t know what type to put in xxx, and the official website lacks documentation on it, so I had to come to the community for help.


This means “any object”.

You can pass any object like {"foo":"bar"} or {"baz":1} and compiler will not complain, but of course you should pass valid options.

The rescript-webapi bindings are a bit unsafe there.


This unfortunately happened because all values in the observe options are optional. The original creators of webapi chose to use an open object here rather than what other parts of the library do, add an extra binding function to generate the options object with only the required values set. It’s one of many things on my list to clean up.

ReScript v10 should have a way to make this nicer, and we’ll probably release a major version update to webapi after that to use the new style (it will be a breaking change).

Documentation is definitely something that webapi needs help with. It does have a certain architecture style that once learned can help to explore what it offers, but there’s no guidance to get there.

For example, don’t use the __ modules. Those are only there for internal structure, the intended API is the Webapi sub-modules. To show what you’re trying to do:

observer->Webapi.Dom.MutationObserver.observe(node, {
  "subtree": true,
  "childList": true,
  "attributes": true,
  "attributeOldValue": true,
  "characterData": true,
  "characterDataOldValue": true,

Where any of the object properties can be omitted.

I tend to use open Webapi.Dom at the top of my files which then translates the above to just observer->MutationObserver.observe(...)


Yeah, the options pattern comes up a lot and very cumbersome to model currently. A middle ground between introducing an @obj decorated function, and just using an open object is this:

But yes, might be better to just wait for the new syntax.


Oh I actually logged a task on webapi to improve this 6 months ago :sweat_smile:

It’s not really new syntax, it’s a way to allow record fields to be omitted :slight_smile: