panzerdp / dmitripavlutin.com Goto Github PK

Update async await post according to this feedback:

This is a helpful description. Some of your arrows don't land however. For example, you state:
The first approach is callbacks. When an async operation had been completed, a special function named callback is called:

asyncOperation(params, result => {
// Called when the operation completes
});

but there is no function named callback in the example code. The callback function is actually named result. This kind of disconnect is not an issue for anyone familiar with the concept of callbacks, but for an absolute noob, some of whom will find your post, it could derail them completely, in the opening section!

I get the following error on trying run the project locally. I used the command "npm run dev". Thanks

Add a section describing the difference between a callback and closure.

const { timeout = 8000 } = options;

This is confusing.

Hi Dmitri,

Is there a typo on line 52 in calling the const duplicated as the arrow function multiplies the array numbers by 2.

Should this const be named doubled instead?

I've opened PR#26 with a fix if this is the case.

Regards

Fix Share on Facebook link title.

From this post: https://dmitripavlutin.com/typescript-index-signatures/

All those types can simply be replaced with the built-in Record<key, value> generic type:

const dictionary: Record<string, number> = {
  one: 1,
  two: 2,
  three: 3
}

for (const name in dictionary) {
  const num = dictionary[name]
}

Quoting from:

https://dmitripavlutin.com/when-not-to-use-arrow-functions-in-javascript/

This function is a good example of breaking the single responsibility principle:

const multiply = (a, b) => b === undefined ? b => a * b : a * b;

Which your guide would rewrite to:

function multiply(a, b) {
  if (b === undefined) {
    return function(b) {
      return a * b;
    }
  }
  return a * b;
}

Here the problem is not that we shouldn't use arrow functions. The problem is we shouldn't write such code at all:

• The name of the function is misleading. It could be called multiplyOrCurry or something like that, but that's the problem. The "And" or "Or" in function names is less disinformative, so that's better, but at the same time, now we see clearer that we are breaking the SRP.
• This is how currying should be done: https://javascript.info/currying-partials .
• The arrow function is only harder to read because it's too complex in the first place.

I know you probably wanted to show a fine example there because our gut feeling is that there should be some code out there that could be a proper example for when arrow functions are indeed hard to read. And indeed, the conditional operator (or also called ternary operator), is also often judged because it's too short, which especially hurts during nesting. Here we nest the conditional operator with the arrow, which in complexity is very similar to the nesting problem. Other than that, right now I can't give you a better example. But we surely shouldn't leave the documentation as it is.

The last code example in https://dmitripavlutin.com/typescript-function-overloading/ (which I believe is this markdown: https://github.com/panzerdp/dmitripavlutin.com/blob/master/content/posts/158-ts-function-overloading/index.md) is missing the ? for the second parameter param2. I believe it should be as follows:

// OK
function myFunc(param1?: string, param2?: string): string {
  // implementation...
}

function Pet(type, legs) {
  this.type = type;
  this.legs = legs;
  this.logInfo = function() {
    console.log(this === myCat); // => false
    console.log(`The $ {this.type} has $ {this.legs} legs`);
  }
}
const myCat = new Pet('Cat', 4);
// logs "The undefined has undefined legs"
// or throws a TypeError in strict mode
setTimeout(myCat.logInfo, 1000);

In that piece of code, you said that the console.log(this === myCat) statement would return false, but it's actually returning true because logInfo is still taking the Pet object as context.

This is the first code example on that part.

In the post arrow vs regular, mention you can't use call & apply on arrow functions.

Add comments count icon on the left side of the post, below the sharing icons.

Add examples section:

• how to toggle a boolean
• how to increment a number
• how to add items to an array ("usestate array")

Good article! But I think a clarification is necessary. Because you don't suggest a way to provide exception handling when there is just a return, it is easy to get the impression that the failure to catch means you should always do return await. This is not so.

Because await is needed only when the final result has to be accessed, which is not ever when returning a value from a function, return await usually should be avoided. In fact, because an asynchronous function always returns a Promise object whether or not await is used, the function caller is stuck having to do await anyway. The net is that your application will be needlessly slowed down, since every await forces the asynchronous thread to return results to the caller. In fact, you will find linting environments that give you a warning when you do return await.

The bottom line is that only one await over the whole thing is usually all that is necessary. The last await will resolve all the pending promises in application, whether or not there are exceptions.

You can always do a try/catch to surround the caller.

async function divideWithoutAwait() {
    return promisedDivision(5, 0);
}

async function run() {
  try {
    const result = await divideWithoutAwait();
  } catch (error) {
    // Rejection  caught!
    console.log(error);
  }
}
run(); // Cannot divide by 0

or if you prefer to leave the exception handling in the method:

async function divideWithoutAwait() {
    return promisedDivision(5, 0).catch((err) => { console.log(err); });
}

async function run() {
  const result = await divideWithoutAwait();
  return result;
}

run(); // Cannot divide by 0

[2, 100, 3].sort(); // [100, 2, 3]

To share easier a section, add a link icon near heading.

E.g.

Hey,
Thanks for the amazing post regarding the this keyword in javascript. Super helpful!

Just noticed that the factory pattern javascript.info link throws a 404 error within https://dmitripavlutin.com/gentle-explanation-of-this-in-javascript/#42-pitfall-forgetting-about-new.

Link - https://javascript.info/class-patterns.
Not sure where was this resource moved.