Pull to refresh

Comments 10

А чтобы не бросать и этот процесс на самотек и гарантированно заработать искреннюю благодарность соратников по работе, можно где-то в середине цепочки изменить или даже обнулить свойство:

…
export function MiddleComponent({account}) {
account.accountType = null
return (
<LowComponent account={account} />
);
}
…

Заголовок не верный для такой статьи. Предлагаю "Вредные рецепты и как схватить ненависть своих коллег".

з.ы. Смеялись с коллегами долго.

Я так и не понял, то ли это "вредные советы", то ли еще что. Скажем первый совет про спред — весьма рабочий. При условии что проект на TS, и типы нормально описаны. А если на JS — то да, это уровень классического // happy debugging!

Необязательно, вполне может хватить prop-types, в некоторых моментах результат может быть даже лучше чем на ts

P.S. PropTypes не замена и не альтернатива, просто ещё один инструмент, который порой очень удобен.

Типы не спасут от того что так можно покинуть несуществующие пропсы в дом элементы.

Контексты можно тоже преопределять, притом хрен кто поймет в каком месте это поменяно. Особенно если использовать displayName по извращенному кодестайлу. И в отличии от props drilling, это точно хрен найдешь...

 export function MiddleComponent() { 
	return (
		<AccountType.Provider value="debet"> 
			<LowComponent account={account} />
		</AccountType.Provider>
	);
 }

а ещё можно провайдер завязать на функционал, который в зависимость берет туеву кучу параметров от родителя, который формируется на основе магии вуду индийского пошива.

а ещё можно каждый компонент обвязать 5-6 различными контекстами (каждый компонент конечно своим списком контекстов), каждый контекст из которых инициализируется в разных родительских компонентах...

я ещё знаю пару способов использования контекстов, которые заставят вашего разработчика сделать харакири, но их приводить не буду, так как запрещены Женевской конвенцией.

Про способ с локальными контекстами было недавно - https://habr.com/ru/company/alfa/blog/647013/

Имхо, вполне съедобная штука. Есть паттерн, есть теория к нему, есть, в конце концов, код-ревью для подстраховки соблюдения дисциплины при использовании - значит инструмент можно использовать.

почему нет совета использовать querySelector вместо ref? :) такое же тоже бывает

Поздравляем, вы приняты на работу, занесите в отдел кадров ведомость "Проклятия коллег 2010-2020"))

const formatNumber = cardNumber => {
  let cNumToStr = ''
  let it = 0
  
  String(cardNumber).split('').forEach((s) => {
    if (it % 4 === 0) {
      cNumToStr = cNumToStr + ' '
    }
    cNumToStr = cNumToStr + s
    it++
  })
  return cNumToStr
}

Отличная реализация форматирования! А то неопытный разработчик мог бы написать

const formatNumber = (cardNumber: string): string => cardNumber.match(/\d{4}/g).join(' ')

и немедленно вылететь с работы. Не за то ему платят, чтобы функции в одну строчку писать.

Кстати, еще один отличный совет: ни в коем случае, ни при каких обстоятельствах не использовать Typescript

Видимо у автора наболело)

К сожалению правда жизни такова что очень многие разработчики пишут код как будто учились по вредным советам. Был у меня в работе один проект, который начинал один мастер пера, я один компонент дорабатывал три дня что бы отредактировать один алгоритм внутри. В итоге мне надоело, я его с нуля написал, оказалось проще код выкинуть

Sign up to leave a comment.

Articles