Leverage ES decorators

1

JS has stage 3 decorators proposal

Would it be posible/considered to use ES decorators from rescript?

@defineElement("my-class")
class C extends HTMLElement {
  @reactive accessor clicked = false;
}
2

Only inside of the %%raw() block, since ReScript doesn’t support classes directly.

1 Like
3

As you can see from the proposal, it’s just a (high-order) function.

1 Like
4

Rescript has builtin decorators (attributes), would it be possible to define them in user space?

5

there are ways to do it (PPX), but it’s overall poorly documented and heavily discouraged by the community because it complicates the upgrade of the compiler and creates breaking changes where it should not.

The core team is working hard to reduce the need for such user-land metaprogramming.

What are you trying to solve with custom decorators?

1 Like
6

Attributes in ReScript looks like ES decorators, but they really have nothing to do with each other outside of looking the same. Decorators in ReScript are arbitrary meta information attached to various parts of your code, that’s accessible only at compile time where something needs to process them into actual syntax in order for them to have any effect on the resulting code. Just like @tsnobip says, that’s typically PPXes, whether external or internal to the compiler. But in this case I don’t think there’s anything a PPX could do to emit that type of code.

However, if there are clear use cases one could explore what it’d mean to have a dedicated attribute for ES decorators, that is then emitted as actual code. Just like we do today with @directive for functions to emit things like 'use client' for React Server Components. There are a lot of things to figure out around type checking and similar though.

This specific feature is probably easiest to solve by just using what this desugars too like @cometkim says (higher order functions). But, speaking in general - we’re always interested in looking into functionality that supports concrete and important use cases in JS. But, keep in mind that in general the JS features we target needs to be stable/standardized.

2 Likes
7

sorry, was trying to do stuff like in typescript, but now understand that rescript promotes a different thinking model, ES decorators a used a lot on class based frameworks like lit or mobx but rescript only has records

some things on rescript are obvious for Ocaml devs, but not so obvios for javascript developers, at least at first

2 Likes
8

That’s great feedback. What could we do to improve that? A section in the docs, or more content in the docs addressing people coming from JS/TS specifically?

1 Like
9

It seems like a pretty tricky problem to explain something that looks similar but is different. Understanding the syntax with a JS background is just as dangerous as understanding the syntax with an OCaml background.

After all, we can’t inherit all the features of another language to support a JS framework, the choice of language is a framework-side decision. Instead, we can provide proper extension points to interop.

For example, we have PPX that can do code generation, it’s possible to make user-level integrations more similar. For example, Lit’s @customElement decorator actually:

const customElement = (tagName) => (classOrTarget, context) => {
  if (context !== undefined) {
    context.addInitializer(() => {
      customElements.define(tagName, classOrTarget));
    });
  } else {
    customElements.define(tagName, classOrTarget);
  }
};

So it can generate the same function, or even generate more efficient pre-optimized code if you want.

I know it doesn’t sound simple, but it’s all we have so far.