Solid.js - правильный React.js

#solid #react

Принцип инверсии зависимостей

Буква D в аббревиатуре принципов объектно-ориентированного программирования SOLID означает Dependency inversion principle - Принцип инверсии зависимостей, который очень хорошо применим и во фронтенд разработке.

Он гласит: "Завись от абстракций. Не завись от конкретной реализации".

Другими словами, если у вас есть некая сущность, которая что-то использует, то возможно она должна это делать через интерфейс.

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

Согласно Принципу инверсии зависимостей вам следует создать интерфейс для функций работы с датой - например, dates.ts, в котором прописать свои функции, которые являются обертками над date-fns функциями. В коде вы обращаетесь к этим своим функциям, а их реализация уже лежит в этом файле. Это даёт ту самую loose coupling - слабую связанность.

В ООП языках между конкретной реализацией dates.ts и кода, её использующего, нужно бы было создать промежуточный абстрактный класс DateUtilities - именно его называют в объяснении принципа "абстракцией". В JavaScript он не создается, dates.ts выполняет и его роль.

Таким образом вы можете спокойно работать над проектом с самого начала, не задумываясь, кто именно будет реализовывать логику работы с датами. Вполне возможно, к концу проекта вы увидите, что используете только 3 функции из date-fns, и они вполне могут быть реализованы самостоятельно. Вы избавляетесь от зависимости, делаете бандл легче, приложение - быстрее, и не надо ничего менять в коде, кроме самого dates.ts. Возможно будет иная причина поменять одну зависимость на другую - вы снова это делаете, не меняя основного кода.

То же самое относится к компонентам - обертки BaseButton, BaseIcon, BaseDropdown и т.п. служат этой же цели - значительно облегчить разработку, поддержку и дальнейшее развитие проекта путем снижения привязанности основного кода к конкретным зависимостям.

#architecture #solid

Кроме Rolldown-a команда Vue на прошлой неделе выставила в open source еще один свой грандиозный проект - Vue Vapor, который уже можно попробовать в его песочнице.

Грандиозный потому, что это по сути переписывание бОльшей части фреймворка. При этом Vue API (код для Vue 3, который пишет разработчик) должен остаться тем же самым.

Современные фронтенд фреймворки бывают двух типов - runtime и compile time. Первые работают с Virtual DOM - это такая абстракция на JavaScript, с которой взаимодействует пользовательская программа вместо реального DOM вебстраницы и, грубо говоря, являющаяся его зеркальным отображением. Делается это потому, что работа с браузерным DOM (рендеринг) - очень затратная операция, и фреймворк через Virtual DOM призван её оптимизировать - например, несколько изменений в DOM собрать вместе и зарендерить как одно. Так работают Vue.js и React, они предоставляют в runtime браузера прослойку для пользовательского кода (типа виртуальной машины), который работает только с объектами Virtual DOM.

Compile time фреймворки вроде Solid.js или Svelte не создают этой прослойки, и компилируют пользовательский код в код, который работает с браузерным DOM напрямую. В результате бандл получается меньше, а программа - быстрее. Сложность тут в оптимизации подобной компиляции. Для простых вещей она подходит, но что-то более сложное - и сompile time фреймворки уже могут проигрывать в скорости, и однозначно проигрывают Vue 3 в DX.

Команда Vue хочет хотя бы частично попробовать внедрить compile time реактивность - можно будет указывать, какие пользовательские компоненты компилировать в конечный код (Vapor mode), а для каких использовать обычный Virtual DOM.

#vapor #solid #svelte #vuejs #react