Блог

Это фрагмент моего кода:

 const data = await fetch(url, options)  .then(res =gt; res.json())  .then(json =gt; {  const payID = json.data.id  sessionStorage.setItem('payID', payID)  return true  })  .catch(err =gt; console.error(`error: ${err}`))  

Какова ваша лучшая практика? Сохраняете ли вы .catch в разработке и постановке, но удаляете его из PROD? Линтер не хочет, чтобы в моем коде была ошибка консоли.

1. В разработке: Мы используем как визуализатор ошибок, например, модальное ПО ошибок промежуточное программное обеспечение консоли/регистратора ошибок.
2. В постановке и производстве: Мы используем только визуализатор ошибок, такой как modal, потому что вы никогда не будете ожидать, что пользователь или тестировщик черного ящика команды(в случае тестирования промежуточного развертывания) перейдет к консоли. Итак, какой смысл утешать в производстве? Обратите внимание, что утешением в производстве может быть даже утечка информации, чтобы хакеры могли четко знать, что происходит. Поэтому я предлагаю никогда не использовать консоль в постановке/производстве, потому что все, что попадает в постановку, означает, что оно попадет в производство после завершения тестирования(поэтому производство и постановка имеют одинаковые правила).

Итак, что касается этой штуки Eslint, я предлагаю вам отключить ее в файле eslint и просто помнить о правиле не ставить ненужную консоль. Для меня то, что я делаю перед фиксацией кода для запроса на извлечение, заключается в следующем: SHIFT CTRL F, а затем введите «console.log», чтобы узнать, в каких файлах находится консоль.метод регистрации в моем VS-КОДЕ, а затем я удаляю их.

Мы не можем оставить линтер решать все за нас, я бы рекомендовал оставить console.error , потому что в большинстве случаев нам нужно видеть эти ошибки в консоли и читать их, они существуют не просто так.

И для стиля письма, конечно, мы можем использовать point free стиль

 .catch(console.error)  

И для линтера, скорее всего, есть правило(в их документации), чтобы отключить эту ошибку.