Как обзорная статья неплохо. Однако полностью проигнорировано, что шаблоны вполне себе могут в динамику из начального примера:
<component :is="'h' + level">{{ text }}</component>
И все, никаких нагромождений из if не требуется. И это далеко не единственный способ реализации динамики в шаблонах и это точно не причина переходить на рендер функции.
Примера рекурсивной функции тоже не было, чтобы как-то сравнить запутанность и неудобность. Рекурсивные компоненты вполне работают нормально и без нее
Пример с прокидыванием attrs/slots тоже отсутсвует, но есть утверждение, что оно удобнее с рендер функцией, хотя весь этот функционал даже гораздо удобнее работает именно из шаблона.
В последнем пункте с гибкостью вновь не показано о какой же гибкости именно идет речь.
Хотя можно было попытаться найти какие-то реальные кейсы или когда JSX выигрывает, но этого сделано не было. И что крайне забавно, то начальный пример с h1-6 именно на JSX выглядит костыльнее чем реализация в шаблоне
Все равно статья ощущается словно цепляющейся за старое. Новые проекты запускать на Webpack - вредительство! Даже со сложными проектами лучше затачиваться под современный туллинг + сейчас Vite 8 в бете, где все почти сказанное о минусах Vite устаревает.
Для библиотек брать Rollup тоже нет причины: современый туллинг для такого tsdown который целенаправленно заточен на использовании библиотек и уже прошел проверку продом в опенсорс библиотеках.
Parcel тоже слишком специфичный проект, чтобы только вопросом конфига все ограничиваться
Оставьте вебпак только как легаси, сделайте мир чуточку лучше
На самом деле то что у меня получилось, вообще не что-то уникальное. Очень много с кем ее обсуждал в моменте проектирования и почти всегда звучало "о мы пришли к нечто похожему". Но это не имело задокументированности нигде, вот эту проблему мы и решали. И все еще решаю в более открытом варианте.
Насчет файлового уротинга: и да и нет, FEOD не призывает никак использовать утилиты или плагины для файлового роутинга, но и не против этого. Вместо этого используем мимикрию под него, чтобы решить часть проблем. А там где файловый роутинг показывает себя плохо, то можно его и проигнорировать.
Да, про микрофронтенды неплохо замечено, так как одна из целей такого подхода дать людям возможность делить зоны ответственности при этом минимально конфликтуя между собой. Те данный подход именно направлен на поптку отказаться от крайне дорогостоящего решения с микрофронтами, там где фичи именно технические микрофронтов не нужны (независимый деплой, внешний контроль за версиями и тп)
Полностью согласен на самом деле. Если бы мог придумать достаточную эвристику, чтобы удержать это от хаоса, с радостью бы ее использовал. Чисто в теории FEOD никак не запрещает модификацию, где использовался бы подход к shared аналогичный FSD, но опасность свалки высока, плюс клубки взаимосвязанных сущностей распутывать тоже приходилось (
Хотелось бы написать "старайтесь держать слабо связанными", скорее всего это более верное утверждение нежели чем полный запрет
Чтобы что? Зачем модулю uif8decoder ограничивать доступ к модулю buffer?
Отталкиваемся от самых слабых. Если не натыкать палок в колеса в common, то оно в короткие достаточно сроки превращается в свалку "не знал куда положить, кинул в туда" и в реальных проектах это наблюдалось далеко не 1 раз. При этом возникала достаточно большая запутанность между частями. Если нескольким частям нужно работать сообща и активно переиспользоваться, лучше рассмотреть вынос в модуль. Да, это несет определенное количество минусов, и действительно, есть случаи когда такое переиспользование уместно, но тут оно принесено в жертву.
То есть в Common должны находиться интерфейсы всех модулей из Modules? Чтобы что?
Там недостаточно подсвечен этот момент, но по своей сути, это опять же истекает из невозможности импортировать в common модули. Если возникает такая необходимость, то выворачиваем это наизнанку используя инверсию контроля. Поэтому не всего, а только самый необходимый минимум, также это долгая и неприятная процедура, опять же чтобы минимизировать возможность таких связей
У меня есть приложение, например, "электронная таблица". Я не могу вывести его в качестве одной из станиц? Почему?
На самом деле, это есть в проработке, что страницы могут формироваться внутри модулей и далее подключаться в App. В данной статье на это выделено только 1 приложение. Полноценная документация покрывает этот момент. (Разработка публичной версии документации в процессе)
Никто не может импортировать из App ... страница может тянуть зависимости только из App и модулей, но не наоборот
Тут оговорка или очепятка, вместо App явно подразумевался Common
Кажется в модулях эта проблема будет куда серьёзней.
И да и нет. Без особых плагинов сделать это лучше и явно не выходит. Я бы с удвольствием оперировал более крупными сегментами для описания ES-модуля нежели чем файл с импортами и экспортами, но все решения несут излишне большие издержки (абьюз неймспейсов, плагины с генерацией импортов и тд). Возможно в будущем удастся решить эту проблему более элегантно. Однако, модули часто более тесно связаны между собой, тогда как в Common связи ограничены, поэтому модули часто все равно бы тянули себя почти полностью, тогда как в Common сущности изолированы и нет причин для того, чтобы тянуть их все всегда
Планируется объемная документация с примерами. К сожалению, пока документация к FEOD только в локальной базе знаний компании (поэтому же на докладе некоторым моментам меньше времени было посвящено), но сейчас идет работа по формированию версии не привязанной к специфике компании, планировалось успеть сделать ее к выходу статьи, но придется подождать. Также в проработке линтер, который будет следить за соблюдением стилей и автофиксом импортов (так как это наиболее назойливая проблема на практике)
Насчет модулей: я сторонник того, что каждый модуль может обладать своей спецификой, он может быть типовым с плоской структуру или более древовидным. Тут надо смотреть на потребности и сложность логики модуля. Главная стандартизация касается только правил импортов и публичного апи. В примерах был плоская структура в модулях, так как она просто привычна тем, кто только и работал раньше с плоской, как таковых же ограничений на нейминг, четкую структуру тут нет. Я вообще сторонник того, что каждый модуль должен обладать минимальным README c пояснением (кратким!) по основной сути модуля
Серебряной пули нет) Особенно в вопросах кода: всегда чем-то жертвуешь или получаешь серые пятна.
Если конкретно по вопросу. Тут конфигурация сочетается с необходимостью переиспользования на различных уровнях проекта. Действительно не самый приятный случай.
На вскидку приходит идея с разделением: определяем интерфейс на доступном уровне, например common / module или даже global если какой-то интерфейс перегружаем. А далее имплементируем его на уровне pages / app. Как и писалось в статье пригодится DI, те условный объект который и будет заполнен из app, а использоваться везде так как определен он в common.
Минус подхода: 2е определение ресурса, больше возни с имплементацией (того же DI базового). В случае разнесения по модулям все чуть проще: экспортируете вы только ключи доступа к атомарным роутам и "плагин" который встроится в app для регистрации самих роутов, далее базовые правила работы.
Ну и стоит понимать, что жесткие ограничения не навязываются прям, если технологически что-то ну слишком больно уносить наверх и поддержка этого будет стоить слишком дорого, то лучше вынести на более базовый слой, просто это явно указать, это лучше чем костылить или 1 логический блок разваливать по отдельным слоям, этого как раз мы и хотели избежать с модулями
тот случай, когда у меня вновь слезы от статьи в целом на глазах. Чуть позже отпишу автору с пояснениями (с телефона затруднительно все расписывать)....
Те самые "большие" проекты на вебпаке, который уже де-факто не развивается. Отличный выбор и надежный. Законсервировать и забыть, если тяготеет душа к вебпаку, то лучше уж в сторону RSpack смотреть
DISCLAIMER: Я буду говорить относительно Vue и только в рамках Vue. Если вы собираетесь читать относительно концепции в других фреймворках и языках, то можете скипать, так как обсуждение каждого фреймворка или другого подхода требует другой аргументации и обсуждения в целом. Данный комментарий больше ориентирован на тех кто воодушивившись уже собрался тащить такой подход к себе в проект
А ради чего Vue который из коробки изначально был MVVM (в последствии реактивная модель по своей сути вышла за рамки классического MV*) пытаться превращать в MVC? Концепции заложенные во фреймворк уже прекрасно работают относительно разделения, а классические подходы в разработке фронтенда закрепляют это еще лучше.
Ну и перепишем предложенный код как он мог быть написанным в классическом Vue исполнении:
"Модель":
function useProgress() {
const isGoing = ref(false)
const percentages = ref(0)
function start() {
isGoing.value = false
percentages.value = 0
}
function finish() {
isGoing.value = false
percentages.value = 0
}
// сохраню изначальную задумку автора
function update(percentages: number) {
switch (true) {
case percentages <= 0:
percentages.value = 0;
break;
case percentages >= 100:
percentages.value = 100;
break;
default:
percentages.value = percentages;
}
}
return {
// для понятности использую самый наивный метод реализации readonly.
// однако так писать не рекомендую
isGoing: computed(() => isGoing.value),
percentages: computed(() => percentages.value),
start,
finish,
update
}
}
Да, это просто композабл. Композаблы это прекрасные кирпичики чтобы выносить бизнес логику или позволять различным компонентам использовать одну функциональность. Создавать классы нет никакой нужды и я надеюсь, что автор это сделал исключительно только ради того, чтобы быть не столь сильно привязанным ко Vue подходам
Представление:
Да не нужно никакую model создавать для передачи. Классические подходы работают прекрасно: пропсы+события это и есть МОДЕЛЬ с которой работает данный компонент (если уж мы начали так представлять). Соответственно
<ProgressBar :is-going :percentages />
Если вам так нравится концепция: передать "все", то есть уже для этого механизм
<ProgressBar v-data="progress" />
Контроллер:
Почему компонент-родитель является контроллером опустим за скобкой, но в классическом представлении для такого уже есть паттерн smart dumb components, когда простое представление контролирует умный компонент.
Итого: натянув MVC предложенный в статье на Vue приложение вы ломаете привычный флоу для Vue разработчиков, усложняете разработку пытаясь реализовать и поддерживать инородные сущности и увеличиваете количество необходимого кода для их поддержания. При этом классические паттерны для работы со Vue (да и в целом Frontend-ом) уже давно выведены и перед такими трюками лучше вначале изучить их и сравнить с тем что могут дать вам они.
Но топить за Vite, который взлетел исключительно из-за того, что его в скафолдинг тулзы стали пихать "чуть менее чем все" дждавскриптовые фреймворки - это наше все.
Звучит как какая-то обида. Нет, Vite стал популярен, так как он обходит webpack по всем характеристикам, кроме гранулярного контроля над чанками (с переездом на rolldown и это останется в прошлом). Иначе бы все "чуть менее чем все" на него не перешли.
Вспоминаю сколько сил забирал Webpack у меня в прошлом буквально 0 желания к нему вновь прикасаться.
PS. В последний раз трогал Webpack когда надо было проект с SSR+SSG Vue2 на Vue3 пернести, мата было много. В итоге переехали компанией на Vite и все остались супер счастливы
Компоненты как раз ничего не запрашивают, а в них проталкивают значение сверху вниз. В то время как у Solid пропсы это Pull-based так как они ленивы и значение пропса вычисляется только в момент попытки обращения значению пропса.
Нужно нехилую ментальнужю гимнастику применить, чтобы хоть как-то натянуть модель реактивности React на Pull-семантику. А если с точки зрения вычисления смотреть, то это прям совсем push push
Так как это изначально не было целенаправленным функционалом Vue. Скорее случайным образом обнаруженная возможность для реализации. Просто из Vue в целом выпилили идею топорных событий (теперь они заранее регистрируются). Если так подумать то действительно смешно было наблюдать по 5-6 инстансов Vue для того чтоб сообщениями обменивались компоненты, как-то логика нарушается
Лучше даже было не писать такую причину "почему не Vue". Ибо когда технический анализ анализ проводится только по популярности, хочется плакать. И нет от перехода меджу 2 и 3 компании не развалились, зато остальные бизнес-метрики отличные у vue: скорость вхождения в проект, скорость изучения, перфоманс, легкость и скорость написания проектов выше чем у React. Но это я так, на подумать, действительно ли "популярность" единственный фактор.
PS. Насчет 2 и 3: уроки учтены, огромная работа была проведена для того чтобы не допустить этого вновь. Так что... аргумент для новых проектов теперь этот на уровне "ну что-то там когда-то произошло"
Там уже почти официально свой язык программирования SvelteScript. И код всего проекта пишется только в файлах .svelte.js. Очень ванильно) По сути 5ка несет еще больше магии и подкапотной работы по итогу. В чем ванильность решения - не ясно
Как обзорная статья неплохо. Однако полностью проигнорировано, что шаблоны вполне себе могут в динамику из начального примера:
И все, никаких нагромождений из if не требуется. И это далеко не единственный способ реализации динамики в шаблонах и это точно не причина переходить на рендер функции.
Примера рекурсивной функции тоже не было, чтобы как-то сравнить запутанность и неудобность. Рекурсивные компоненты вполне работают нормально и без нее
Пример с прокидыванием attrs/slots тоже отсутсвует, но есть утверждение, что оно удобнее с рендер функцией, хотя весь этот функционал даже гораздо удобнее работает именно из шаблона.
В последнем пункте с гибкостью вновь не показано о какой же гибкости именно идет речь.
Хотя можно было попытаться найти какие-то реальные кейсы или когда JSX выигрывает, но этого сделано не было. И что крайне забавно, то начальный пример с h1-6 именно на JSX выглядит костыльнее чем реализация в шаблоне
В целом работа с вопросом "зачем?" в блоке с рендер функцией проделана на уровне ниже желаемого
Все равно статья ощущается словно цепляющейся за старое. Новые проекты запускать на Webpack - вредительство! Даже со сложными проектами лучше затачиваться под современный туллинг + сейчас Vite 8 в бете, где все почти сказанное о минусах Vite устаревает.
Для библиотек брать Rollup тоже нет причины: современый туллинг для такого tsdown который целенаправленно заточен на использовании библиотек и уже прошел проверку продом в опенсорс библиотеках.
Parcel тоже слишком специфичный проект, чтобы только вопросом конфига все ограничиваться
Оставьте вебпак только как легаси, сделайте мир чуточку лучше
намного ближе к чему?
На самом деле то что у меня получилось, вообще не что-то уникальное. Очень много с кем ее обсуждал в моменте проектирования и почти всегда звучало "о мы пришли к нечто похожему". Но это не имело задокументированности нигде, вот эту проблему мы и решали. И все еще решаю в более открытом варианте.
Насчет файлового уротинга: и да и нет, FEOD не призывает никак использовать утилиты или плагины для файлового роутинга, но и не против этого. Вместо этого используем мимикрию под него, чтобы решить часть проблем. А там где файловый роутинг показывает себя плохо, то можно его и проигнорировать.
Да, про микрофронтенды неплохо замечено, так как одна из целей такого подхода дать людям возможность делить зоны ответственности при этом минимально конфликтуя между собой. Те данный подход именно направлен на поптку отказаться от крайне дорогостоящего решения с микрофронтами, там где фичи именно технические микрофронтов не нужны (независимый деплой, внешний контроль за версиями и тп)
Полностью согласен на самом деле. Если бы мог придумать достаточную эвристику, чтобы удержать это от хаоса, с радостью бы ее использовал. Чисто в теории FEOD никак не запрещает модификацию, где использовался бы подход к shared аналогичный FSD, но опасность свалки высока, плюс клубки взаимосвязанных сущностей распутывать тоже приходилось (
Хотелось бы написать "старайтесь держать слабо связанными", скорее всего это более верное утверждение нежели чем полный запрет
Отталкиваемся от самых слабых. Если не натыкать палок в колеса в common, то оно в короткие достаточно сроки превращается в свалку "не знал куда положить, кинул в туда" и в реальных проектах это наблюдалось далеко не 1 раз. При этом возникала достаточно большая запутанность между частями. Если нескольким частям нужно работать сообща и активно переиспользоваться, лучше рассмотреть вынос в модуль. Да, это несет определенное количество минусов, и действительно, есть случаи когда такое переиспользование уместно, но тут оно принесено в жертву.
Там недостаточно подсвечен этот момент, но по своей сути, это опять же истекает из невозможности импортировать в common модули. Если возникает такая необходимость, то выворачиваем это наизнанку используя инверсию контроля. Поэтому не всего, а только самый необходимый минимум, также это долгая и неприятная процедура, опять же чтобы минимизировать возможность таких связей
На самом деле, это есть в проработке, что страницы могут формироваться внутри модулей и далее подключаться в App. В данной статье на это выделено только 1 приложение. Полноценная документация покрывает этот момент. (Разработка публичной версии документации в процессе)
Тут оговорка или очепятка, вместо App явно подразумевался Common
И да и нет. Без особых плагинов сделать это лучше и явно не выходит. Я бы с удвольствием оперировал более крупными сегментами для описания ES-модуля нежели чем файл с импортами и экспортами, но все решения несут излишне большие издержки (абьюз неймспейсов, плагины с генерацией импортов и тд). Возможно в будущем удастся решить эту проблему более элегантно. Однако, модули часто более тесно связаны между собой, тогда как в Common связи ограничены, поэтому модули часто все равно бы тянули себя почти полностью, тогда как в Common сущности изолированы и нет причин для того, чтобы тянуть их все всегда
Планируется объемная документация с примерами. К сожалению, пока документация к FEOD только в локальной базе знаний компании (поэтому же на докладе некоторым моментам меньше времени было посвящено), но сейчас идет работа по формированию версии не привязанной к специфике компании, планировалось успеть сделать ее к выходу статьи, но придется подождать. Также в проработке линтер, который будет следить за соблюдением стилей и автофиксом импортов (так как это наиболее назойливая проблема на практике)
Насчет модулей: я сторонник того, что каждый модуль может обладать своей спецификой, он может быть типовым с плоской структуру или более древовидным. Тут надо смотреть на потребности и сложность логики модуля. Главная стандартизация касается только правил импортов и публичного апи. В примерах был плоская структура в модулях, так как она просто привычна тем, кто только и работал раньше с плоской, как таковых же ограничений на нейминг, четкую структуру тут нет. Я вообще сторонник того, что каждый модуль должен обладать минимальным README c пояснением (кратким!) по основной сути модуля
Серебряной пули нет)
Особенно в вопросах кода: всегда чем-то жертвуешь или получаешь серые пятна.
Если конкретно по вопросу. Тут конфигурация сочетается с необходимостью переиспользования на различных уровнях проекта. Действительно не самый приятный случай.
На вскидку приходит идея с разделением: определяем интерфейс на доступном уровне, например common / module или даже global если какой-то интерфейс перегружаем. А далее имплементируем его на уровне pages / app. Как и писалось в статье пригодится DI, те условный объект который и будет заполнен из app, а использоваться везде так как определен он в common.
Минус подхода: 2е определение ресурса, больше возни с имплементацией (того же DI базового). В случае разнесения по модулям все чуть проще: экспортируете вы только ключи доступа к атомарным роутам и "плагин" который встроится в app для регистрации самих роутов, далее базовые правила работы.
Ну и стоит понимать, что жесткие ограничения не навязываются прям, если технологически что-то ну слишком больно уносить наверх и поддержка этого будет стоить слишком дорого, то лучше вынести на более базовый слой, просто это явно указать, это лучше чем костылить или 1 логический блок разваливать по отдельным слоям, этого как раз мы и хотели избежать с модулями
тот случай, когда у меня вновь слезы от статьи в целом на глазах. Чуть позже отпишу автору с пояснениями (с телефона затруднительно все расписывать)....
На самом деле нормально. Сейчас в 3ке даже удобно стало
Вот пример: https://codepen.io/vokgfqld-the-flexboxer/pen/ogNjXJK
Никаких сборщиков, зато крайне удобно работать с данными сохраняя всю мощь Vue при необходимости
Те самые "большие" проекты на вебпаке, который уже де-факто не развивается. Отличный выбор и надежный. Законсервировать и забыть, если тяготеет душа к вебпаку, то лучше уж в сторону RSpack смотреть
DISCLAIMER: Я буду говорить относительно Vue и только в рамках Vue. Если вы собираетесь читать относительно концепции в других фреймворках и языках, то можете скипать, так как обсуждение каждого фреймворка или другого подхода требует другой аргументации и обсуждения в целом. Данный комментарий больше ориентирован на тех кто воодушивившись уже собрался тащить такой подход к себе в проект
А ради чего Vue который из коробки изначально был MVVM (в последствии реактивная модель по своей сути вышла за рамки классического MV*) пытаться превращать в MVC? Концепции заложенные во фреймворк уже прекрасно работают относительно разделения, а классические подходы в разработке фронтенда закрепляют это еще лучше.
Ну и перепишем предложенный код как он мог быть написанным в классическом Vue исполнении:
"Модель":
Да, это просто композабл. Композаблы это прекрасные кирпичики чтобы выносить бизнес логику или позволять различным компонентам использовать одну функциональность. Создавать классы нет никакой нужды и я надеюсь, что автор это сделал исключительно только ради того, чтобы быть не столь сильно привязанным ко Vue подходам
Представление:
Да не нужно никакую model создавать для передачи. Классические подходы работают прекрасно: пропсы+события это и есть МОДЕЛЬ с которой работает данный компонент (если уж мы начали так представлять). Соответственно
Если вам так нравится концепция: передать "все", то есть уже для этого механизм
Контроллер:
Почему компонент-родитель является контроллером опустим за скобкой, но в классическом представлении для такого уже есть паттерн smart dumb components, когда простое представление контролирует умный компонент.
Итого: натянув MVC предложенный в статье на Vue приложение вы ломаете привычный флоу для Vue разработчиков, усложняете разработку пытаясь реализовать и поддерживать инородные сущности и увеличиваете количество необходимого кода для их поддержания. При этом классические паттерны для работы со Vue (да и в целом Frontend-ом) уже давно выведены и перед такими трюками лучше вначале изучить их и сравнить с тем что могут дать вам они.
ох не по тем стопам вы пошли, неужели чужие истории не научили ничему? (это я о методах продвижения вашего решения)
Звучит как какая-то обида. Нет, Vite стал популярен, так как он обходит webpack по всем характеристикам, кроме гранулярного контроля над чанками (с переездом на rolldown и это останется в прошлом). Иначе бы все "чуть менее чем все" на него не перешли.
Вспоминаю сколько сил забирал Webpack у меня в прошлом буквально 0 желания к нему вновь прикасаться.
PS. В последний раз трогал Webpack когда надо было проект с SSR+SSG Vue2 на Vue3 пернести, мата было много. В итоге переехали компанией на Vite и все остались супер счастливы
только зачем пример с Vue2?
Компоненты как раз ничего не запрашивают, а в них проталкивают значение сверху вниз. В то время как у Solid пропсы это Pull-based так как они ленивы и значение пропса вычисляется только в момент попытки обращения значению пропса.
Нужно нехилую ментальнужю гимнастику применить, чтобы хоть как-то натянуть модель реактивности React на Pull-семантику. А если с точки зрения вычисления смотреть, то это прям совсем push push
А зря, Vue с 3кой в итоге расцвел, библиотеки подтянулись и он вполне имеет право заменять React полноценно
Так как это изначально не было целенаправленным функционалом Vue. Скорее случайным образом обнаруженная возможность для реализации. Просто из Vue в целом выпилили идею топорных событий (теперь они заранее регистрируются). Если так подумать то действительно смешно было наблюдать по 5-6 инстансов Vue для того чтоб сообщениями обменивались компоненты, как-то логика нарушается
Лучше даже было не писать такую причину "почему не Vue". Ибо когда технический анализ анализ проводится только по популярности, хочется плакать. И нет от перехода меджу 2 и 3 компании не развалились, зато остальные бизнес-метрики отличные у vue: скорость вхождения в проект, скорость изучения, перфоманс, легкость и скорость написания проектов выше чем у React. Но это я так, на подумать, действительно ли "популярность" единственный фактор.
PS. Насчет 2 и 3: уроки учтены, огромная работа была проведена для того чтобы не допустить этого вновь. Так что... аргумент для новых проектов теперь этот на уровне "ну что-то там когда-то произошло"
Там уже почти официально свой язык программирования SvelteScript. И код всего проекта пишется только в файлах .svelte.js. Очень ванильно) По сути 5ка несет еще больше магии и подкапотной работы по итогу. В чем ванильность решения - не ясно