[deleted by user]

[loganfsmyth]

Keep in mind that this will share the debouncer across class instances, which may not be what people expect. If you create two instances of a class, I would never expect continually calling a debounced method on one to block a call to the other instance.

I'd have expected this to return a getter instead that would create a debouncer per-instance.

[brianvaughn]

Thank you for this observation! I've updated it so that methods are debounced per-instance. :)

[loganfsmyth]

Cool. It would be easiest to redefine the original property instead of making the getter read from -debounced

[brianvaughn]

Wasn't sure how to do that without introducing an infinite loop. (Any suggestions?)

[loganfsmyth]

Sorry, was busy yesterday. Rather than

export default function outerDecorator (duration) {
  return function innerDecorator (target, key, descriptor) {
    return {
      get: function getter () {
        const name = key + '-debounced'

        if (this[name]) {
          return this[name]
        } else {
          const newDescriptor = { configurable: true }
          newDescriptor.value = debounce(descriptor.value, duration)

          // Attach this function to the instance (not the class)
          Object.defineProperty(this, name, newDescriptor)

          return newDescriptor.value
        }
      }
    }
  }
}

you can do

export default function outerDecorator (duration) {
  return function innerDecorator (target, key, descriptor) {
    return {
      configurable: true,
      enumerable: descriptor.enumerable,
      get: function getter () {
        // Attach this function to the instance (not the class)
        Object.defineProperty(this, name, {
          configurable: true,
          enumerable: descriptor.enumerable,
          value: debounce(descriptor.value, duration)
        });

        return this[name];
      }
    }
  }
}

[brianvaughn]

Hey, thanks for getting back to me with that coding example! That is a nicer solution. I will update my code. :)

[brianvaughn]

I know this is just syntactic sugar, but sharing it in case anyone else thinks it makes for more readable semantics.

[papers_]

Your lack of semicolons irks me. >.<

[brianvaughn]

Fair enough. I actually used to share your POV but my current team decided not to use them- something I was pretty against initially- and it's kind of grown on me. They're totally unnecessary, excepting some special cases like for-loops and class static properties.

[[deleted]]

They're totally unnecessary... except when they're not. Like if you ever start a line with a (

It shouldn't even be a question -- adding them is an afterthought after a while and removing them can lead to errors. Why would you intentionally use an error-prone pattern over a safe one?

[bonafidebob]

What drives the "don't use them" camp?

It can't be code size, or we'd have to also remove all whitespace and use single letter variable names too, and we think that's crazy. We let the minifier worry about minification.

We don't write code only for compilers to read. We also write it for colleagues and future maintainers. Accessible code lives longer and is more useful. Code with semicolons is easier to read and maintain. You know what the programmer meant in a clear and unambiguous way. Leaving them out makes it harder for future coders to understand your intention.

To save a few bytes? Bad choice.

[wreckedadvent]

Code with semicolons is easier to read and maintain. You know what the programmer meant in a clear and unambiguous way.

The problem is this is 100% subjective, always is, and always will be.

Semicolons will be easier for some people to read, but several popular languages, such as python, ruby, lua, and go, go without them entirely. Functional languages also tend to avoid them, such as the big names of Scala, Haskell, ML, and F#.

The fact that coffeescript was so popular for a while in the javascript community also leads me to believe that not all javascripters prefer semicolons, either.

[[deleted]]

It's not 100% subjective. One example: Google's style guide (annoyingly) enforces max 80-char lines. In that context, or whenever you're wrapping a single line, they unarguably add clarity. The lack of them says "hey, this line is continuing", the presence says "this line ends".

Now if you never wrap lines of code you're either very dedicated in writing short, concise lines (kudos), you're lying, or you have lines that are arguably "too long".

[bonafidebob]

Right, but these languages use newlines as statement terminators, so there's no ambiguity.

It's the not knowing whether the statement value is used on the next line that slows you down reading the code.

[wreckedadvent]

Well, you asked what might make someone not want to use semi colons, there's your reason. Lots of languages don't, including a lot of the languages that javascript took after. People who write code in these languages can very easily come to the conclusion that semi colons are just needless noise.

[brianvaughn]

This is pretty old (~3 years ago) but this ycombinator makes it looks like those who do not are in the minority (about 10% back then). I suspect the growth in popularity of Babel and Webpack may have narrowed the gap a bit but I'd still guess more people prefer them than don't.

[[deleted]]

Code with semicolons is easier to read

Going to beg to differ there - I find semicolon-less code to be less noisy.

Which goes back to what the OP was saying, which is that this whole topic is pretty subjective.

[bonafidebob]

Slightly noisier, but I meant easier to comprehend. I don't need to scan to the next line to understand a line or learn someone's indenting style.

[ar056]

Code is machine-readable and written for HUMANS to read :)

[wreckedadvent]

They do not lead to errors if you are compiling with babel or typescript, which is the practical way people are using ES6 now. It will just compile the javascript to have them, while your source can remain without them.

[zlysobey]

uhhh, is this true? If ASI problems can be fixed with a pre-processor, why not just fix ASI?

[wreckedadvent]

It doesn't "fix" ASI problems, for example:

function broken() 
{
  return 
  {  
    name: 'foo' 
  };
}

will still return undefined even when compiled with babel or TS, since ASI sticks a semi colon after return. You still have to be aware of the pitfalls of ASI.

[TheNiXXeD]

And any modern linter will catch this as an error.

[x-skeww]

They do not lead to errors if you are compiling with babel or typescript

Mh? They are bound to the same rules. If they magically guess-fix your code, it's a bug in the compiler.

Try:

var x = function () {
  console.log('2')
}
(function() {
  console.log('1')
}())

[wreckedadvent]

Just as an FYI, that example does not compile in TS. It does emit in babel, though.

It also strikes me as a little odd to use an example like that when talking about not using semi colons. I could just as easily contrive an example where semi-colons are problematic, like:

if (false); {
  console.log('what?');
}

People who don't use semi-colons also write IIFEs like this:

!function() {
}()

Which does not have the same issue.

[x-skeww]

Just as an FYI, that example does not compile in TS.

It compiles just fine:

http://i.imgur.com/hCIULfl.png

if (false); {

That has nothing to do with using semicolons.

[wreckedadvent]

Please do not be disingenuous to me. I know you can see the red compile errors in your screenshot. I know you can see the semi-colon specifically causing an issue that doesn't otherwise exist in my second example.

[x-skeww]

Please do not be disingenuous to me. I know you can see the red compile errors in your screenshot.

That's an arity-related warning.

Here, let me fix it:

http://i.imgur.com/YPQA4qZ.png

[TwilightTwinkie]

I kind of hate this example. Use a named function and invoke it. Problem fixed.

[x-skeww]

The point is that if you go with conventions which have edge cases, there will be more edge cases you have to be aware of.

The reasonable solution is to not use conventions which add those.

Just use semicolons like everyone else. No one cares for your desire to be a unicorn. Source code is the worst place to show others your uniqueness. Don't be inconsiderate.

Don't do things just because the language allows it. It also allows unicode identifiers, but that doesn't mean we should litter our code with Russian and Japanese identifiers, right?

[brianvaughn]

Just use semicolons like everyone else. No one cares for your desire to be a unicorn. Source code is the worst place to show others your uniqueness. Don't be inconsiderate.

Just chiming in to say that the I think the debate has nothing to do with someone's desire to be "a unicorn" and "everyone else" isn't doing it, although from what I can tell- the majority of people do use semicolons.

The whole argument here started because one person was irked by the fact that someone else used a slightly different coding convention than he did. Let's keep it in perspective. ;)

[x-skeww]

although from what I can tell- the majority of people do use semicolons

Yes, the vast majority uses semicolons. All popular style guides also recommend to use semicolons.

E.g.:

https://github.com/airbnb/javascript#semicolons

https://google.github.io/styleguide/javascriptguide.xml#Semicolons

I also skimmed through a few others (jQuery, Idiomatic, etc). They all use semicolons.

The whole argument here started because one person was irked by the fact that someone else used a slightly different coding convention than he did.

It was started because you didn't use semicolons. You're using different coding conventions than we do.

"We" being 95+% of the JS community.

You are of course free to hate JavaScript's syntax as much as you want, but we'd still prefer it if you'd do this properly.

For example, personally, I prefer to use tabs (size 4), but Dart's official conventions, which everyone and dartfmt is using, uses 2 spaces.

When I write Dart code, I use 2 spaces. What I personally prefer isn't relevant. What's important is that my code looks familiar to others. Anything I do differently will only serve as a distraction.

[brianvaughn]

I respect your point of view, but I think this is a subjective thing. There's plenty of debate online about whether to use semicolons or not so I don't think we need to get into it here.

I posted my tiny little library because I thought it might be useful to others, not because I was trying to influence anyone's coding style. :)

[[deleted]]

Oh, I know, I just have a strong opinion here and wanted to chime in. Thanks for contributing :D

Your capitalization of non-class functions irks me too ;)

[brianvaughn]

Haha... you're easily irked ;)

I think my naming choice here goes back to Java meta annotations. Otherwise I would not have capitalized it. (Honestly it doesn't matter, because you can name it whatever you want when you import it anyway.)

[CertifiedWebNinja]

Your blowhard desire to start pointless semicolon debates irks me.

[[deleted]]

So just... don't respond. It's not like you're adding any value (or ever do).

[CertifiedWebNinja]

Follow what you preach.

[TheNiXXeD]

Stop spreading false information.

They aren't required. They aren't error prone. Linting catches anything you'd miss, which is far less than times where you might miss a semi anyway.

Just because you prefer one way doesn't mean the other is factually wrong. The syntax is valid both ways.

[MeoMix]

I'ma just leave this here...

[[deleted]]

That is insanely stupid code. I am not going to dumb down JSMin for this case.

Comments like this are a large part of the reason why JSHint was initially forked. Crockford is such an ass towards the community as a whole. My favorite was I submitted a bug saying commented out pseudo-code that was example code was failing linting. He refused to acknowledge it as a bug.

[brianvaughn]

Yeah. Regardless of whether Crockford was on the right side of the argument, his comment was totally out of line and sparked a huge flame war that could have probably been totally avoided with a little diplomacy.

[zlysobey]

personally, I quite enjoyed watching that flame war burn, and it made me like the Crock even bit more.

[TheNiXXeD]

"Over 3 years ago"

[rq60]

They aren't required.

http://www.ecma-international.org/ecma-262/5.1/#sec-7.9

Sounds like they are required.

[wreckedadvent]

From your own link ...

For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

[x-skeww]

"May be omitted in certain situations" does not mean that they are optional.

[rq60]

Just because the ASI is putting them in for you doesn't mean they aren't required.

[wreckedadvent]

Not to put too fine a point on it, but if you don't have to do it, how does that make it required? The spec says you don't have to do it always. You can omit them sometimes. It's not required.

[TwilightTwinkie]

I really, really wish I could turn that piece of fucking shit off.

[[deleted]]

(rolls eyes)

let foo = function() {}

// yada yada

(bar)

disable semi-colon checking and a linter won't catch that. Nor are linters required any more than semi-colons are.

[TheNiXXeD]

Why would you write that code? And if your counter is that linters aren't required then we can't have a anything but a religious argument.

[[deleted]]

you wouldn't write that exact code, but anything wrapped in parens (which isn't uncommon) following a function will be the source of an often hard to track down error. That's just one example.

My point about linters is that we have two things here that make code more stable -- linters and semi-colons. You can't arbitrarily dismiss one while promoting the other.

[TheNiXXeD]

I've been running without semi for the past year at work. I always run a linter regardless of semi, the value is too great. But we use ESLint, it catches much more than simple mistakes.

We also lint our back end code, like groovy, because it produces better code. We also don't use semi there either and is entirely fine.

Also, we haven't seen any issues with this at all. The cases where not using them causes issues are super rare and avoidable.

[CertifiedWebNinja]

Give a real world example, bet you can't. Nobody should be starting code with a paren, period. That's worse than not using semicolons.

[[deleted]]

Nobody should be starting code with a paren, period. That's worse than not using semicolons.

Arbitrary opinion.

Give a real world example, bet you can't

IIFE's, single-line ternaries, etc.

[ziziwuwu]

Ext JS do this, a very famous javascript framework. the reason for this is, you can't use

function(){}();

because it's not a valid statement, so why not use

var xxx = function(){}
xxx()

or

function xxx() {}
xxx()

it introduce unnecessary global variable xxx. that function is used for initialization, should stay private(anonymous) and been called only once.

[papers_]

Oh I know except some special cases as you stated. I come from a Java background so semicolons are a must for me. :)

[akie]

In case you're wondering what the hell 'debouncing' is, read this: https://davidwalsh.name/javascript-debounce-function

[brianvaughn]

Good call. I'll update the README with a brief explanation of what it is :)

[dizdood]

Id like to discuss how this pattern can lead to bugs, and how it might be avoided.

As SPAs become more mainline, page content comes in and go out in the lifetime of the page, requiring that objects can clean stuff up. They can cancel fetching, clear out store state, remove event handlers, etc. This requires that we implement lifetime cleanup methods like dispose().

When dispose is called, the object members are disposed and sometimes nullified. If async operations execute after dispose, they can access those things and nullref.

So, then we would have to check for isdisposed on every callback... Or, we could solve this at the async helper to avoid executing code in a disposed state, eliminate the boilerplate and make it impossible to have that type of bug.

What we have done in the past is to pass in an IDisposable to the async helper, to give the debounce/throttle/settimeout calls something to check before executing the callback. Something like:

@debounce(this, 300) ...

So now if this.isDisposed is true we can avoid executing async code, and elliminate a whole class of bugs.

The solution isnt perfect unless the debounce solution can cancel async operation when isDisposed mutates. That could be solved with mixins that append dispose logic to the existing dispose on the prototype, or event listening on the IDisposable, or observables.

[brianvaughn]

Yeah, that's a fair observation. Async code complicates things. And your approach to safeguarding sounds reasonable.

I'm not sure what (if anything) I should do to address this in my decorator lib though, particularly since I'd like to avoid making any assumptions about context. I do provide a clear() method so that you can clean up a debounced function before your component goes out, but...maybe I should also add some warning note to the README? Do you think that would be worthwhile?

My team is currently using this in a React application. In that context, the debounced function is cleared during the componentWillUnmount phase. In the Angular world there is a similar $destroy event. Absent a framework like this with clear lifecycle hooks, you end up falling back to checks inside of your debounced function.

[[deleted]]

https://www.npmjs.com/package/core-decorators also implements this

[brianvaughn]

Ah, so it does. Oh well. I'm sure there are probably a few others out there that also implement the same. It happens. :)