Some eslint fixes #428
Some eslint fixes #428
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| setSelectedSavedAddress(address); | ||
| updateAddressMutation({ | ||
| const _errors = await updateAddressMutation({ |
There was a problem hiding this comment.
Why do we need to assign response to a _errors?
Can'we just do this?
| const _errors = await updateAddressMutation({ | |
| await updateAddressMutation({ |
There was a problem hiding this comment.
I want us to come back to these places and actually handle errors… :D I'll add some @todo comments.
| // we sometimes use async functions that don't await anything | ||
| "@typescript-eslint/require-await": "off", |
There was a problem hiding this comment.
Offf... I really don't like this. We've specifically added this rule due to issues in API routes in Next.js - sometimes forgetting await caused unexpected issues on production that were not visible in development.
I know that this can be annoying (you need to add either void or await) but IMHO this is a worthy tradeoff. Since API routes are main use case, we could enable it only for them? 🤔
There was a problem hiding this comment.
I think you're talking about another rule – no-misused-promises or no-floating-promises maybe?
require-await is about ensuring you only add async to functions that actually use await and remove async when functions don't use await. Which, in my opinion, is pointless – we often want async functions which don't use await – we just want to make sure they return a Promise. I don't see any value in this rule apart from maybe very minor (negligible) performance hit for using async where sync function would be enough.
There was a problem hiding this comment.
I'll also enable "@typescript-eslint/return-await": ["error", "in-try-catch"], because we want to force return await inside of try…catch blocks and forbid it elsewhere.
packages/checkout-storefront/src/providers/BillingSameAsShippingProvider.tsx
Show resolved
Hide resolved
No description provided.