Size: a a a

Иван Акулов про разработку

2017 August 14
Иван Акулов про разработку
источник
Иван Акулов про разработку
и в тестах, которые я провёл, вычисление getBoundingClientRect() после инвалидации лэйаута занимает больше времени:
источник
Иван Акулов про разработку
источник
Иван Акулов про разработку
ТЕМ НЕ МЕНЕЕ вычисление getBoundingClientRect() всё равно, похоже, медленное ↓. Поэтому лучше его кешировать.
источник
Иван Акулов про разработку
источник
Иван Акулов про разработку
Спасибо, что уточняете :–)
источник
2017 August 16
Иван Акулов про разработку
Джеймс Аквух рассказывает про lodash-webpack-plugin

(Имейте только в виду, что этот плагин удаляет часть реальной функциональности Lodash-а, и просто так с дефолтными настройками включать его не стоит.)
источник
Иван Акулов про разработку
Daily tip #29: How to reduce lodash size by 3 times http://bit.ly/2vBCAIt
источник
Иван Акулов про разработку
А для уменьшения размера Lodash ещё полезно использовать babel-plugin-lodash. Он выбрасывает из Lodash те методы, которые вы не вызываете. Я писал про него раньше
источник
Иван Акулов про разработку
И вот ещё (огонь, я не знал):
источник
Иван Акулов про разработку
Переслано от Valentin Semirulnik
а ещё можно сделать алиас с lodash-es на lodash или наоборот. Это будет гарантировать тебе, что у тебя только один лоудэш в бандле
источник
Иван Акулов про разработку
Переслано от Ivan Akulov
Это если другие пакеты зависят?
источник
Иван Акулов про разработку
Переслано от Valentin Semirulnik
да, к примеру redux
источник
Иван Акулов про разработку
Ещё комментарии:
источник
Иван Акулов про разработку
Переслано от Олег Сергеев...
Привет, объясни мне, зеленому, если можно импортить только используемые методы из лодаша, зачем существует тот плагин, о котором ты только что написал?
источник
Иван Акулов про разработку
Переслано от Ivan Akulov
Не знаю :–) Для меня это вопрос удобства. Мне удобнее, когда у меня есть общий объект _ с кучей методов, чем когда я 1) импортирую каждый метод в отдельности и 2) при взгляде на метод не могу сразу понять, он мой или «лодэшевский»
источник
Иван Акулов про разработку
Переслано от Ivan Akulov
То есть _.forEach или _.flatten для меня считывается проще, чем просто forEach или flatten
источник
Иван Акулов про разработку
Переслано от Ivan Akulov
Потому что первое — очевидно методы из Лодэша, и я сразу вспоминаю, что они делают; а со вторым ещё подумать надо
источник
2017 August 17
Иван Акулов про разработку
#TodayILearned

В браузерах есть штука под названием IntersectionObserver — АПИ, которое помогает определять, когда элемент пересекает видимую область экрана или другой элемент. Обнаружил две вещи насчёт него:

В колбеке IntersectionObserver-а _можно_ узнать, находится ли элемент внутри экрана. (Или внутри другого элемента — зависит от того, как вы настроили observer.) Раньше я об этом не знал и пробовал определять пересечения, считая входы и выходы в экран вручную.

Эту информацию даёт свойство isIntersecting в колбеке observer-а:

const observer = new IntersectionObserver(myCallback);
observer.observe(document.querySelector('#target'));

function myCallback(entries) {
 // entries[0].isIntersecting → true or false
}


IntersectionObserver _не_ умеет ловить пересечения произвольных элементов. То есть если у вас в одном месте документа есть <div class="a">, а в другом — <div class="b">, и вы хотите определять, когда они пересекутся, то этого не получится. Пересечения двух элементов будут ловиться, только если один элемент — потомок другого:

const observer = new IntersectionObserver(
 myCallback,
 { root: document.querySelector('.a') }
);
observer.observe(document.querySelector('.b'));

function myCallback(entries) {
 // Если .b — не потомок .a, то колбек
 // вызовется только один раз
 // с entries[0].isIntersecting === false
}


Из-за этого определять, например, когда какой-то элемент заезжает под прилипшую шапку, не получится:
источник
Иван Акулов про разработку
источник