Comments 28
<button @click="e => doSomething(e) ^ doSomethingElse(e)" />В отличии от операторов || и && он не восприимчив к возвращаемому значению и выполняет всю цепочку
- Не используйте хаки
condition && invocation()вместоif (condition) invocation(). - Умоляю, не используйте оператор-запятую (кроме разве что с
for()) - Не используйте ^-xor хак выше
Вместо всего этого — пишите простой и понятный код. Именно это в конечном счёте имеет ценность. Не экономьте строчки и символы без явной на то выгоды. Не превращайте ваш код в нечитаемое месиво. Выбирая между "так будет понятнее, но многословнее" и "там будет короче, но сложно для восприятия" почти всегда выбирайте первое. Разумное исключение — сосредоточение сложной логики в одном месте, вместо размазывания его по всему коду.
Разве что если ваша работа не сводится к написанию write-only кода… Тогда можно писать ногами.
Не используйте хаки condition && invocation() вместо if (condition) invocation().
Кстати видел довольно удобное применение этому в React для опционального рендера, примерно так:
<div>
{isCondition && <SomeComponent1 />}
<SomeComponent2 />
<SomeComponent3 />
{isAnotherCondition && <SomeComponent4 />}
</div>
А в бизнес-логике такое смотрится довольно странно, согласен
С изобретением JSX количество тернарных операторов в мире увеличилось вдвое:)
Кстати видел довольно удобное применение этому в React
Это потому что проектируя JSX его создатели намеренно проигнорировали:
- условия и прочие вветвления
- итераторы
Аргументируют это тем, что используя {} вы можете вставить любой JS-код. Скажем всякие хаки ? A : undefined, A && B, c.map(...).
У меня от это уже года 4 бомбит. Есть решение — jsx-control-statements. Но, к сожалению, это почти никак невозможно с TypeScript (ввиду того как устроена там поддержка plugin-ов). Поэтому пришлось съехать снова на эти && хаки.
А tsx-control-statements не может в сужение типов. Условно:
<If condition={optionalField in obj}>
{obj.optionalField /* error */}
</If>Для него это просто обёртка.
А ещё tsx-control-statements не умеет в удобные <For each="element" of={source}/>. Причину описал выше — TS как language server не даёт возможности патчить TS код до вывода типов. Его плагины умеют только в патчинг выходного JS кода
Когда смотрел в сторону ангуляра, эти различные
<div *ngIf="condition">Content to render when condition is true.</div>как-то отпугнули.
Да, в реакте вроде как выглядит похоже
<Component prop={value} />но для меня разница больше ментальная, так как в случае ангуляра добавляются кастомные данные в обычные html теги (о нет, только не это), а в реакте — в кастомные компоненты, для них вроде как можно :)
Ну и из таких же соображений я не переходил на реактовые хуки, их работа _не очевидна_ со стороны
На вкус и цвет, как говорится
Когда смотрел в сторону ангуляра, эти различные *ngIf как-то отпугнули
Меня всегда удивляли эти нападки на синтаксис vue, angular, svelte. Это как всерьёз обсуждать форму ручек дверей внедорожников. Сложные и важные вещи, которые и определяют всё, лежат далеко вне плоскости этого синтаксического сахара. Важно то как оно работает. Как там потоки данных гуляют. Как и чем обеспечивается реактивность. Какие проблемы и сколь эффективно решает инструмент. Я так в своё время отказался от Vue2. У него очень приятный шаблонизатор, но что от него толку, с такой моделью observable. Я могу сколь угодно восхищаться их вкусностями в директивах вроде .prevent и .keyUp.esc, но пока оно не умеет в прямые зависимости одних computed значений от других, я лучше выберу другой инструмент.
Ну и из таких же соображений я не переходил на реактовые хуки, их работа не очевидна со стороны
Ну так можно долго бегать. Бегать от ФП, от хуков, от контейнеризации, от… от чего угодно незнакомого на самом деле. Кто-то даже от GIT-а бегает и заливает обновы по FTP. Я с большим удивлением для себя открыл что очень многие мобильные разработчики до сих пор делают руками, то что в web-е реактивно уже лет 5-10. Показываешь им магию реактивности — морщат носы и отнекиваются. Мол это медленно, это непонятно, нам так нельзя, мы лучше по старинке будет всё руками писать. Моя их не понимать.
Лучше проверить и не вызывать, чем вызывать, проверить и не вызывать.
Хех. Не вызывает он ничего. Если бы вызывал, никому бы он нафиг не сдался, уж поверьте. Это babel-plugin, который как раз <If/>-ы в эти хаки с && и преобразует. И именно поэтому у него проблемы с TypeScript, т.к. оный просто не умеет в плагины трансформации TS AST.
Ну только не {isCondition && <SomeComponent1 />} конечно, а {Boolean(isCondition) && <SomeComponent1 />}, так как этот оператор приводит к boolean лишь при сравнении, но выводит в итоге оригинальное значение. Была в одном известном проекте система прав и пермишенов, основанная на 0 и 1 вместо булеанов, то есть isCondition был при отсутствии прав === 0, соответственно на странице оказывалось немало нод-нулей, отчего ехала верстка. А так как разработчиков было много, пришлось очень тщательно следить за этим на код-ревью.
{!!isCondition && <SomeComponent1 />} покомпактнее будет тогда и ещё один "трюк". Но лучше типы по назначению использовать всё-таки.
Интересно было бы почитать комментарии минусующих. Airbnb считают этот подход наилучшим, но применительно к React дело даже не в чьём-то мнении, а в том, чтобы минимизировать смещение блока кода вправо, нарушающее иерархию.
А что, если поле ввода допускало бы и дробные числа (типа 16.56)? Тогда для преобразования пришлось бы использовать "parseFloat()"?
Можно всегда использовать parseFloat. Number.isInteger(parseFloat('15.0')) возвращает true.
event.target.valueAsNumber
На картинке рядом видно, что еще бывает .valueAsDate (для <input type="date"/> и т.д.)
Мои любимые трюки в JavaScript
Трюков тут от силы штук 5, остальное — возможности языка из документации (isArray, destructuring, spread operator, шаблонный строки и др.). Еще бы написали про «трюк» как создать переменную…
Мои любимые трюки в JavaScript