Code splitting. Code splitting is everywhere. However, why? Just because there is too much of javascript nowadays, and not all are in use at the same point in time.

JS is a very heavy thing. Not for your iPhone Xs or brand new i9 laptop, but for millions(probably billions) of slower devices owners. Or, at least, for your watches.

So — JS is bad, but what would happen if we just disable it — the problem would be gone… for some sites, and be gone "with sites" for the React-based ones. But anyway — there are sites, which could work without JS… and there is something we should learn from them...

Have you heard about memoization? It's a super simple thing, by the way,– just memoize which result you have got from a first function call, and use it instead of calling it the second time - don't call real stuff without reason, don't waste your time.

Skipping some intensive operations is a very common optimization technique. Every time you might not do something — don’t do it. Try to use cache — memcache, file cache, local cache — any cache! A must-have for backend systems and a crucial part of any backend system of past and present.

So, first of all — this is not a common battle. It's not about CSS versus CSS-in-JS, not atomic CSS versus BEM, not LESS vs SASS. This battle is about THE ORDER.

This battle is between ORDER and CHAOS. And between ORDER and,… another ORDER. In short — about a better way to sort CSS properties. No more, no less.

In short — there are 3 ways to do it:

• don't do it. Write any CSS as you can. This is the most popular way
• group properties by sense. Just put some stuff together. This is a quite popular way.
• order all the properties alphabetically. The easiest, but less popular way.

It's 2019! Everybody thinks they know code splitting. So - let's double check!

What does code splitting stand for?

In short – code splitting is just about not loading a whole thing. Then you are reading this page you don't have to load a whole site. When you are selecting a single row from a database – you don't have to take all.
Obvious? Code splitting is also quite obvious, just not about your data, but your code.

Этот code splitting, честное слово, уже немного надоел. Мы все ходим и ходим по кругу, и в этом и есть главная проблема.

Code splitting начинался как разделение на уровне Модулей, а закончился как разделение на уровне Компонент.

И проблема тут исключительно в голове — React.lazy это хорошо, но и import никуда не делся… Так почему же code splitting только про компоненты?

С code splitting я познакомился очень давно, в году так 2008, когда Яндекс немного подвис, и скрипты Яндекс.Директа, синхронно подключенные на сайте, просто этот сайт убили. Вообще в те времена было нормой, если ваши "скрипты" это 10 файлов которые вы подключаете в единственно правильном порядке, что и до сих пор (с defer) работает просто на ура.
Потом я начал активно работать с картами, а они до сих пор подключаются как внешние скрипты, конечно же lazy-load. Потом уже, как член команды Яндекс.Карт, я активно использовал ymodules возможность tree-shaking на клиенте, что обеспечивало просто идеальный code splitting.

А потом я переметнулся в webpack и React, в страну непуганных идиотов, которые смотрели на require.ensure как баран на новые ворота, да и до сих пор так делают.

Code splitting — это не "вау-фича", это "маст хэв". Еще бы SSR не мешался...

В последнее время на Хабре появилось пара интересных статей. Первая была посвещена проблеме минификации ES6, вторая про общие полезные советы оптимизации webpack.

Все бы хорошо, но они обе обошли стороной вопрос разделение бандлов на ES6 и ES5 для целей минификации и другой оптимизации. И вообще, в то время как одни все пишут и пишут статьи про это — другие (почти все) данную технику игнорируют.

Потому что Долго. Дорого. И не так чтобы очень очень.

А надо быстро, дешево, и потупее. Возможно следует просто обратить эволюцию вспять.

Have you ever thought — How to explain programming to the one never faced it before? It could be a problem, as long a new one will not understand you.

So, let's imagine — you have a friend, who is not soiled by computer science, never tried to automate something, never played factorio, never written a single line of code.

So, let's imagine a normal human being.

And let's call him Bill. He is not very good in Maths, just “not good”, but he loves candies!

Your task is to teach Bill some basic(or magic) IT things, you are doing every day. The simplest ones.
So what shall you do first? Basically — FEED HIM!

We have a problem. The problem with testing. The problem with testing React components, and it is quite fundamental. It’s about the difference between unit testing and integration testing. It’s about the difference between what we call unit testing and what we call integration testing, the size and the scope.

It's not about testing itself, but about Component Architecture. About the difference between testing components, standalone libraries, and final applications.

Everyone knows how to test simple components(they are simple), probably know how to test Applications(E2E). How to test Finite and Infinite things…

Чем мне нравится экосистема React, так это тем, что за многими решениями сидит ИДЕЯ. Различные авторы пишут различные статьи в поддержку существующего порядка и обьясняют почему все "правильно", так что всем понятно — партия держит правильный курс.

Через некоторые время ИДЕЯ немного меняется, и все начинается с начала.

А начало этой истории — разделение компонент на Контейнеры и неКонтейнеры (в народе — Тупые Компоненты, простите за мой франзуский).

Примерно месяц назад вышли React Hooks, и сразу же выяснилось что React-Hot-Loader портит все малину и не только сам с ними не очень совместим, так еще и весь остальной код ломает. В общем это был жаркий месяц...

Что внутри?

• Новый API для HMR
• Полная поддержка React 16.6 – React.lazy, React.memo и forwardRef
• Конечно же hooks
• React--dom (что бы это не значило)
• Webpack plugin
• Automagic ErrorBoundaries
• Pure Render
• “Principles”

Я люблю Реакт. Люблю за то, как он работает. За то, что он делает вещи «правильно». HOC, Composition, RenderProps, Stateless, Stateful – миллион патернов и антипатернов которые помогают меньше косячить.

И вот совсем недавно React принес нам очередной подарок. Очередную возможность косячить меньше — getDeviredStateFromProps.

Технически — имея статический мапинг из пропсов в стейт логика приложения должна стать более проста, более понятна, тестируема и так далее. По факту многие люди начали топать ногами, и требовать prevProps обратно, не в силах (или без особого желания) переделать логику своего приложения.

В общем разверлись пучины ада. Ранее простая задача стала сложней.

Давным давно я посмотрел Терминатор1. Немного подрос и посмотрел немного отрефакторенный Терминатор 2. Третьей интерации пришлось ждать немного дольше.

И каждый раз бедному СкайНету не везло, и каждый раз все наперекосяк, и секрет этого невезения очень прост — СкайНет не был Subject Under Test (SUT).

Другими словами SkyNet подзабила на тестирование, и производила разведку боем. И, как это обычно бывает, падала в корку(под пресс, в лаву, далее не помню) примерно сразу после выкладки в продакшен.

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

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

В балансе между тем насколько долго будет исполнятся мемоизируемая функция, сколько дополнительного времени потребует сахар мемоизации, и (про это все забывают) сколько програмистов потребуется, чтобы эту мемоизацию правильно прикрутить.



Но начнем с простого — что же это за слово такое странно — «мемоизация».

У меня есть два любимых запроса в гугле:

— Что будет, если в унитаз поезда на полном ходу бросить лом?
— Что будет, если в реакту по полном ходу заменить компонент?

И если с первым вопросом все более менее понятно, то со вторым вопросом все не так просто — тут же вылезает Webpack-dev-server, Hot Module Replacement, и React-Hot-Loader.

И все бы хорошо, но эта гремучая смесь просто не работает, спотыкаясь на первом же сложном коде, HOC, композиции, декораторе и нативных arrow функциях.

В общем третья версия Reac-hot-loader заводилась далеко не у всех.

История развития IT намного интереснее любой мыльной оперы, но пересказывать ее мы не будем. Скажем только, что были свидетили принципа «data-driven», адреналинщики с two-way-binding и беспредельщики без принципов и понятий.

Бог создал людей сильными и слабыми. Сэмюэл Кольт сделал их равными.
Примерно тоже самое сделали Flux и Redux.

Была только одна проблема — Redux по сути своей крайне примитивная хреновина, и чтобы с ним хоть как-то работать надо было добавить парочку middleware — thunk, saga, observable и так далее.

Но эта статья заходит с другой стороны, серьезно так спрашивая про композицию, и, в частности, про компонентную модель. Которой в редаксе — нет.

Уже больше 10 лет _большая_ часть моей работы — чистый JavaScript. Но иногда приходится заниматься и чуть более типизированными языками. И каждый раз после такого контакта остается странное чувство «непонятности», почему же в js вот так же сделать нельзя.

Особенно потому, что можно. И сегодня мы попробуем добавить немного типизации в самую хаотическую область javascript — mock-и в unit-тестах.

А то говорят тут всякие, что mocking is a coding smell.

В мире JavaScript существуют две фракции. Первая из них — технари, которые все проблемы стараются решать «технично». Вообще технари ребята суровые, я бы даже сказал строгие, и потому любят такую же суровую и строгую типизацию, и везде суют TypeScript, Dependency Injection и другой IoC.

Вторая же — маги. Кто-то, считает их шарлатанами, и уж никто точно не понимает как работает их код. Но он работает. На строгую типизацию у них табу, а про(от) DI у них есть простая отговорка:

«Зачем мне уродовать свой код, смешивая ужа с ежом, если это нужно исключительно для тестов?».

И ведь на самом деле — добавлять в проект DI исключительно чтобы мокать зависимости в тестах — идея не самая умная. Особенно если DI и на самом деле редкий зверь за пределами экосистемы Angular.

Есть только одно но — если технари от своей профдеформации не страдают, то маги… ну как сказать…

В общем пару месяцев назад один добрый человек создал мне в proxyquire-webpack-alias issue. Суть была проста — «не работает». Мне потребовался день чтобы изменить ЧТО не работает, на ГДЕ.

Люди которые пишут стандарты — очень хитро устроились. Им достаточно написать как должно все хорошо работать, а дальше уже не их проблемы.

Примерно так и получилось с тем «как должны работать диалоги», точнее «правильные» с точки зрения a11y модальные диалоги.

В описание к dialog role на MDN все написано очень просто:

• The dialog must be properly labeled
• Keyboard focus must be managed correctly

Проблема в том, что MDN забыла еще об одном важном пункте, а все остальные забыли про один из сказанных – про то, что модал не должен выпускать фокус из своих рук. Активный элемент надо посадить под замок. Не дать ему сбежать из нашей ловушки.

Mocks, fakes, and stubs — три столпа юнит тестирования. Конечно же все знают что это такое, как солить и когда есть. Я честно тоже так думал, пока не столкнулся с действительностью, под которую мне пришлось немного прогнуться.

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

Component = proxyquire.noCallThru().load(‘../Component’, {
 
     ‘../../core/selectors/common': { getData }

}).default;