Один принцип, который делает разработчика middle+
Заголовок кликбейтный, но я собираюсь его оправдать.
В разработке самое главное понимание касается не того, как написать код, а того, как он должен работать. То есть — нужно понять, как должна работать система в целом и на корнер кейсах, и как она будет развиваться дальше. Чтобы разобраться в сложных кейсах, разработчики обычно смотрят, как сделано в других местах или ориентируются на лучшие практики, но самый правильный путь — понять, какова бизнес цель ваших действий, тогда сразу станет понятно, как следует сделать.
Приведу пример.
Недавно мой менти делал Input с ограничением длины ввода и задал максимальную длину ввода пропсом max?: number | string
На вопрос, зачем здесь string, он ответил, что где-то читал, что так лучше.
Давайте подумаем. Мы делаем компонент, который будут использовать другие разработчики нашей системы. В таком случае мы можем потребовать, чтобы строка конвертировалась в число до передачи в компонент. Таким образом мы делаем нашу границу более строгой. Что нам это дает?
1. В Input меньше кода => легче поддержка
2. Меньше потенциальных багов и возможностей ошибиться
3. Унификация кода
Получится, что мы должны затипизировать так: max?: number.
Если развить эту мысль, то мы можем прийти к выводу, что ограничение длины должно быть обязательным. Например, для расчета ширины. И тогда получится max: number.
Следует ли из этого, что нам всегда следует типизировать пропс именно так? Нет. Можно легко найти сценарии, где решение моего менти будет более подходящим. Например, если вы делаете библиотеку для JavaScript-разработчиков. JS не подскажет корректный тип, и им слишком легко ошибиться — с нашей стороны логично будет их подстраховать.
📌 Таким образом, когда вы принимаете решения, ориентируйтесь на целесообразность и бизнес-потребность. Не бывает никакого “хорошего” и “плохого” кода в вакууме, бывает хорошее решение конкретной задачи и плохое.
Заголовок кликбейтный, но я собираюсь его оправдать.
В разработке самое главное понимание касается не того, как написать код, а того, как он должен работать. То есть — нужно понять, как должна работать система в целом и на корнер кейсах, и как она будет развиваться дальше. Чтобы разобраться в сложных кейсах, разработчики обычно смотрят, как сделано в других местах или ориентируются на лучшие практики, но самый правильный путь — понять, какова бизнес цель ваших действий, тогда сразу станет понятно, как следует сделать.
Приведу пример.
Недавно мой менти делал Input с ограничением длины ввода и задал максимальную длину ввода пропсом max?: number | string
На вопрос, зачем здесь string, он ответил, что где-то читал, что так лучше.
Давайте подумаем. Мы делаем компонент, который будут использовать другие разработчики нашей системы. В таком случае мы можем потребовать, чтобы строка конвертировалась в число до передачи в компонент. Таким образом мы делаем нашу границу более строгой. Что нам это дает?
1. В Input меньше кода => легче поддержка
2. Меньше потенциальных багов и возможностей ошибиться
3. Унификация кода
Получится, что мы должны затипизировать так: max?: number.
Если развить эту мысль, то мы можем прийти к выводу, что ограничение длины должно быть обязательным. Например, для расчета ширины. И тогда получится max: number.
Следует ли из этого, что нам всегда следует типизировать пропс именно так? Нет. Можно легко найти сценарии, где решение моего менти будет более подходящим. Например, если вы делаете библиотеку для JavaScript-разработчиков. JS не подскажет корректный тип, и им слишком легко ошибиться — с нашей стороны логично будет их подстраховать.
📌 Таким образом, когда вы принимаете решения, ориентируйтесь на целесообразность и бизнес-потребность. Не бывает никакого “хорошего” и “плохого” кода в вакууме, бывает хорошее решение конкретной задачи и плохое.