Add support for object literals

[dead-claudia]

This has indirectly come up in ES Discuss, in the context of a possible @lazy decorator.

Where we currently have methods for classes that can be decorated, I think object methods, getters, and setters could be decorated similarly to class instance methods, just with placement: "own" (which is obviously never going to be possible for any other type of method). In terms of grammar, you could just reuse the same grammar for class methods.

Object properties are deliberately left out, since a function works just as well, and it's easier to write, faster to call, etc.

[littledan]

We have discussed decorators object literals several times in the past. This proposal attempts to be consistent with decorators for object literals. TC39 has discussed and drafted a PR to tweak object literal semantics to enable this change.

Do you see decorators for object literals something that needs to be in the v1 proposal, or would it be OK to handle as a follow-on?

[dead-claudia]

@littledan It's okay as a follow-on. I'm not personally super invested in this, but you can probably find a few in that es-discuss thread who might. To be fair, the @lazy decorator idea isn't even mine, it's just something that makes the object decorator idea at least worthwhile for something beyond adding a column to the grid.

I didn't know it was already being considered by you all, so that's convenient. 🙂

[lehni]

I am very interested in object decorators and would like to see them considered soon. Would it increase the complexity of this proposal a lot?

[littledan]

Object decorators are blocking on this patch. If you want object decorators to move forward, we have to first decide either for or against it.

[ORESoftware]

afaict, decorators for objects is most useful for concise configuration objects

for example:

const v = {
  @bar('zoom')
  foo: getSomeObj()
}

it would be nice to be able to decorate by way of properties of objects - where the return value of getSomeObj() gets decorated.

[nicolo-ribaudo]

It could be done using the pipeline operator:

const v = {
  foo: getSomeObj() |> bar("zoom"),
}

[lazarljubenovic]

@nicolo-ribaudo Couldn't most decorator things be done by decorator(arguments, class {}) anyway?

[nicolo-ribaudo]

In classes, using a decorator like that you cant modify own fields, change the placement (static/own/prototype) and modify private elements.

[ORESoftware]

@nicolo-ribaudo well does your example mean something like this:

const bar = s => {
   return (target) => {
        // s is "zoom", target is return value of getSomeObj()
   }
};

[nicolo-ribaudo]

Yes 👍

[ORESoftware]

@nicolo-ribaudo can you show an example of using multiple pipeline operator arguments? I assume using decorators for objects literals is more likely than implementing the pipeline operator? I like the pipeline operator b/c it uses horizontal space instead of vertical space. (Decorators would use vertical space).

[nicolo-ribaudo]

can you show an example of using multiple pipeline operator arguments?

Do you mean something like getFoo() |> add(2) |> multiply(3)?

I assume using decorators for objects literals is more likely than implementing the pipeline operator?

Well, the pipeline operator is a stage 1 proposal, while a proposal for object decorations doesn't exist yet.

[ORESoftware]

@nicolo-ribaudo just curious can the pipeline go both directions?

getFoo() |> add(2)) <| multiply(3)) |> whatever(3)

I assumed it's borrowed from Elixir, but I don't know if it can go both directions in Elixir or not.

[nicolo-ribaudo]

No, the current proposal is only in one direction. We are going out of topic (@littledan maybe you could hide this conversation?). If you want more info you can find them at https://github.com/tc39/proposal-pipeline-operator

[adam-cyclones]

Please please support this feature, I don't want to use singletons just to write nice code.

[littledan]

I'd like to support decorators on object literals too! Let's do it in a follow-on proposal, as described in https://github.com/tc39/proposal-decorators/blob/master/NEXTBUILTINS.md#object-literals .

[mattdesl]

Chiming in to +1 support for object literals, for my purposes it would be to decorate object literals with properties for GUI features like so:

const data = {
  @UI.ColorPicker()
  background: 'blue',
  @UI.Range({ min: 0, max: 1, step: 0.01 })
  scale: 1
};

This is used in oui project here already and it would be nice to see it standardized, or at least included in decorator syntax, as not everybody working with JS uses classes:

https://github.com/wearekuva/oui

[dantman]

Chiming in to +1 support for object literals, for my purposes it would be to decorate object literals with properties for GUI features like so:

Oh, right I forgot about this pattern. This pattern is actively used in other languages. Notably in C# by the Unity engine, which depends on this pattern heavily.

[littledan]

This is still considered a follow-on proposal; see https://github.com/tc39/proposal-decorators/blob/master/EXTENSIONS.md#object-literal-and-property-decorators-and-annotations

[erickriva]

Any news about it?

[cha0s]

Throwing my +1 on this.

Example use case:

my-plugin.js:

import {secret} from '...';

export const defaultConfiguration = () => ({
  beds: 5,
  cups: 4,
  @secret
  password: 'CHANGE_ME',
});

...then later something like...

const secrets = somePluginConfiguation[Symbol.Secrets];
Object.entries(secrets).forEach(([key, value]) => {
  if ('production' === process.NODE_ENV || whatever) {
    return loadSecret(key);
  }
  else {
    return value;
  }
});

[pzuraq]

This is still considered out of scope for this proposal, and will potentially be considered for a follow up proposal.

[pzuraq]

I'm going to close this issue for the time being given we are not actively seeking to add it to this proposal.

[ruoru]

{
  benchmarkIndexList: [],
  @observable benchmarkPerformanceList: [],
}

Any news about it?