jayphelps/core-decorators

@debouce - deprecation discussion

Closed this issue · 6 comments

I'm know that @debounce already exists on lodash, but I don't want to use it for the following reasons:

  • I'm using ramda.js
  • I'm associate my decorators to core-decorators
  • I don't want to add a heavy library to my code only to use the debounce

why don't you re-export from lodash?

thanks in advance

If you use lodash-decorators you can import individual decorators, without importing everything, like this:

import debounce from 'lodash-decorators/debounce';

class Foo {
  @debounce(200)
  test() {
    // stuff
  }
}

Or if you want to use just core-decorator's @decorate with the raw lodash debounce function, you can probably do that too, but I can't haven't tested it so there may be issues dealing with prototype inheritance (e.g. incorrectly sharing timers between instances)

import debounce from 'lodash/debounce';
import decorate from 'core-decorators/lib/decorate';

class Foo {
  @decorate(debounce, 200)
  test() {
    // stuff
  }
}

I don't want to duplicate the effort of lodash-decorators, which indeed is basically just decorator wrappers around lodash.

What's the schedule on removing these deprecated features? Some of the tests failing when I try to use TypeScript with core-decorators are around deprecated features.

@BurtHarris there's no real schedule. Whenever.

Closing this ticket as there hasn't been a response and I think I answered their question. Lmk if not.

If lodash/decorators already have all anotations, why should I continue to use core/decorators?

@allangomessl that doesn't sound like a question.

@jayphelps I get your intention, but this is kind of a bummer since it adds some bulk even when using:

import debounce from 'lodash-decorators/debounce';

Webpack Bundle Analyzer:

I also have to change all my import statements, and there are many. I guess you've made up your mind, but I 100% agree with the reasons listed by @allangomessl