Красивые каскады условий в JS?

Question

[nickerlan]

Я написал кусок кода и плююсь от того, насколько он противный.
Как сделать лучше?

var token = ""
var cook=cookie.parse(document.cookie)
if (cook&&cook.ptq) token=cook.ptq;
 if (token)
{
   axios.get(BACKEND_URL+'/complete',{params:{
     token
   }}).then(d=>d.data).then(console.log)
}

Тут есть два момента.
1. Во-первых, я хочу избавиться как-то от цепочек условий
Хочу писать выражения в духе cookie.parse(document.cookie).ptq, а то и более к сложные каскады свойств a.b.c.d.e вызывать без if (a && a.b && a.b.c && a.b.c.d) { }
Слышал что какой-то костыль на эту тему есть в lodash, не уверен что достаточно изящный.

2. Во-вторых, я хочу найти более изящный способ прокидывать внутрь if значение выражения которое стояло в условии. Задавать переменную, проверять ее, потом использовать внутри эту переменную вызывает эстетическую боль:

var complicatedObject = (...) //какое-то длинное выражение. Поиск какого-нибудь значения в выборке например.
if (complicatedObject.key=="someValue")
{
   doSmth(complicatedObject)
}

Есть ли какие-то штуки в духе примера ниже?

(...someComplicatedExpression...)
.if (v=>v.key=='someValue')
.then(v=>{ doSmth(v) })

Answer 1

[Robur]

JS не самый лаконичный.
Есть приемы чтобы сократить код, но это нормально если вы пилите мелкие проекты которые и проектом назвать сложно.

например
token && axios.get(...)
не делайте так.

вместо if (cook&&cook.ptq) token=cook.ptq; можно написать var token = cook && cook.ptg || null
так можно.

в целом - лучше писать более структурировано, чем более коротко.

1) есть костыли но будет только хуже. пишите свои обертки под конкретные случаи и весь шум прячьте туда
2) ничего не понятно. Если у вас условие прописано в коде - то вам не нужно ничего "прокидывать" - у вас уже и так понятно что оно выполнилось что чему равно внутри - просто пишете код исходя из этого.

Comments

[nickerlan]

Под "прокидывать" я имею ввиду использовать результат выражения, прописанного в if (...) внутри его тела { }
Частый юзкейс очень.

Пишу какой-нибудь await Users.findOne({token:String(token)})
Прежде чем использовать объект полученный от монго, я должен проверить нашел ли кого-то

пишу if (await Users.findOne({token:String(token)})) { ... }

Потом понимаю, что внутри придется второй раз искать чтобы использовать результат.
Ввожу промежуточную переменную. Проверяю ее. Использую внутри.

И получаю

var user = await Users.findOne({token:String(token)}))
if (user) {
   doSmth(user)
}

Но мне прямо очень не нравится такой паттерн.

[Robur]

Под "прокидывать" я имею ввиду использовать результат выражения, прописанного в if (...) внутри его тела { }

результат выражения будет true, тогда ваш код выполняется, или false тогда он не выполняется. То что вы туда хотите запихать "compilcated expression" по какому-то своему капризу, не меняет сути.

Но мне прямо очень не нравится такой паттерн.

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

Есть "хороший" код, а есть "мне нравится"

Для серьезных проектов нужно выбирать первое, для своих пет-проектов, можете выбирать второе, там уже насколько фантазии хватит, варианты разные, в своем проекте можете писать любую дичь, кто же вам запретит.

[Stalker_RED]

var user = await Users.findOne({token:String(token)}))
if (user) {
   doSmth(user)
}

Но мне прямо очень не нравится такой паттерн.

Чисто технически можно сделать вот так:

if (var user = await Users.findOne({token:String(token)}))) {
   doSmth(user)
}

Но вас обязательно кто-то проклянет, потому что легко можно спутать = и == Да и читается ваш вариант получше.

Выберите лучше какой-нибудь из популярных стайл-гайдов, и следуйте ему.

[Robur]

Stalker_RED, зачем вы множите зло.

[nickerlan]

Stalker_RED, нашел красивую сейчас штуку

const ifVal = (val, fn) => val == null ? null : fn(val)

[Robur]

тут кстати в соседнем вопросе упомянули https://github.com/tc39/proposal-optional-chaining
это то что позволит заменить "a && a.b && a.b.c" на "a?.b?.c"
возможно уже есть трансформ в бабеле, оно в stage 2 уже