Обновить
2
Роман Пятаков@romankipper

Фронтенд-разработчик

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

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

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

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

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

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

По моим сегодняшним ощущениям, я бы этот фрагмент кода урезал или вообще убрал. Здесь так называемый «смузи»-уровень, не предлагается готовых решений. Код как иллюстрация мысли, не больше.
Возможно. На практике я это решение не пробовал, не могу сказать, как оно)
Да, вижу. Я просто вспомнил, что мне советовали разбить модалку на базовые абстракции: стек окон, свайп и тд. Чтобы таким образом уменьшить сложность этого монстра :)
Интересная задача) Ты разрабатывал что-то типа стека окон, как в винде или другой ОС?

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность