Пример, хочу читать на двух языках: Ru и En. Есть статья А, есть ее перевод B. В итоге, мне в ленту прилетят они обе. Было бы очень здорово иметь статью, как одну сущность с возможностью переключения языков.
Зачем при рефакторинге этот вызов делать асинхронной функцией? (async () => {
Promise.all([selectPizza(), selectDrink()]).then(orderItems) // асинхронный вызов
})()
Если уж сделали асинхронной, то почему бы тогда не дождаться резолва Promise.all с помощью await? Promise.all внезано тоже возвращает промис.
Сами себе каких-то проблем выдумали, сами их себе порешали.
Это будет работать нормально ровно до тех ор, пока вы контролируете все эти редьюсеры и их логику. А когда используется сторонняя библиотека, то могу быть болшие проблемы. Развязывание экшн типов и констант им соотвествующих — это благо.
// your reducer
const initialState = { num: 1 }
TYPE1: ( { num } ) => ({ num: num + 1 })
// third-party reducer which source code you can not affect
TYPE1: (state) => throw new Error('Blow up the world')
Еще веселее станет дебажить, если над проектом работает несколько человек, и вы назвали свои экшн типы одниаково
По-большому счету вы изобрели заново redux-actions, с той лишь разницей, то намертво связали имена констант с их значениями. Это плохо потому, что для констант обычно используются довольно короткие имена. Есть очень не маленькая вероятность, то при таком походе при подклюении очередной библиотеки ваши типы экшнов совпадут, и приехали. Решение было предложено в весьма популярном пропосале ducks-modular-redux
Нет. Все именно так и обстоит. Возможно, разницу можно списать на параллельные случайные процессы в системе, и предположить, что время одинаково примерно. Другой вариант — для каждого отдельного элемента в DOM дереве браузер пытается вычислить окончательные стили в CSS дереве. В случае если стили могут быть найдены для конкретного элемента, то браузеру достаточно обойти только часть дерева, а если их нет, то он обходитвсе дерево, чтобы удостовериться, что подходящих стилей нет. Повторюсь, что это только предположение.
Я так понимаю, эта проблема была актуальна еще у дедушки IE. Когда писал статью, то всплывали смутные воспоминания о том, как я де-то когда-то мельком видел инфу, что в IE аттрибуты тормозят. Тем не менее отправить баг репорт стоит. Спаибо за мысль.
Не согласен. У нас в страшей школе вел информатику физик из универа. Писали на Си, ничего сложного, но освоил рекурсию, циклы, понял на самом простом уровне, что с памятью происходит и как. Я ему очень благодарен и по сей день.
Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к негативным результатам. Контакт должен происходить исключительно через менеджера проекта. И не стоит передавать специалистам негативные мысли заказчика, если таковые имеются. Возможно, утром он просто встал не с той ноги, простите ему это и продолжайте свою работу.
Еще предложения есть по ухудшению улучшнию испорченного телефончика?
Если речь про документацию REST API, то обычно Swagger'а достаточно. Для чего-то минимально сложного можно в PlantUML диаграмки нарисовать и в с проектом репу запушить
Рискну предположить, что потому что в Иркутске, а не в Москве
await Promise.all(items.map(sendRequest))
(async () => {
Promise.all([selectPizza(), selectDrink()]).then(orderItems) // асинхронный вызов
})()
Если уж сделали асинхронной, то почему бы тогда не дождаться резолва Promise.all с помощью await? Promise.all внезано тоже возвращает промис.
Сами себе каких-то проблем выдумали, сами их себе порешали.
Жаль, что тут нету Си. Нам в школе старшей все было рассказано на примере Си, за что и сейчас благодарен.
Еще веселее станет дебажить, если над проектом работает несколько человек, и вы назвали свои экшн типы одниаково
Еще предложения есть по
ухудшениюулучшнию испорченного телефончика?