Разработка сложных компонентов: деливерим быстро, поддерживаем легко

[raamid]

Недавно тоже сталкивался с подобной проблемой при разработке библиотеки оконного интерфейса. Помучился с side-эффектами и пришел к следующему выводу: нужно сделать плоский слой событий для объекта window и блокировать события для дочерних элементов когда происходит перетаскивание/свайп или любая другая модификация элемента.

[romankipper]

Интересная задача) Ты разрабатывал что-то типа стека окон, как в винде или другой ОС?

[raamid]

Библиотека оконного интерфейса для браузера. Вот пример работы.

[romankipper]

Да, вижу. Я просто вспомнил, что мне советовали разбить модалку на базовые абстракции: стек окон, свайп и тд. Чтобы таким образом уменьшить сложность этого монстра :)

[raamid]

Вполне нормальное решение, однако, если каждый слой будет иметь свою систему обработки событий, это до добра не доведет. По крайней мере, из моего опыта.

[romankipper]

Возможно. На практике я это решение не пробовал, не могу сказать, как оно)

[pepelsbey]

А вот как это выглядит в коде

Это не код, это картинка. Она мелкая и нечитаемая на мобильных, её не скопировать в редактор, не прочитать в скринридере. Код — это текст.

Пожалуйста, уважайте читателей.

[romankipper]

Добро, исправим) Делали на базе доклада, не до конца адаптировали.

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

[romankipper]

Исправил.

[Ivan_Kotov]

Однако поддержка CSS решения (https://caniuse.com/css-snappoints) удручает, когда нужно, чтобы в каком-нибудь древнем WebView все работало.

[romankipper]

Ну здесь же можно использовать принцип graceful degradation. Просто выключаем свайп на таких девайсах.

[Spunreal]

… Паттерн Proxy выступает в роли прозрачного клея...

Всё-таки это не Proxy в классическом понимании. Это больше похоже на смесь стратегии и фасада — выбор стратегии скрыт внутри функционального компонента.

Но подход с функциональным компонентом интересный. Как-то от делать нечего портировал на vue БЭМовскую react-библиотеку (https://ru.bem.info/technologies/bem-react/) — https://github.com/sp1ker/bem-vue. Там такой же подход через функциональные компоненты, которые не видны в девтулзах, т.к. по сути являются обёрткой, только всё немного сложнее и позволяет на лету через изменение свойств извне изменять дерево компонентов Блока. Гибкости и декларативности добавило знатно, но только как эксперимент :)

[romankipper]

Всё-таки это не Proxy в классическом понимании. Это больше похоже на смесь стратегии и фасада — выбор стратегии скрыт внутри функционального компонента.

Дело было как: я сначала пришел к идее функционального компонента, а потом уже подвел это под некий паттерн, чтобы и коллеги, и аудитория меня лучше поняли. Технически это очень похоже на прокси, тк мы сохраняем API компонента. Но по существу никто не требует унифицировать API, поэтому это похоже на фасад. Ну а selectorFunction — стратегия в чистом виде. Так что кажется ты прав)

Но подход с функциональным компонентом интересный. Как-то от делать нечего портировал на vue БЭМовскую react-библиотеку

Хм, интересно. Из того что заметил — name лишний, в девтулзах ты его все равно не увидишь. По самому БЭМу ничего не могу сказать. Юзал его только как способ изолировать CSS, сама же методология гораздо глубже, не вникал.

В плане функциональных компонентов мне еще нравится, как реализован router-view из либы vue-router. Функциональный компонент, который лезет вверх (!) по дереву, чтобы понять уровень вложенности в другие router-view. И еще он использует $createElement не свой, а родительский, чтобы правильно резолвить слоты. Оттуда я эту технику и в мое решение с модалом перетащил)

[Spunreal]

Из того что заметил — name лишний, в девтулзах ты его все равно не увидишь

Всё не так однозначно :) Сейчас нет возможности точно воспроизвести, но год назад было что-то типа такого:

• Если мы в функциональном компоненте в createElement передаём HTML-элемент (а уже ниже по уровню без разницы что), то мы функциональный компонент увидим в девтулзах.
• Если мы в createElement передаём другой компонент, то там всё схлопывается и в девтулзах выводился 1 компонент, который передали.

[romankipper]

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

[Spunreal]

Это уже генерация верстки, полноценный компонент, которому и стейт не помешал бы

Зачем для вёрстки состояние? Для вёрстки часто и js не нужен то. Например, компонент иконки, который принимает на вход название иконки и генерирует div с классом.

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

[romankipper]

Да, я об этом как-то не задумывался) Для той же иконки мы всегда можем определить шаблон как template functional и не заморачиваться с render-функцией. В дев-тулзах как отдельную сущность мы ее получается увидим.

Видишь, во вью по сравнению с реактом сделан акцент на вот этой простоте, что все компоненты задаются как опции во vue-файле, а функциональные компоненты рассматриваются как advanced practice для HOC, оптимизаций и тп. Поэтому рядовой разработчик вряд ли догадается делать иконку как функциональный компонент.

[Spunreal]

del

[romankipper]

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