(prop === 'string' && someFlag ) 'a'
if (prop !== 'string' && someFlag) 'b'
prop === 'string' && someFlag ? 'a' : 'b' это же не одно и тоже
а вроде одно) могу ошибаться.
Что значит "одиночные выражения" ?
Нет, разное Ни а ни б не выведется если someFlag falsy В тернарнике же в таком случае будет b
if (someFlag) { prop === 'string' ? 'a' : 'b'; }
не заменяйте if тернарником - вот и всё
а вообще можно более развёрнуто
cпс , а если так: if (prop === 'string' && prop2 == 'string' ) 'a' if (prop !== 'string' && prop2 == 'string') 'b' вот тут тернарник обломится , переменные одни и теже в условиях , но условия по разному трактуються нежели просто привести выражения к булевому true / false
Это заведомо кривой код
> тернарник обломится Любое выражение можно засунуть в тернарник, и оно даже будет работать, проблем тут нет. Но, как сказали выше, так лучше не делать.
да у меня в if всё стоит , это именно из этого разряда на понимание тернарников я хотел 2 if перевести на тернарник поскольку переменные одни и теже, но такое условие под тернарник не сочинил) ну вот вообщем пища для раздумий: if (connection.name === event.target.value && fieldMeta.error !== msgError) { setFieldError(field.backendId, msgError) } if (connection.name !== event.target.value && fieldMeta.error === msgError) { setFieldError(field.backendId, undefined) }
А почему во втором случае undefined вместо msgError? Странно выглядит логика. setFieldError вроде должен устанавливать что-то, а ты туда undefined. Может хоть пустую строку для однообразия?
да это изначальное значение которое там стояло, типо live change валидация
А что значит второе условие в обоих ифах? В первом вроде понятно , если не равны сообщения об ошибках то переписать новым сообщением, а насчёт логики второго не понятно.
undefined руками - дурной тон. вспомните о семантике
да кто только не сказал. дурной тон уже подразумевает, что это вкусовщина есть null для этого
потому что оно в циклах , что бы setField не срабатывал количество итераций это типо триггер ,
Обсуждают сегодня