Discuss
  • Shape objects

Shape objects

# Cyril Auburtin (6 years ago)

I wish JS had Shape objects, which would not only ease performance optimization for the benefit of JS engines ( youtu.be/5nmpokoRaZI?t=871), but also helps for validation, like an interface

shape Point { x: Number, y: Number, name: String };

const p = Point({x: 1, y: 2, name: 'foo'})

const p = Point({x: 1, y: 2, naem: 'foo'}) // throws

That object would have its properties immutable

I think proposal-first-class-protocols ( michaelficarra/proposal-first-class-protocols#27) could more or less directly do that feature

# Andrea Giammarchi (6 years ago)

StructType never really got a chance: developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/js-ctypes_reference/StructType

but it's also easy to have those kind of shapes in userland:

const shape = definition => {
  const keys = Reflect.ownKeys(definition);
  const key = k => keys.includes(k);
  function type(key, i) {
    var expected = definition[key];
    var current = this[key];
    return typeof current === 'object' ?
      (!expected ||
        current instanceof expected) :
      expected(current) === current;
  }
  return class Shape {
    constructor(details) {
      const k = Reflect.ownKeys(details);
      if (
        k.length !== keys.length ||
        !k.every(key) ||
        !k.every(type, details)
      )
        throw new TypeError('wrong shape: ' + k);
      Object.freeze(Object.assign(this, details));
    }
  }
};
# Bob Myers (6 years ago)

The engines already do these optimizations.

# kai zhu (6 years ago)

I wish JS had Shape objects, which would not only ease performance optimization for the benefit of JS engines (youtu.be/5nmpokoRaZI?t=871, youtu.be/5nmpokoRaZI?t=871), but also helps for validation, like an interface

shape Point { x: Number, y: Number, name: String };

const p = Point({x: 1, y: 2, name: 'foo'})

const p = Point({x: 1, y: 2, naem: 'foo'}) // throws

@cyril, you are thinking too low-level. given how time-constrained most web-projects are, shape-validating low-level library-code is poor-allocation of a backend-engineer’s time, that could be better spent on integration-level interfaces (e.g. browser <-> server interface) where most of these validation painpoints occur, e.g. [1]:

// frontend-request
POST /api/v2/createPoint
{ "x": 1, "y": 2, "naem": "foo" }

// useless backend-response
500 Internal Server Error or TIMEOUT

// better backend-response (that can be reasonably debugged)
400
{
    "message": "400 POST /api/v2/createPoint - object body must have property \"name\"",
    "statusCode": 400
}

[1] shape-validate integration-level interfaces with swagger kaizhu256.github.io/example-esdiscuss-topic-shape-objects/assets.swgg.html, kaizhu256.github.io/example-esdiscuss-topic-shape-objects/assets.swgg.html

kai zhu kaizhu256 at gmail.com

# Cyril Auburtin (6 years ago)

Thanks for the replies, Optimization was not the main concern, sorry for being confusing, I was just reminded of that idea from the video

Of course there are languages like TS which allow this, but I think it would be natural step for JS to integrate this. Like said, it allows validation, enforce a structure constraint, code editors could use this new types to give autocompletion, etc..

I don't think eslint could catch a typo in an object property

@kai_zhu: Yes, at a network level, things like GraphQL or swagger allows dynamic validations, I was more thinking directly at a language level and more 'statically' (even if it doesn't make sense for JS, it would open doors for tools and editors)

Le sam. 16 juin 2018 à 14:03, kai zhu <kaizhu256 at gmail.com> a écrit :

# Jordan Harband (6 years ago)

See michaelficarra/proposal-first-class-protocols which may address what you need.

given how time-constrained most web-projects are

This is no more true, or universal, for web projects than it is for any project.

shape-validating low-level library-code is poor-allocation of a

backend-engineer’s time Validating anything is a good use of an engineer's time, frontend or backend. Bugs are much more costly than writing code.