Блогово
→
WebDev
→
Состоялся Vue.js Moscow Meetup #1 в логове Акрониса в Физтехпарке
26 Марта 2018 года
Я там был, мед-пиво пил.
Спасибо организаторам и докладчикам за клевый ивент! Делюсь своим бесценным (и запоздалым) мнением об увиденном. Видео можно позырить вот тут. В чате адовое трололо, кстати для ценителей. Ну или вот эмбед:
1) Выступление Александра Башкирцева было интересным, но не очень понятным =) Уловить мысль получилось, только почитав и пощелкав демо-код с включенным vue-плагином. Демонстрация и разбор кода, видимо, не влезли в регламент. Кто еще не ознакомился — ознакомьтесь обязательно: github.com/abashkirtsev/forms-example
Меня слегка сбило с толку название доклада, я скорее надеялся послушать про организацию верстки. Часто, особенно в CRUD-приложениях, верстать формы руками не хочется, потому что их много и они плюс-минус похожие. Можно взять генератор типа такого: github.com/vue-generators/vue-form-generator — и радоваться, пока не понадобится прикрутить что-то кастомное куда-то вглубь пирога «форма — строчки — поля». А когда понадобится — чесать репу, как бы так заинжектить нужный кусок vDom вниз через слоты на два уровня =) Короче, у меня это актуальная головоломка.
Александр же рассказал о том, как они организуют хранилище на основе Vuex, и этот (весьма интересный) подход, ИМХО, совершенно не завязан на хранение данных именно для форм — выбор todoMvc для иллюстрации эту мысль подтверждает. Но тем интереснее было бы посмотреть, как будет выглядеть реализация этой модели не на плоском списке, а на типичной ынтерпрайзной форме со вложенными группами полей, генерируемых из релейшнов, с хитрой валидацией и изысканными элементами UI :)
2) Доклад Александра Майорова был хорош и, как мне показалось, вызвал ажиотаж среди присутствующих ангулярщиков, реактщиков и прочих, кто Vue еще не щупал, но активно присматривается. Александр рассказал историю личного пути к Vue, довольно честно обозрел вообще развитие фронтенд-мысли за последние 5 лет, ну и, надеюсь, многих замотивировал пробовать.
Однако тема все-таки не была раскрыта: как в готовом проекте заменить jQuery на Vue нам не рассказали =( Александр лишь продемонстрировал, что порог входа действительно очень низкий, можно подключить Vue на страницу из CDN и немедленно начать колбасить, отложив настройку вебпака до лучших времен.Но это для нового проекта. А для готового, подозреваю, эта задача вообще не очень решается. Все-таки jQuery — это в первую очередь удобная манипуляция DOM-деревом, но для готовки дерева с нуля он не предназначен. Там, где есть много jQuery-кода (и сопутствующей скорби), обычно верстка приходит откуда-то снаружи, чаще всего HTML рисует серверный шаблонизатор типа Twig, а jQuery «оживляет» результат. В то же время Vue (как и любой из «большой тройки») может управлять только тем отображением, которое сам и нарисовал (потому что, собственно, нету «управления», есть перерисовка). Это значит, что:1) придется переписывать шаблоны (хорошо, если они хотя бы не «нейтив похапе»), 2) придется учить сервер отдавать JSON (хорошо, если в серверные шаблоны приходят «отупевшие» структуры, а не полноценные модельки, которые шаблон дергает за методы). Оба этих занятия не из приятных, опасности таят великие, а профит ну такой (оно же работает, правда?). Случаи бывают разными, но в целом я бы для проектов «с историей» рекомендовал такую тактику избавления от «истории»:1) не ставить задачу «избавиться от jQuery» (бизнес не оценит),2) но начать делать новые экранчики на Vue,2) и когда надо переработать какой-нибудь старый экранчик — тоже внедрять Vue.И надо понимать, что это требует значительного уменьшения связности в коде на разных уровнях — от бэкенда до CSS. Это полезно, но одним махом не делается.3) Александр Сафт рассказал о поиске удобного способа управления состоянием. Мне доклад очень понравился. Вообще гораздо интереснее слушать про решения не в вакууме, а в контексте того, как они появились, какие проблемы приходилось решать, на какие компромиссы идти. Это учит нас критически смотреть в том числе и на общепринятые подходы, периодически спрашивать себя, а действительно ли мне вот это нужно, а хочу ли я писать вот такой код только потому, что так в мануале написано, или можно сделать проще?Отдельно стоит заметить, что «оборачивание» Vuex или его замена на нечто «с человеческим лицом» — вообще прослеживаемая тенденция. Эта часть экосистемы, на мой взгляд, действительно выглядит слегка чужеродной, как минимум стилистически. Думаю, в ближайшее время мы еще увидим много интересного в этом направлении.4) Григорий «Сюрприз-сюрприз» Петров в хорошем темпе представил обзор Nuxt. Без жести, но с понятными примерами и по-честному. По крайней мере я наконец понял область применения этой штуки, это ценно =) Секция вопросов к этому докладу тоже была весьма интересной. Особо отмечу мысль о том, что для проектов со сложностью выше определенного уровня, нужно быть готовым переходить на самописные решения, потому что у готовых запас гибкости не бесконечный, а впихивать невпихуемое — иногда ощутимо дороже. Это было сказано про SSR, но можно обобщить.Когда появится следующая задачка класса RAD, постараюсь вспомнить про Nuxt.**Подводя итог: митап удался, организация на 5+, контент на 4+ на мой вкус (хотелось бы больше хардкора, но это кому как). Респекты всем, надо продолжать =)
|
|
