21 Matching Annotations
  1. Oct 2022
    1. Note: For keyword parameters, use @param, not @option.

      I sure was looking for @option (knowing already about @param) and assuming/expecting that (if it exists) it would totally be the right thing to use for documenting keyword parameters. So I was quite surprised to see this much-needed warning (for me and others like me who came here expecting/assuming the same thing).

  2. Jan 2022
  3. Sep 2021
  4. May 2021
  5. Apr 2021
  6. Jan 2021
    1. I've reproduced, in a very simple way, what I would like it to do: https://svelte.dev/repl/2b0b7837e3ba44b5aba8d7e774094bb4?version=3.19.1

      This is the same URL as the original example given in issue description.

      I'm guessing what happened is they started with that one, made some changes, and then I think they must have forgot to save their modified REPL (which would have generated a new, unique URL).

  7. Dec 2020
  8. Oct 2020
    1. In a large code base, this will result in moving imports randomly around until stuff just happens to work. Which is often only temporary, as a small refactoring or change in import statements in the future can subtly adjust the module loading order, reintroducing the problem.
    1. Looks like the problem is that debounce defaults to waiting for 0 ms ... which is completely useless!

      It would be (and is) way to easy to omit the 2nd parameter to https://lodash.com/docs/4.17.15#debounce.

      Why is that an optional param with a default value?? It should be required!

      There must be some application where a delay of 0 is useless. https://www.geeksforgeeks.org/lodash-_-debounce-method/ alludes to / implies there may be a use:

      When the wait time is 0 and the leading option is false, then the func call is deferred until to the next tick.

      But I don't know what that use case is. For the use case / application of debouncing user input (where each character of input is delayed by at least 10 ms -- probably > 100 ms -- a delay of 0 seems utterly useless.

    2. It looks like you accidentally passed resolve() (immediately invoking the function) directly to setTimeout rather than passing a function to invoke it. So it was being resolved immediately instead of after a 1000 ms delay as intended.

      I guess this is the "immediately invoked function" problem.

      Not to be confused with: immediately invoked function expression. (Since it is a regular named function and not a function expression.)

    3. You should not create a new debounce function on every render with: return new Promise(resolve => { debounce(() => resolve(this.getIsNameUnique(name)), 2000); }); Instead you should just wrap your whole function isNameUnique with the debounce (see my sandbox). By creating a new debounce function on every hit, it cannot 'remember' that is was called or that is will be called again. This will prevent the debouncing.
    1. _.debounce creates a function that debounces the function that's passed into it. What your s.search function is doing is calling _.debounce all over again every time s.search is called. This creates a whole new function every time, so there's nothing to debounce.
    2. I run s.search() by typing into an input box, and if I type gibberish very quickly, the console prints out "making search request" on every key press, so many times per second -- indicating that it hasn't been debounced at all.
    3. they're not invoking the function that _.debounce returns
    1. When using React hooks there is no concept of onMount because the idea of only running some code on mount leads to writing non-resilient components, components that do one thing when they mount, and then don’t take prop changes into account.
  9. Sep 2020
    1. Just throwing in <div class="{$$props.class || ''} otherChildClass"></div> seems the easiest, and it'll avoid undefined classes. I feel like many aren't noticing the undefined values getting inserted in their classes.
  10. May 2020
  11. Apr 2020
    1. Remember to call super in any subclasses that override teardown.

      And yet the Rails core chose not to use RSpec, citing how it would be too easy to write subject == expected on accident?

  12. Jan 2020
    1. Please do not make the mistake of trying to reduce the HAVING clause with a little false relational algebra to: 1 HAVING COUNT(PS1.plane_name) = COUNT(H1.plane_name) because it does not work; it will tell you that the hangar has (n) planes in it and the pilot_name is certified for (n) planes, but not that those two sets of planes are equal to each other.