Comments 22
Если вы используете vue-cli вам потребуется в vue.config.ts проставить флаг
runtimeCompiler: true
Не лучше было бы использовать расширение синтаксиса JSX/TSX и render-функции, чтобы они компилировались при сборке, а не в runtime браузера пользователя?
Эх, непросто всё в мире фронт-энда, кучи инструментов и технологий :)
Всегда была интересна эта область, но никогда не было достаточно свободных времени и ресурсов, чтобы нормально изучить её…
Мастера фронтов, а подскажите, есть что-то простое, без всяких нод и компиляций, чтобы в идеале подключил чистый js файл (вроде jquery) и можешь работать с беком по api (crud, json) и динамически обновлять таблички на фронте без тонн кода?
Мастера фронтов, а подскажите, есть что-то простое, без всяких нод и компиляций, чтобы в идеале подключил чистый js
Если хочется реактивности - тотже vue умеет в загружаемые компоненты (ничего собирать и компилировать не нужно), если нет - чем vanilla html/js/css не угодили?
Для модульности: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
Для общения с бекендом: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Для динамических табличек: https://developer.mozilla.org/en-US/docs/Web/Web_Components
Эх, непросто всё в мире фронт-энда, кучи инструментов и технологий :)
А на каком стеке их не кучи ?
alpinejs в помощь
Избавляемся от .vue, .ts и .html файлов и склеиваем их в один .ts файл. “Зачем это всё?” — спросите вы.
Действительно спрошу. SFC - это как раз про .vue файлы, в которых присутствуют и template и script и (опционально) style.
Зачем вместо этого держать разметку компонента в строке, как в доисторические времена без сборщиков? (К тому же, так ещё и тянутся в бандл лишние килобайты компилятор шаблонов)
И отдельный вопрос - зачем backend разработчиком руками настраивать Webpack, когда есть Vue CLI (а в 2022 году - Vite)?
Напоминаю, что безопаснее пользоваться дистрибутивами и пакетами, которые вышли раньше 24 февраля 22 года.
Безопаснее воспользоваться последними стабильными версиями, а не устаревшими из-за суеверий, примет, или какого-нибудь идиота одиночки. Или будем и дальше искать пасхалки в коде из-за того, что говорят по телевизору?
Пакеты vue-class-component и vue-property-decorator для того чтобы привести к классо-ориентированному виду, который все мы так любим;
Эти пакеты более не поддерживаются. Переходить с них на vue3 — это ужас. Надо уходить с них, а не использовать. И, следовательно, composables избавляют от дублирования, а не наследование классов
Vuex (позволяет общаться компонентам между собой.
Pinia. Типизировать Vuex грустно
Компонент на 2000 строк кода и 3000 строк шаблона это уже сигнал о том, что что-то не так
Это сигнал о том, что предыдущие сигналы были проигнорированы
Вы находитесь сейчас где-то в 2018-2020 годах
Отлично, давайте косплеить ромашку и представлять, что всего этого дерьма никогда не было.
А что, до 24 февраля вредоносного кода в пакетах не встречалось? Особенно, среди всякого мусора, который в проектах-то лучше и не использовать
Отлично, давайте косплеить акробатов и, переобувшись в полёте, делать вид, что людям, подверженным массовому психозу, можно продолжать и дальше доверять, как некогда разумным и ответственным.
Да причем тут доверие вообще? Мы же имеем дело с фактами, если пакет содержит вредоносный код, причем абсолютно неважно какого характера: политического, рекламного, волшебного — мы его не используем ни сейчас, ни в будущем, т.к. как минимум ревьюер это пропустил (опять же, нет никакой разницы почему — обиженный правый или невнимательность), а это означает, что даже если завтра настанет любовь и мир во всем мире, кто-нибудь захочет залезть к нам в карман, и к нашим клиентам, и потому мы вообще никак не защищены, гарантий нет.
Следовательно, Ваш совет тянуть старые версии пакетов, которые вполне могут содержать уже закрытые уязвимости, являющиеся приглашением для тех самых подверженных психозу — вреден.
А что будет, если недовольные останутся и через 10 лет? Будете тянуть фреймворки от 2022 года?
И так пишите на старом. Конечно, я понимаю, что Вам, как бэкендеру на php, с классами иметь дело приятнее, но вот просто ради интереса, взгляните на два шага вперед — как планируете мигрировать на vue3?
Отлично, давайте косплеить 5-летрих детей, и делать вид, что безопасность построена не на сети доверия.
Вы перепутали меня с автором статьи. Вы и код так же внимательно ревьите?
А теперь давайте представим, что вы решили ещё сильнее упростить себе жизнь и переписали всё на $mol...
Мы постарались написать приложение так, чтобы backend разработчикам было наиболее привычно и комфортно. Классы, интерфейсы, наследование, типизация..
.. шаблоны вперемешку с логикой и стилями. У вас тоже PHP на бэкенде?
Ладно, шутки в сторону. В $mol все компоненты являются обычными классами унаследованными от других компонент. При этом в полной мере поддерживается инверсия контроля (Пруф). У Vue же с нею всё плохо, как и со статической типизацией шаблонов и стилей. А вот в $mol с этим более чем хорошо (Пруф).
Нам понадобятся:
Да, это всё. В $mol есть все необходимые батарейки: богатая библиотека виджетов, запросы к серверу, роутинг, стейт-менеджмент и тд. И даже сам $mol нет необходимости устанавливать - он скачается автоматически, как только вы начнёт его использовать.
Перейдём к самой ужасной части: сборке проекта
Разворачивание рабочего окружения делается всего в несколько вызовов:
git clone https://github.com/hyoo-ru/mam.git
cd mam
npm install
npm start
И вы уже можете писать код, видя продакшен сборку в браузере.
После всем нам известных событий, много библиотек стали тянуть транзитивно вредоносные зависимости.
Хвала Ленину, что мейнтейнером $mol является мало того, что россиянин, так ещё и живёт он в России. Более того, ему хватает совести не использовать свои проекты для политической борьбы, и прагматичности не тянуть 100500 зависимостей. Благодаря чему приложения получаются куда более легковесными (Пруф).
был сложный компонент редактора документов на 2000 строк кода и на 3000 строк шаблона
А после переписывания на $mol он похудел до 300 строк кода и 200 строк "шаблона" (Пруф).
Наследование нас спасло от дублирования кода, но не от дублирования 3000 строк шаблона.
К счастью, в $mol наследование спасает и от дублирования в "шаблонах" (Пруф). Впрочем, декомпозиция, конечно, предпочтительнее.
Что делать, если потребуется передать данные из дочернего 1.1.1 компонента в дочерний 2.3.1?
Ну а если надо передать из 1.1 в 1.3 - тоже гонять всё через глобальную шину или глобальный стор? Всё же лучше иметь разнонаправленные потоки данных, которые позволяют хранить состояние в том компоненте, где ему место, а работать с ним из разных мест благодаря разнонаправленным потокам данных (Пруф).
Чтобы отобразить пользователю ошибку, по всему проекту встречались вот такие куски кода при каждом обращении к серверу (и не только):
Ну, в реализации на $mol они бы у вас и не встречались вовсе, так как ошибки, как и индикаторы ожидания показываются автоматически там, где это необходимо (Пруф).
Есть такая поговорка - "самый худший клиентский код - это тот, который написал синьор-бекендер"..)
В очередном проекте нам хотелось не допустить такого развития событий, и, кажется, у нас получилось.
Не думали нанять одного-двух фронтов с высокой экспертизой, которые бы закрывали все ваши боли на легаси-проектах, и быстро и правильно делали новые? Разделение труда, делегирование и всё такое..
При всем при этом можно реализовать его так, чтобы разработчики не впадали в фрустрацию при каждой следующей доработке. Даже больше, сейчас некоторые коллеги по команде охотно берут задачи на доработки frontend.
Мы постарались написать приложение так, чтобы backend разработчикам было наиболее привычно и комфортно. Классы, интерфейсы, наследование, типизация, вот это вот всё… И, конечно же, чтобы визуально это смотрелось красиво и современно.
Реализовать хороший и не сложный frontend под силу не профильным разработчикам.
Нет боязни, что в итоге есть немаленький шанс, что у вас получился "write-only" код? И после передачи проекта другим людям, у них не возникнут теже мысли как у вас в начале? - типа "нежелание кого-либо туда лезть и что-то править. Команде там кажется страшно, непонятно и неудобно. Любая доработка превращается в головную боль."
В итоге, всё по новой будет переписываться, потому что кто-то решил "нашарик" попрактиковаться пописать боевой фронт.. там же ничего сложного.. формочки, таблички, кнопки.. обезьянки справятся)
Не думали нанять одного-двух фронтов с высокой экспертизой, которые бы закрывали все ваши боли на легаси-проектах, и быстро и правильно делали новые? Разделение труда, делегирование и всё такое..
Думали. Провели ни одну встречу за обсуждением. У нас фронт маленький и обычно доработок по нему в спринт на 1-2 дня. Что делать тогда фронтендеру с его высокой экспертизой остальное время не ясно...
Нет боязни, что в итоге есть немаленький шанс, что у вас получился "write-only" код? И после передачи проекта другим людям, у них не возникнут теже мысли как у вас в начале?
Опробовали на двух новых сотрудниках, без опыта работы с фронтом. Дали им пару задач не сложных. Разобрались. И теперь даже охотно берут новые такие задачи.
Как backend разработчики frontend писали (Vue + TS + Webpack)