IT — Embedded webpack application
Возникла необходимость внедрять готовый SPA в другой проект на страницу. Проект сразу писался под это дело, но всё равно возник ряд проблем, которые нужно было решать. Напишу про 2 из них сюда как шпаргалку.
webpack & dynamic import
Что если ваш проект использует динамический импорт? Например System.import. В этом случае webpack сделает для подгружаемых файлов отдельный chunk. И грузить он его будет исходя из publicPath в настройках webpack. Но ведь embedded решения могут быть внедрены по любому пути. Как быть? Всё просто, пишем в точке входа что-нибудь типа: __webpack_public_path__ = window.myPredefinedPath и дело в шляпе. Магия. До загрузки приложения нужно определить этот window.myPredefinedPath, webpack его увидит и будет использовать. Сразу отмечу, что надо писать как есть, не window.__webpack...=, а как-будто эта переменная уже определена в коде. Если на неё ругается eslint не беда, пишем: // eslint-disable-line и он более не ругается.
webpack css & url
Возникла проблема с тем, что в стилях указаны пути к шрифтам так, что webpack их найти не может (отдельная тема почему так). Да и не должен, него его это забота. Однако он пытается от-revolve-ить все пути, что находит в css. Лечится установкой url: false в cssLoader-е. После этой настройки пути отдаются как есть без каких-либо проверок.
IT — React 16 & Context decorators
С обновлением React до 16 версии мы получили новый вид контекста, на замену старому. Теперь это не мутное API, как было раньше, а утверждённый вариант, с которым можно смело в бой. В чём же ключевые различия?
- Старый вариант был многословным. Новый вариант компактнее.
- Старый вариант не обновлял связанные с контекстом компоненты при изменении контекста. По сути контекст должен был быть имутабельным. Новый вариант обновляет связанные с ним компоненты.
- Старый вариант можно было использовать в любом методе компонента. Новый только в render-е.
- Старый вариант не имел пенальти по производительности и не требовал использования HOC-ов, не увеличивал иерархию древа. Новый вариант всё это делает. Скажем для connect-а из redux-а потребуется аж 2 дополнительных уровня иерархии.
- Старый вариант был оформлен в виде static полей класса, новый вариант в виде function as tag content. И то и другое слегка уродливо. Или не слегка. JSX в целом страшненький. А тут...
В итоге послевкусие специфическое. С одной стороны API хотя бы устаканили. С другой стороны сделали его каким-то очень неудобным и вообще кривоватым. Такое впечатление возникает в целом, глядя на новые возможности из 16+. Но тут я остановлюсь на работе с контекстом.
Писать вот так:
render()
{
return <Consumer>{arg1 =>
<Consumer2>{arg2 =>
<div>/* some code with them */</div>
}</Consumer2>
}</Consumer>
}
… невыносимо. Хочется удобства. В итоге это вылилось в такой вариант:
@renderContext('arg1', 'arg2')
render(arg1, arg2)
{
return <div>/* some code with them */</div>;
}
По сути я воспользовался декораторами из ES7, которые пока под некоторым вопросом. Но т.к. JSX в стандарте тоже нет, то плевать. Что делает данный декоратор? Он оборачивает метод render обёртками из кода выше. Но делает это автоматически. А в исходный render метод передаёт все контексты как аргументы функции в том же порядке.
Никакой магии в этом нет и все эти обёртки над обёртками никуда не испарились, но теперь хотя бы скрыты с глаз долой. Помимо прочего я написал ещё несколько декораторов. Один для <Provider/>-ов, один для HOC, один для удобтва i18n. Чувствую в декораторы затянет меня с головой. Ух злая эта штука. Это не к добру :)
Сам декоратор устроен вот так:
const renderContext = (...keys) =>
function(target, methodName, descriptor)
{
const render = descriptor.value;
descriptor.value = keys
.map(key => list[key].Consumer)
.reverse()
.reduce((inner, Consumer) =>
{
return function(...args)
{
return <Consumer>
{arg => inner.call(this, ...args, arg)}
</Consumer>;
};
}, render);
return descriptor;
};
Забирайте кому надо ;)
IT — Sequelize и тестирование
Добрался до тестирования серверной части (node). Встал вопрос: а как проще всего протестировать вещи, связанные с БД? Подумал о том, что должен быть для Sequelize какой-нибудь драйвер, который отрабатывает прямо в ОЗУ. Сразу не нашёл, но зато нашёл вариант с sqlite и storage=memory. Сработало. В купе с хаками для mocha в виде beforeEach и afterEach, получилось довольно удобно. Работает молниеносно, подключается тривиально. Единственное ― приходится тягать пакет с sqlite тоже. В моём случае это оказалось совершенно не критичным.
{ dialect: 'sqlite', storage: ':memory:', }
IT — onMouseMove & movementX & movementY
Ковыряясь с доступными в Event полями я наткнулся на два незнакомых, которые ныне есть во всех современных браузерах. А именно: movementX & movementY. Показывают сдвиг мыши относительно предыдущего вызова callback-а. Чертовски удобно, т.к. с ними можно не считать эти сдвиги вручную. Эх, ещё бы выдали штатную возможность узнать положение мыши относительно заданного DOMElement-а без груды кода с offsetTop-ми и прочими костылями.
IT — Размеры SVG-элементов в реальных пикселах
При использовании динамической SVG-графики, может возникнуть ситуация, когда удобно работать с каким-нибудь конкретным viewBox-ом, указав ту координатную сетку, с координатами и размерами которой будет удобно работать. Однако не все векторные примитивы вам может захотеться рисовать в масштабе этой сетки. Какие-то из них вы пожелаете сохранить в пикселном представлении. Что же делать?
- Можно поменять viewBox таким образом, что бы 1-ца сетки в нём соответсвовала 1px на канве. Что далеко не всегда бывает удобным вариантом.
- Можно подсчитать кол-во реальных px-й на 1 сетки viewBox-а и исходить из них.
В этом посту я остановлюсь на 2-ом варианте. Итак, с чего начнём? Начнём с того, что для границ-рамок-как-угодно-называйте, в общем для stroke, есть уже готовый механизм: vector-effect: non-scaling-stroke. Указав это свойство ваши stroke-width будут задаваться в реальных пикселах, а не в масштабе SVG.
А что делать, скажем, с радиусом для circle? Положим мы хотим нарисовать точку, но хотим чтобы её размер в px-ах не зависел от размеров канвы и масштаба на ней. Ну для начала посчитаем кол-во пикселей на 1-цу сетки:
const { width: wpx, height: hpx } = svg.getBoundingClientRect();
const kx = wpx / wi;
const ky = hpx / hi;
Где wi и hi это координатные width и height для viewBox. Если kx === 10, то на 1-цу сетки у вас 10 пикселей.
Ок, что дальше? Можно использовать эти коэффициенты на стороне JS, а можно отдать почти всё на откуп CSS, воспользовавшись CSS-variables. Например так:
<svg viewBox="" style={{ '--var-kx': kx }}/>
а в CSS используем calc:
circle { r: calc(5 / var(--var-kx)); }
UPD: Firefox не умеет r в css :(
Хотелось бы, конечно, чего-то вроде vector-effect: non-scaling и для других полей. Но меня устроил и этот вариант.