Constructor for record with optional fields?

1

One nice thing about @deriving(abstract) was the ability to partially apply arguments before closing the function call. Rasonably this isnt possible with optional record fields…so…is there maybe a way to derive a constructor that gives the same behavior?

2

If you mean that the optional record field is {x?: string}, why do you want to keep using derving(abstract) attribute?

3

I dont want to keep using @deriving abstract, but i do want:

   type g = {x?: string, y?: string}
   let v = {x: "yes"}
   let w = v{y: "yes"}

The example I have in mind is that highcharts has many many instances of various configuration objects, with a type field that identifies which kind it is. In rescript then you end up with multiple separate type definitions each requiring the type field be a constant value. Id like to preapply that value in the bindings so that callers dont need to.

4

Maybe the @deriving(accessors) attribute could be changed to also generate a constructor function? Then that would be basically equivalent to what “abstract” did except without an abstract type.

5

One usage pattern is this:

let a = foo({x:"yes"})
let b = foo({y:"yes"})

Another usage pattern is this:

let a = r => foo({...r, x:"yes"})
let b = r => foo({...r, y:"yes"})

In the latter case, one can pass an initial r, such as {x:"yes"}.

6

I see. I’ve been through the same path before. My case was echarts. Yes, there are huge different cases usage of js object there.
How about this? I solved many cases before with it:

@unboxed
type rec chartOption = ChartOption({..}): chartOption

You can use like this:

Echarts.Instance.option(
  ~tooltip=Echarts.Instance.ChartOption({
    "trigger": "axis",
    "backgroundColor": "rgba(38,38,38,1)",
    "textStyle": {
      "color": "rgba(255, 255, 255, 1)",
    },
  }),
  ~grid=Echarts.Instance.ChartOption({
    "right": "16px",
    "left": "50px",
 }),
 ...
)

I hope this can help to solve your issue.

EDIT: definitely, there is a trade-off. It has to pay off the type safety about chart option value.

7

Really after all maybe its best to just make the users specify the “type” field value. its going to be obvious and required so not much pain…using Object and quoted key values everywhere is my least favorite.

Thanks
A