Предупреждение для тех, кто хочет перейти с Webpack на Vite

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

Если совсем коротко, не делайте этого!

Если чуть подробнее, то:

- Нормальных инструментов анализа бандла нет, Statoscope вы будете видеть только в своих влажных снах;
- Нормальной настройки, чтобы в лучшем случае обновлялся хеш одного (последнего) чанка, а не всей цепочки до него, нет (писал про это);
- Чтобы нормально настроить разделение чанков вам придётся пострадать, но скорее всего у вас вообще ничего не получится. Про вендор чанк авторы вообще написали: думайте сами, но так уж и быть вот вам deprecated плагин (который работает не так, как вы можете этого ожидать);
- Нормального (единого) кода ошибки загрузки css нет, только ошибка браузера (про это тоже писал);
- Плагинов всё же маловато, и их качество и работоспособность порой сильно хромает.

П.С. Если вы думаете что Webpack медленный, то скорее всего у вас что-то не правильно настроено.

П.П.С. Если вам всё равно на бандлы, чанки, анализ и прочие страшные вещи, а 10 мб вашего великолепного Javascript кода это нормально, пользователи потерпят, то можно и Vite 😅

#frontend #development #webpack #vite

[SolidJS] Suspense + createResource

Suspense в SolidJS реагирует не только на ленивую загрузку компонентов, но и на загрузку данных через встроенный createResource. На первый взгляд это может показаться очень удобно, но есть нюанс.

Возьмём для примера следующий код:

<Suspense fallback={<div>Loading app...</div>}>
  <List />
</Suspense>

const List: Component = () => {
  const [list] = createResource(fetchList);

  return (
    <section>
      <header>
        <h4>Title</h4>
      </header>
      <Suspense fallback={<div>Loading list...</div>}>
        <ul>
          <For each={list()}>
            {(item) => <li>Item #{item}</li>}
          </For>
        </ul>
      </Suspense>
    </section>
  );
};

Тут всё ожидаемо: пока приложение загружает список, пользователь видит заголовок и надпись “Loading list”.

Но давайте, например, добавим отображение количество элементов списка в заголовке:

const List: Component = () => {
  const [list] = createResource(fetchList);

  const count = createMemo(() => {
    return list()?.length;
  });

  return (
    <section>
      <header>
        <h4>Title <span>{count()}</span></h4>
      </header>
      <Suspense fallback={<div>Loading list...</div>}>
        <ul>
          <For each={list()}>
            {(item) => <li>Item #{item}</li>}
          </For>
        </ul>
      </Suspense>
    </section>
  );
};

И вот теперь, вместо казалось бы ожидаемого “Loading list”, пользователь увидит “Loading app”.

С одной стороны всё логично — мы добавили чтение из list за пределы внутреннего Suspense, поэтому отработал Suspense выше. Но как мне кажется, простое добавление createMemo (или чего-то подобного) не должно менять порядок отрисовки.

#frontend #development #solidjs

Что не так с React

Вот уже почти 10 лет я использую React, как для коммерческой разработки, так и для персональной. Из них 4 года, параллельно, использую и SolidJS. И как известно, именно в сравнении начинаешь лучше понимать плюсы и минусы обеих сторон.

Почему именно SolidJS, а не Angular, Vue или что-то другое? Всё просто — верхнеуровнево они очень похожи. Я бы даже сказал что SolidJS умышленно скопировал JSX компоненты и “хуки”, но это лишь на уровне идеи, работает же всё иначе.

Что же не так с React?

Количество выполнений тела функции-компонента (и всего содержимого по цепочке вниз). Бороться с лишними выполнениями несложно, но мало кто хочет тратить на это время. В реальности почти ни кто не хочет думать нужно ли в текущем компоненте применять memo, useMemo, useCallback, как часто будут заново создаваться массивы и объекты, как правильно инициализировать какой-нибудь класс и т.п. Зачастую это приводит к проблемам производительности в больших приложениях, и порой достаточно серьёзным. А на решение этих проблем приходится тратить дополнительное время.

Необходимость (правильно) указывать зависимости хуков. Даже правило для линтера придумали специальное… которое иногда больше мешает, чем помогает. А реализацию сложного эффекта (или вычисления), который должен зависеть от одной переменной, но при этом не должен зависеть от пары других, всегда имея их актуальные значения, кроме как через костыль в виде useRef, кажется, и не решить. В общем, опять требуется дополнительные временные затраты. Ах да, ещё вы точно не обойдёте срача на ревью по поводу нужен в каком-то конкретном месте useMemo или нет.

Виртуальный DOM. Да да, то что когда-то было преимуществом, теперь становится недостатком (в контексте веб-разработки). SolidJS прекрасно обходится без него, при этом меняя в реальном DOM-е только то, что нужно, благодаря системе сигналов. Нет VDOM-а — нет дополнительных вычислений и потребления памяти.

Большой вес и отсутствие tree shaking. За столько лет в библиотеку много чего было написано, и хотите вы того или нет, всё это попадёт в вашу сборку.

Тем не менее это не делает React плохим, а Solid хорошим, у всего есть свои плюсы и минусы. Но всё же, если есть такая возможность, я выберу именно SolidJS.

#frontend #development #react #solidjs

Архитектура: размазывание ответственности

Рассмотрим одну из основных проблем при разработке (архитектуре) веб-приложений, которую я называю “размазывание ответственности”. В данном случае, речь пойдёт только про один аспект — прямая связь UI компонентов со слоем данных (через импорты) и, как организовать эту связь так, что бы и сам код и работа с ним была чуть более предсказуема и понятна.

Пример №1

[См. первое изображение]

Есть некоторое приложение (Router), на котором есть страница (Screen) и хук с классом, и всё это завязано на работу с одним значением в локальном хранилище (Storage). Обратите внимание на жёлтые стрелки — это то, как именно компоненты связаны с хранилищем:

- Router содержит действие, которое удаляет значение;
- Router выполняет hook, который создаёт Class (читает и меняет значение);
- ScreenHeader читает значение.

В этих связях и заключается проблема, их много и они разбросаны по разным частям приложения как придётся. Всё это усугубляется ещё и тем, что кто-то обращается к хранилищу напрямую (через API браузера), а кто-то через специальный хук (его нет на схеме). В подобном коде вообще не очевидно что и где происходит, как говорится “без поллитра не разберёшься”.

А вот, как это должно быть:

[См. второе изображение]

Во-первых, все действия с ячейкой хранилища должны быть собраны в ОДНОМ единственном месте. В нашем случае это Class. Это кстати не означает что, например, ScreenHeader теперь должен быть (напрямую) связан с Class, что и отображено на схеме но может быть не очевидно.

Во-вторых, точка связи между UI и Storage должна быть также ОДНА (“где вошли, там и вышли”), через hook и Class. А до ScreenHeader значение можно пробросить, например, через параметры компонентов.

#frontend #development

...продолжение:

Пример №2

[См. первое изображение]

⁃ Widget — независимый блок (на большой странице) с ограниченным списком;
- Full List — всплывающая страница с полным списком;
- Add/Edit — всплывающая страница добавления или редактирования элемента списка.

Обратите внимание, что Widget и Full List используют одинаковую цепочку компонентов для отображения списка. При этом, каждый элемент можно удалить или отредактировать, а также добавить новый.

Набросим схему работы с данными:

[См. второе изображение]

Схема уже не кажется такой простой. 😅 А всё потому что мы имеем туже проблему, что и в первом примере — слишком много точек связи с данными (Data Layer). Widget и страницы — “управляющие компоненты”, им положено быть связанными со слоем данных. А вот компоненты Remove и Select — нарушители (поэтому и выделены цветом).

Решается также просто как и в первом примере, правильной настройкой связей:

[См. последнее изображение]

Обратите внимание, что сама схема стала приятнее на вид, и наш слоёный “пирог” приобрёл логический вид — сверху данные, потом управляющие компоненты, а в самом низу “глупые” компоненты. Из чего кстати, легко выводится правило — “умные” компоненты, напрямую связанные с данными, не могут находиться в конце цепочки из “глупых”, т.е. внизу.

П.С. Всегда бывают исключения, но они должны быть сильно оправданы.

#frontend #development

https://kettanaito.com/blog/dont-sleep-on-abort-controller

Хорошая обзорная статья про AbortController. Обычно его используют только для отмены запросов fetch, но на самом деле, при желании, отменять можно всё что угодно.

Самым вкусным, на мой взгляд, является отмена пачки подписок на события одной командой:

useEffect(() => {
  const controller = new AbortController();
  const options = { signal: controller.signal };
  
  el.addEventListener('pointerdown', handler, options);
  el.addEventListener('pointerup', handler, options);
  el.addEventListener('pointercancel', handler, options);
  el.addEventListener('pointerleave', handler, options);
  el.addEventListener('click', handler, options);

  return () => {
    controller.abort();
  };
}, []);

#frontend #development #javascript #react

Рендер массивов в SolidJS

Рендер массива в SolidJS можно выполнить тремя способами:

Первый (как в React)

{items().map((item) => (
  <Item item={item} />
))}

Это самый “тупой” вариант и лучше его не использовать, т.к. при любом изменении массива весь список будет создан заново. Другими словами, если в компоненте Item используются onMount и onCleanup, то для каждого элемента списка сначала будет вызван onCleanup а затем onMount.

Через компонент For

<For each={items()}>
  {(item) => <Item item={item} />}
</For>

По сути, это тот же .map() но имеющий очень важное отличие: если элемент списка не изменился, то и перерендера этого элемента не будет, как собственно и вызовов onMount и onCleanup. В общем, если массив состоит из объектов, важно следить чтобы они не менялись без необходимости.

Через компонент Index

<Index each={items()}>
  {(item) => <Item item={item()} />}
</Index>

Этот вариант подходит для статических массивов. При этом, значения в элементах могут меняться, главное чтобы не менялась длинна самого массива и расположение элементов в нём. В противном случае вы можете столкнуться с ситуацией когда, например в onCleanup, будет значение не того элемента которого вы ожидаете.

Это я всё к тому, что если вдруг у вас появится желание использовать Index для динамического массива, лучше подумайте как избавиться от лишних изменений в самом массиве.

П.С. Ни в одном случае не нужно указывать параметр key, как например того требует React.

#development #frontend #solidjs

Про SOLID

Сколько всего уже про этот несчастный SOLID написано, сколько попыток объяснить простыми словами, что это и зачем, а воз и ныне там. Особенно иронично получается, когда статья называется “Понятно про SOLID” или что-то в этом духе, а содержимое наоборот больше запутывает. А что если в погоне за объяснением значения каждой буквы мы теряем что-то важное?

“…использование SOLID способствует созданию такой системы, которую будет легко поддерживать и расширять в течение долгого времени.”

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

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

П.С. Кстати, SOLID это не только (и не столько) про классы, хотя на них обычно все примеры и строятся.

#frontend #development

Освобождение памяти в React

Представим, что у нас есть некоторый провайдер, в котором:

⁃ open создаёт инстанс класса SomeClass и помещает его в useState;
⁃ close затирает это инстанс с помощью null;
⁃ instance передаётся через контекст ниже и где-то там используется

function SomeProvider() {
  const [instance, setInstance] = useState(null);

  const open = useCallback(() => {
    setInstance(new SomeClass());
  }, []);

  const close = useCallback(() => {
    setInstance(null);
  }, []);

  return <>...</>;
}

На первый взгляд кажется, что после выполнения метода close и присвоения состоянию instance значения null, ранее созданные инстанс класс SomeClass более недостижим и может быть удалён из памяти сборщиком мусора, но это не так. Ссылка на инстанс всё ещё будет храниться в React Fiber.

Исправить это можно. Например, хранить инстанс в useRef. Однако, в этом случае useState вам всё равно потребуется для хранения состояния наличия этого инстанса. Ну или повторно затереть (с помощью undefined) состояние в метод close, что, к сожалению, вызовет лишнюю отрисовку:

// Костыль через setTimeout
setInstance(null);
setTimeout(() => setInstance(void 0));

// Или через api react
flushSync(() => {
  setInstance(null);
});
flushSync(() => {
  setInstance(void 0);
});

#development #frontend #react

Batching обновлений в React и SolidJS

Batching — группировка нескольких обновлений состояния в одно, для оптимизации количества "отрисовок" компонента. Если коротко, в React он автоматический, а вот в SolidJS ручной. Но в случае React есть нюансы, куда же без них. 😅

React

function Comp() {
  const [first, setFirst] = useState();
  const [second, setSecond] = useState();

  function handleClick() {
    setFirst(...);
    setSecond(...);
  }

  return <>...</>;
}

Автоматическую группировку в React вы получите в следующих случаях:

⁃ В синхронном обработчике события;
⁃ В асинхронном обработчике (только для v18+ с createRoot).

Во всех остальных случаях группировки не будет. Обратите внимание, что при переходе на 18 версию (и createRoot), в большом приложении реально словить баги в самых неожиданных местах, т.к. изменения состояний в асинхронных блоках теперь будут группироваться, чего не было в 17 версии и ниже.

Если вам нужно вынести какое-то обновление из автоматической группировки, лучше использовать специальный метод flushSync из пакета react-dom, вместо нулевого setTimeout.

Если совсем подробно, то вот тут всё описано https://github.com/reactwg/react-18/discussions/21

SolidJS

function Comp() {
  const [first, setFirst] = createSignal();
  const [second, setSecond] = createSignal();

  function handleClick() {
    batch(() => {
      setFirst(...);
      setSecond(...);
    });
  }

  return <>...</>;
}

В SolidJS вы сами решаете когда нужна группировка обновлений, через специальную утилиту batch. Использовать её, наверное, имеет смысл только в случае если от обновляемых сигналов (состояния) зависит какое-то дорогое вычисление. В противном случае можно обходится без неё.

#frontend #development #react #solidjs

Пятничный наброс... 🙃

Пара слов о Feature-Sliced Design (FSD)

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

Читаешь документацию, туториал, статьи… в целом, вроде всё понятно, садишься делать реальный проект — начинаются вопросы. Смотришь примеры собранные на официальном сайте, а там везде по разному (я про детали, само собой). И тут понимаешь, что не понятно не только тебе.

И вот вопрос (риторический): а как тогда эта методология поможет сделать проект понятным, если сама методология не так уж и понятна и каждый разработчик трактует её по своему?

Стоит отметить, что в версии 2.1 FSD сделал шаг в сторону более логичного подхода, когда всё нужное для страницы не размазано по разным корневым папкам, а находится рядом (если не нужно шарить с другими страницами). Но как-то это уж больно похоже на изобретение колеса.

Как нибудь ещё вернусь к вопросу “как раскладывать файлы по папочкам” и покажу “свою” схему которую я использую уже более 5 лет.

П.С. FSD в шутку расшифровывают как Freaky-Sliced Design 😅

Интересное ограничение Typescript

При написании хука для более удобной работы со списками данных (объектов), столкнулся с интересной особенностью Typescript.

Для начала приведу пример (предполагаемого) использования:

// Если в качестве ключа используется параметр с именем id
const [list, handlers] = useListState<ItemType>();

// Если в качестве ключа необходимо указать конкретное имя поля
const [list, handlers] = useListState<ItemType>('someId');

Ключ необходим для таких методов как has, remove и т.п., благодаря чему в качестве аргумента достаточно будет передать значение этого поля. Например, для удаления элемента из списка достаточно вызвать:

handlers.remove('some-id-value');

Теперь давайте про Typescript. Если в качестве ключа я указал название поля с типом string, то и в методах типа remove, в качестве аргумента должна приниматься именно строка. В чём же проблема? А в том, что при указании типа до аргументов, а название ключа в аргументах, Typescript не поймёт вас и не сможет вывести необходимо значение в возвращаемом типе. Другими словами, и тип и ключ должны оба быть в одном месте:

// или до аргументов:
useListState<ItemType, 'someId'>('someId');

// или в аргументах:
useListState([] as ItemType[], 'someId');

В обоих случаях получается не так красиво как хотелось бы: в первом приходится дублировать имя ключа, а во втором вообще добавлять ещё один аргумент.

Есть и третий вариант решения (который тоже не очень):

// сначала необходимо создать хук с нужным типом
const useListState = createListState<ItemType>();

// а затем, при использовании, указывать ключ
useListState('someId');

Если что, вот ссылка на сам хук:
https://gist.github.com/SanichKotikov/510004365de8cafbd51623b581b5733c

Хотя кто знает, может решение всё же есть. Если найдёте, напишите.

Архитектура: функциональное проектирование

Я недавно писал про архитектуру на примере React компонентов, где в конце приводится схема слоёного “пирога”, на которой сверху данные, посередине управляющие компоненты, а снизу “глупые” компоненты. А теперь давайте попробуем взглянуть на код чуть глобальнее.

Итак, в целом весь наш код можно разделить на три условные категории:

Данные

Тут всё просто, данные есть данные, например пользователь в системе или транзакция в банковской системе. Их преимущество в том, что они прозрачны и могут быть интерпретированы по-разному.

Вычисления

Это преобразование данных без побочных эффектов. Они не зависят от места и времени выполнения, и всегда возвращают одинаковый результат при одинаковых входных данных. Другими словами, это чистые функции.

Действия

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

Обратите внимание на порядок, в котором описаны эти категории, он не случаен. Данные — фундамент любого продукта, и как уже было сказано, они прозрачны и интерпретировать их можно как угодно. Далее идут вычисления (чистые функции), их проще писать и тестировать. Это довольно обширный пласт и может включать в себя много уровней, от работы с типами и структурами языка программирования до всевозможной бизнес-логики разных уровней. А замыкают всё действия, оперируя данными и вычислениями. Этот уровень больше подвержен ошибкам и в него чаще всего вносятся изменения, и при этом его может быть не так просто протестировать. Именно при работе с последним уровнем нужно быть максимально внимательным.

А теперь давайте вернёмся к примеру React компонентов, и возможно вы уже понимаете почему так важно стремиться к тому, что бы у вас было как можно больше “глупых” компонентов и как можно меньше “умных”. Да, всё просто, глупые компоненты являются вычислениями, а умные (управляющие) — действиями. Глупые компоненты реже меняются, их легко переиспользовать и они меньше подвержены ошибкам. Управляющие компоненты напротив, меняются чаще, их практически невозможно использовать повторно, и шанс допустить в них ошибку гораздо выше.

Есть ещё один важный момент — если вычисление использует действие, то оно автоматически становится действием, со всеми вытекающими!

#development #frontend #architecture

Архитектура: раскладываем код по папкам

Примечание №1: под словом “компонент”, без приставки UI, будет подразумеваться именно компонент системы, а не интерфейса.

Примечание №2: какой бы вы подход не выбрали, этот, FSD, классический или ещё какой-то, это никак не скажется на качестве вашего кода и системы в целом. Правила это не главное, главное то как ими распорядиться.

Пришло время описать схему, по которой я “раскладываю код по папкам”, года так с 2019. Всё это время я пробовал менять в ней разные нюансы, сравнивал, делал выводы, но база оставалась всегда одна — фокус на предметной области. Максимально простое объяснение этой схемы можно выразить следующей строкой:

Feature/Segment/Component

Предположим, вы пишите приложение для сети общепита. В данном случае предметная область будет включать сотрудников, филиалы, меню и заказы. Добавим ко всему этому “базовую” функциональность и компоненты касающиеся самого приложения и получим верхний уровень структуры:

📁 _core
📁 _ui-kit*
📂 branch
📂 employee
📂 menu
📂 order
📁 app

Папку _core, в теории, можно переносить из проекта в проект, т.к. она не должна содержать ничего что относится к нашей предметной области. А вот что она должна содержать, так это всевозможные утилиты для работы с примитивами языка, api платформы (fetch, storages), какие-то базовые хуки (если мы используем React или SolidJS), типы и т.п. Компоненты из папки _core можно использовать в любой части системы, при этом сама папка не может импортировать что-либо из соседних папок.

В папке _ui-kit лежат все базовые UI компоненты: кнопки, поля ввода, выпадающие списки и т.п. Компоненты этой папки можно использовать в любой части системы, кроме папки _core. В случае если вы используете сторонний ui-kit, то возможно, разумнее будет положить свои дополнительные UI компоненты в _core/ui.

В папке app хранится всё, что относится к специфике текущего приложения, но при этом не относится ни к _core, ни к предметной области. Это может быть общая разметка, интеграции со сторонними сервисами, логирование ошибок и т.п. Эта папка может использовать любые другие, но её использовать ни кто не может.

Все остальные папки верхнего уровня — “фичи” предметной области. Эти папки могут использовать компоненты из любой другой, кроме app. Кстати, в использовании компонентов из одной фичи в другой нет ни чего плохого, главное чтобы не было циклических зависимостей.

Второй уровень — Segment

Этот уровень описывает сегменты из которых может состоять любая папка первого уровня. Перечислю основные:

📁 type — typescript типы;
📁 lib — утилиты и хуки;
📁 context — контексты и их типы;
📁 ui — “глупые” UI компоненты;
📂 api — общение с сервером;
📂 control — “умные” UI компоненты и провайдеры;
📂 page — страницы;

Сразу отмечу что порядок, в котором выстроен этот список, имеет важное значение — сегмент может использовать всё что расположено выше него, и не может использовать всё что ниже. Например, page может импортировать модули из api, а вот ui не может.

Второй момент, на который стоит обратить внимание — api, control и page являются “умными” сегментами, т.к именно тут сосредоточены “действия”. Всё остальное должно относится к “вычислениям” или “данным”.

Иногда я думаю над тем, что бы добавить этим трём папкам какой-то префикс, например !, который бы отличал их от остальных. Но пока это открытый вопрос.

[продолжение ниже]

#development #frontend #architecture

[продолжение]

Третий уровень — Component

Тут только одно, но очень важное, правило: компонент может быть как единственным файлом, так и папкой с экспортом через index-файл внутри. Другими словами, импорт любого компонента вашей системы должен быть из трёх составляющих:

import { component } from 'feature/segment/component';

Ещё один важный момент: в папках первого и второго уровней не должно быть ни одного index-файла. Кого-то это может возмутить, мол как же так, но стоит вам попробовать и вы поймёте всю прелесть этого решения. 😎 По сути, в этой системе “публичным” интерфейсом обладают только её компоненты.

Также допустимые импорты:

// Соседний компонент
import { component } from '../component';

// Соседний файл
import { component } from './component';

Примеры не допустимых импортов:

../../something, ../../../something и т.п.
../component/file-inside
domain/segment/component/file-inside

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

Думается мне, этим постом можно закрыть серию про архитектуру, по крайней мере на какое-то время.

П.С. Пишите хорошие (маленькие) функции, и хорошая архитектура сама подтянется.

#frontend #development #architecture

Интересное мнение про найм в современных реалиях:
https://habr.com/p/882392/