Giter VIP home page Giter VIP logo

d's Introduction

Build status Windows status Transpilation status npm version

d

Property descriptor factory

Originally derived from d package.

Defining properties with descriptors is very verbose:

var Account = function () {};
Object.defineProperties(Account.prototype, {
  deposit: {
    value: function () {
      /* ... */
    },
    configurable: true,
    enumerable: false,
    writable: true
  },
  withdraw: {
    value: function () {
      /* ... */
    },
    configurable: true,
    enumerable: false,
    writable: true
  },
  balance: {
    get: function () {
      /* ... */
    },
    configurable: true,
    enumerable: false
  }
});

D cuts that to:

var d = require("d");

var Account = function () {};
Object.defineProperties(Account.prototype, {
  deposit: d(function () {
    /* ... */
  }),
  withdraw: d(function () {
    /* ... */
  }),
  balance: d.gs(function () {
    /* ... */
  })
});

By default, created descriptor follow characteristics of native ES5 properties, and defines values as:

{ configurable: true, enumerable: false, writable: true }

You can overwrite it by preceding value argument with instruction:

d("c", value); // { configurable: true, enumerable: false, writable: false }
d("ce", value); // { configurable: true, enumerable: true, writable: false }
d("e", value); // { configurable: false, enumerable: true, writable: false }

// Same way for get/set:
d.gs("e", value); // { configurable: false, enumerable: true }

Installation

$ npm install d

To port it to Browser or any other (non CJS) environment, use your favorite CJS bundler. No favorite yet? Try: Browserify, Webmake or Webpack

Other utilities

autoBind(obj, props) (d/auto-bind)

Define methods which will be automatically bound to its instances

var d = require('d');
var autoBind = require('d/auto-bind');

var Foo = function () { this._count = 0; };
Object.defineProperties(Foo.prototype, autoBind({
  increment: d(function () { ++this._count; });
}));

var foo = new Foo();

// Increment foo counter on each domEl click
domEl.addEventListener('click', foo.increment, false);

lazy(obj, props) (d/lazy)

Define lazy properties, which will be resolved on first access

var d = require("d");
var lazy = require("d/lazy");

var Foo = function () {};
Object.defineProperties(Foo.prototype, lazy({ items: d(function () { return []; }) }));

var foo = new Foo();
foo.items.push(1, 2); // foo.items array created and defined directly on foo

Tests

$ npm test

Security contact information

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.


Get professional support for d with a Tidelift subscription
Tidelift helps make open source sustainable for maintainers while giving companies
assurances about security, maintenance, and licensing for their dependencies.

d's People

Contributors

medikoo avatar timoxley avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

d's Issues

lazy example doesn't work?

Is the "lazy" example from the README still supported?

$ node -v
v0.10.29

$ cat package.json | grep '"d":'
    "d": "~0.1.1",

$ cat test.js
var d = require('d');
var lazy = require('d/lazy');

var Foo = function () {};
lazy(Foo.prototype, {
  items: d(function () { return []; })
});

var foo = new Foo();
foo.items.push(1, 2); // foo.items array created

$ node test.js 
foo.items.push(1, 2); // foo.items array created
          ^
TypeError: Cannot call method 'push' of undefined
    at Object.<anonymous> (/Users/michael/Projects/mach/test.js:10:11)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:906:3

Consistent getter declarations using d/lazy

Using d/lazy is a little confusing for me. Usually, when I define a getter using d, I use d.gs, like this:

function Person(name) {
  this._name = name;
}

Object.defineProperties(Person.prototype, {
  name: d.gs(function () {
    return this._name;
  })
});

(new Person('michael')).name; // "michael"

However, if I use d/lazy I can't use d.gs to define getters anymore. Now, I have to define my properties using d, which I normally use for defining functions.

function Person(name) {
  this._name = name;
}

Object.defineProperties(Person.prototype, lazy({
  name: d(function () { // note the use of `d` here instead of `d.gs`
    return this._name;
  })
}));

(new Person('michael')).name(); // TypeError: Property 'name' of object #<Person> is not a function
(new Person('michael')).name; // "michael"

Ideally I wouldn't have to change the style that I use to declare getters if I wrap my properties in d/lazy.

Consider 'deepLevel: true' option for autoBind

It should work similiarly to cacheName of lazy util, so allow functionality to work cross deep prototype chains, and not just on first level.

It needs to be discussed which configuration method is more dev friendly.
Possibly having option named deepLevel with default to false will make more sense in both utils, and cacheName by default should be name prefixed with $ (eventually additionally configurable)

restore d/d

Just had another thing break due to missing d/d :(

Could you please restore d/d until you bump major version?

> yo kraken

module.js:340
    throw err;
          ^
Error: Cannot find module 'd/d'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/usr/local/lib/node_modules/yo/node_modules/insight/node_modules/inquirer/node_modules/cli-color/node_modules/memoizee/node_modules/event-emitter/lib/core.js:3:16)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

semver plz

95cc8a4

d should have bumped a major version for this breaking change.

I know semver says 0.x == do whatever, but it's be nice if more people were comfortable with regularly bumping major versions even if they don't consider their module 'stable'. in fact, semver helps the most when your module isn't stable.

Rename the package?

Hello,

I'd like to formerly ask if you could reconsider the name of your package for something more meaningful. It's hard to know what a single letter package does, and there's another reason as well... Mistyping an npm i command by forgetting the - would install your package. Typing npm i d react (install d and react instead of mistyped react -d). There's also a - pacakge on npm, so mistyping a space would install both - and d packages.

Your lib seems cool, please don't troll other people.

Make it override friendly

When overriding existing property configuration, not listed characteristics is kept at it's current value, e.g. when overriding enumerable property, and not stating new value for enumerable, the property will stay enumerable.

Currently there's no way with d to maintain such defaults, we need to be explicit about all property characteristics, otherwise it'll be just set to false. That's a big downside

Possibly it could work that way:

  • d(value) - no configuration, keep current behavior { configurable: true, writable: true, enumerable: false, value })
  • d('c!w', value) - Pass only listed configuration properties, and if we want to negate setting, precede it with !. Therefore in this example it'll turn to { configurable: true, writable: false, value }

.

.

The # in ext-es5 breaks in Vite

According to this comment, that has been resolved in the ext package, but I am using a library that relies on d which in turn relies on the legacy package.

Yes, this is a bug in Vite and they are on it (vitejs/vite#2432), but for now I am blocked by this. Could you update the dependency?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.