Feature suggestion: syntax for Js.Dict.t literals

[johnridesabike]

I've been working with code that uses "hash map" style JS objects, and the ReScript syntax for declaring them can be tedious. (Or rather, the lack of syntax to declare them is tedious.)

Consider this JS:

const data = {
  a: foo,
  b: bar,
  c: baz,
};

Compared with this ReScript:

let data = Js.Dict.fromArray([
  ("a", foo),
  ("b", bar),
  ("c", baz),
])

That's a lot of extra parentheses and brackets to express the same thing. When you inline it somewhere (such as inside a function argument), then it's even more noisy and less readable.

My suggestion is to include a dedicated syntax similar to Js.t objects. Maybe something like this:

@dict
let data = {
  "a": foo,
  "b": bar,
  "c": baz,
}

Would this make sense to add?

[bloodyowl]

I think we could even have a generic system for simple, literal keys:

// Js.Dict
dict{
  "a": 1,
  "b": 2,
  "c": 3,
}

// Belt.Map.String
map{
  "a": 1,
  "b": 2,
  "c": 3,
}

// Belt.Map.Int
map{
  1: 1,
  2: 2,
  3: 3,
}

set{1, 2, 3} // Belt.Set.Int
set{"foo", "bar", "baz"} // Belt.Set.String

[johnridesabike]

That would be cool if it was possible, although that would have to still desugar/compile to function calls, right? Js.Dict can potentially compile to an object literal, which seems much simpler.

[bloodyowl]

I think I saw an issue on the compiler that @bobzhang opened some time ago that discussed the possibility to convert ˋfromArray` calls with literal to the data structure itself. I think it'd be fairly easy for dicts, but not sure about Belt data structures.

[jfrolich]

@bloodyowl: Love this approach!

[tsnobip]

@bloodyowl if calls to Js.Dict.fromArray with a literal array would be compiled directly to the given json object then it would totally make sense to have a dedicated syntax. But I wouldn't mind the slight runtime cost meanwhile.
I couldn't find the issue though, are you talking about #2320 ? It's more than 3 years old, I hope it'll get more love now ^^

[jaidetree]

@bloodyowl I would very much be in favor of that.

My use case in case there's a better way

module Icon = {
  @react.component
  let make = (~icon: option<string>=?) => {
    <img src={icon->Option.getWithDefault("/img/default-icon")} />
  }
}

module LabelWithIcon = {
  @module external hobbyIcon: string = "./hobby.svg"
  @module external memoryIcon: string = "./memory.svg"
  @module external standardIcon: string = "./standard.svg"
  let icons = Js.Dict.fromArray([
    ("Hobby", hobbyIcon),
    ("memory", memoryIcon),
    ("standard", standardIcon),
  ])

  @react.component
  let make = (~id: string, ~label: string) => {
    <label><Icon icon={icons->Js.Dict.unsafeGet(id)} />{label->React.string}</label>
  }
}

My rationale is that explicitly typing all the possible ids with a Record would be rather tedious. Additionally by definition of this type it does not really matter if an icon displays or not, it's a nice-to-have, but no one is going to miss them if they don't display. The fromArray works but it's a bit of a roundabout way to get there so a direct syntax would be awesome!

[stale]

The rescript-lang/syntax repo is obsolete and will be archived soon. If this issue is still relevant, please reopen in the compiler repo (https://github.com/rescript-lang/rescript-compiler) or comment here to ask for it to be moved. Thank you for your contributions.

[tsnobip]

I would still be in favor of having this feature.

[zth]

I also find this interesting. @tsnobip maybe open a new issue for it in the compiler repo?

[cknitt]

I'll transfer this one to the compiler repo.

[CarlOlson]

A couple of thoughts:

1. Having syntax that expands to Belt or Js will elevate those libraries, not all users want to use those implementation.
2. Js.Dict in particular is not safe. For example, using a Js.Dict with keys from a client, the client could set __proto__. Most devs wouldn't consider this kind of thing. ES6 Maps would be preferable.
3. This could be a good test case for an official PPX alternative. At the very least, it should be configurable due to the above reasons.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[zth]

Dedicated syntax was added recently.