По словам Джона, последние три года он занимается коммерческой разработкой на React. Он говорит, что когда в компанию, где он работает, приходят клиенты, чаще всего они заявляют о том, что хотят, чтобы их проект был создан с использованием React. Однако, судя по всему, через некоторое время похожим уровнем внимания будет пользоваться и Vue. В этом материале он анализирует React и Vue для того, чтобы лучше понять разницу между этими двумя библиотеками? и говорит о том, что то, чему посвящена эта статья, поможет ему в работе с клиентами. Он полагает, что даже хотя работает с React уже несколько лет, и ему нравится то, что он делает, неплохо будет подготовиться к будущему, так как при работе с Vue могут возникнуть неожиданные ситуации, в которых его опыт ему не поможет.
Начнём с конца
Я хочу начать мой рассказ о React и Vue, как ни странно, с выводов. Эти два фреймворка похожи, хотя между ними имеются некоторые важные различия, о которых я кратко расскажу. Зачем их сравнивать? Одна из причин заключается в том, что для Эвана Ю, разработчика Vue, React был одним из источников вдохновения. Эти фреймворки гораздо сильнее похожи друг на друга, чем они же, скажем, похожи на Angular или Ember. Из документации Vue можно узнать, что оба фреймворка, о которых мы сегодня говорим, обладают следующими особенностями:
- Использование Virtual DOM.
- Реактивная и компонентная структура.
- Основное внимание уделяется главной библиотеке. Дополнительные задачи, вроде маршрутизации и управления глобальным состоянием приложения, решают вспомогательные средства.
Если рассматривать готовые проекты, построенные на базе этих библиотек, не думаю, что между теми из них, которые сделаны на Vue, и теми, которые построены на React, можно увидеть серьёзные различия. А именно, React и Vue похожи в плане производительности, оба фреймворка подходят для создания проектов самых разных масштабов.
Если вы разрабатываете приложение, рассчитанное на разные платформы, например — на традиционный веб и на мобильные устройства, преимущество оказывается у React благодаря замечательному React Native. Мои коллеги, кроме того, использовали React для создания встраиваемых приложений для телевизоров. Это — интересный пример экзотической платформы, на которой можно использовать React. Однако, возможности разработки приложений под мобильные платформы есть и у Vue, благодаря Weex, поэтому, вполне возможно, что для некоего мобильного проекта предпочтительным окажется именно этот фреймворк.
Нужно отметить, что экосистема React гораздо больше, чем у Vue, что вполне может способствовать успешности и скорости разработки. Если для того, чтобы React-приложение состоялось, нужен некий важный функционал, велики шансы того, что нечто подобное уже реализовано. На самом деле, весьма вероятно то, что для множества проблем в сфере React можно будет найти даже несколько вариантов решений.
Ещё одно важное соображение для того типа клиентов, с которыми работает моя компания, это возможность найти разработчиков, которые хорошо разбираются в библиотеке или фреймворке, на который эти клиенты делают ставку. Тут у React тоже есть преимущество, хотя я полагаю, что оно, скорее всего, временное.
Другие различия, в основном, относятся к тонкостям разработки и к техническим деталям. Например, они касаются парадигм программирования, которым свойственны определённые особенности, какие-то компромиссы, и я не могу выделить ни в одной из них чётких сильных или слабых сторон. Это мы ещё обсудим.
В итоге можно сказать, что если имеется команда, которая уже знакома с React, переход на Vue особых преимуществ ей не даст (о минусах поговорим ниже). Если ваша команда только начинает заниматься разработкой фронтенда веб-приложений, или подумывает о том, чтобы перейти на что-то новое с фреймворков вроде Backbone или AngularJS, тогда вам стоит посмотреть в сторону Vue, хотя вышеозначенные сильные стороны React никуда не деваются. Другие факторы, опять же, касаются технических деталей, о которых мы сейчас поговорим.
Различия React и Vue
Пожалуй, лучше всего, сравнивая React и Vue, обратиться к документации по Vue (весьма качественной), в которой их сходства и различия раскрыты очень хорошо. Эта документация особенно полезна, так как она была написана Эваном Ю вместе с Дэном Абрамовым, членом команды React. Кроме того, если я буду относиться к чему-то предвзято, выдержки из документации помогут трезво взглянуть на положение дел.
?Производительность
В плане производительности Vue и React очень похожи. В документации Vue сказано, что у Vue, в большинстве случаев, есть небольшое преимущество, однако, свежие бенчмарки показывают, что React 16 быстрее чем Vue 2.5. Некоторые различия в работе с фреймворками наблюдаются и при оптимизации производительности.
В React, когда изменяется состояние компонента, это вызывает повторный рендеринг всего поддерева компонента, начиная с него самого. Он выступает в роли корневого компонента. Для того, чтобы избежать ненужного повторного рендеринга дочерних компонентов, нужно либо использовать
PureComponent, либо реализовать, везде, где это возможно, shouldComponentUpdate.В Vue зависимости компонента автоматически отслеживаются при его рендеринге, поэтому система точно знает, какие компоненты нужно повторно отрендерить при изменении состояния. Каждый компонент можно считать имеющим нечто вроде автоматически реализованного метода
shouldComponentUpdate, без ограничений, которые могут вызывать вложенные компоненты. Такой подход устраняет необходимость в целом классе оптимизаций производительности, и позволяет разработчикам заниматься созданием и развитием основного функционала приложений, а не решением вспомогательных задач.Тут мне хотелось бы отметить, что 19-го декабря 2017-го, после того, как я, вникая в тонкости вопросов производительности веб-фреймворков, опубликовал свежую статью, я понял, что мои выводы о производительности фреймворков стоит уточнить. Vue немного быстрее, но результат зависит от того, что именно измеряют.
?Шаблонизация и JSX
Ещё одно серьёзное различие между рассматриваемыми фреймворками заключается в том, что в Vue используются шаблоны, а в React — JSX. Многим программистам не нравится язык шаблонов. Вот что об этом говорит документация Vue:
Некоторые утверждают, что для того, чтобы писать шаблоны, нужно изучить дополнительный специализированный язык. Мы считаем поверхностным такой подход при сравнении Vue и React. Во-первых, использование JSX не означает, что программисту не нужно изучать ничего нового, так как перед нами — дополнительные конструкции, построенные на обычном JavaScript. В результате JSX легко освоить тому, кто знаком с JS, но говорить, что для использования JSX не нужно прилагать вообще никаких усилий — это уже чересчур. Аналогично, шаблоны — это расширение обычного HTML, и, таким образом, те, кто знаком с HTML, могут освоить их без особых проблем. Благодаря особенностям шаблонов, мы, кроме того, можем помочь программисту добиться большего, написав меньше кода (например, с использованием модификаторов
v-on). Для решения тех же задач может понадобиться гораздо больше кода при использовании обычного JSX или рендер-функций.Меня беспокоит ситуация, когда при разработке приложения смешивают JSX и язык шаблонов. Это усложняет проект. Проще придерживаться какого-то одного подхода, иначе неизбежна трата сил на «переключение контекста», на переход из одной среды в другую. Однако, могут найтись те, кто с этой идеей не согласится.
?CSS
В Vue очень приятно работать с CSS. В документации Vue, где этот фреймворк сравнивают с React, определённое внимание уделено и CSS. В React, в частности, весьма популярно использовать так называемый CSS-in-JS. Взглянем в документацию:
Если вы — фанат подхода CSS-in-JS, знайте, что он доступен и в Vue, благодаря многим популярным библиотекам, например, таким, как
styled-components-vue и vue-emotion. Главное различие между React и Vue в этой области заключается в том, что в Vue для стилизации по умолчанию применяются теги style в однофайловых компонентах.Мне нравятся однофайловые компоненты, которые включают в себя CSS. На рисунке ниже показан пример компонента из документации. Обратите внимание на тег
<style> в нижней части кода.
Этот тег в файле компонента даёт нам стили, ограниченные рамками этого компонента, плюс — удобства при редактировании кода в виде подсветки синтаксиса. Кроме того, такой подход проще в реализации, чем CSS-in-JS из React…
?Экосистема
Как уже было сказано, экосистема React намного больше, чем экосистема Vue. Перед нами — одно из преимуществ React, но это может запутать новичков. Vue даёт сообществу меньше свободы. Вместо этого важные библиотеки пользуются официальной поддержкой:
Вспомогательные библиотеки Vue для управления состоянием приложения и маршрутизации (помимо прочего), официально поддерживаются и обновляются в соответствии с основной библиотекой. В React, вместо этого, выбран путь передачи этих функций сообществу. Это усиливает фрагментацию экосистемы. Однако, благодаря большей популярности React, и его экосистема оказывается более обширной, чем у Vue.
?Управление состоянием
Для меня управление состоянием приложения — основное различие React и Vue. Одна из ключевых парадигм в React — функциональное программирование. Если вы используете вместе с React популярную библиотеку для управления состоянием Redux, значит вы уже работаете в рамках функционального подхода к разработке приложений.
Подобное внимание к функциональному программированию в React в последние годы оказало серьёзное воздействие на обширное сообщество JS-разработчиков. Создатели React не являются изобретателями функционального программирования — это довольно старая идея. Однако, React, совершенно очевидно, популяризовал эту концепцию среди нового поколения программистов. Это — мощный подход к программированию, который, лично мне, помогает писать более качественный код.
Один из основополагающих принципов функционального программирования — неизменяемость (иммутабельность). Вот, если интересно, недавнее выступление, посвящённое важности иммутабельности, но основная идея тут заключается в том, чтобы управлять тем, что называется «побочными эффектами», а также упростить и сделать более предсказуемым управление состоянием приложения.
Надо отметить, что сам по себе React — это библиотека, которую нельзя назвать полностью соответствующей духу функционального программирования. Существует, кроме того, популярная библиотека для управления состоянием React-приложений, которая называется MobX. Она реализует изменяемое состояние приложения. Вот что об этом можно найти в документации к Vue:
Библиотека MobX стала весьма популярной в сообществе React-разработчиков, и она, на самом деле, использует систему реактивности, практически идентичную таковой в Vue. В некоторой степени связку React + MobX можно рассматривать как более многословную версию Vue, поэтому, если вы используете эту комбинацию и она вам нравится, переход на Vue, вероятно, это следующий логический шаг.
Об этом же пишет и Эван Ю в одном из своих твитов.
Ещё одно популярное средство управления состоянием в Vue — это библиотека, которая называется Vuex. Вот выдержка из статьи, где сравнивают Redux и Vuex, которая поможет выделить отличия этих библиотек:
Vuex, как и Redux — это библиотека, создатели которой вдохновлялись Flux. Однако, в отличие от Redux, Vuex изменяет состояние вместо того, чтобы сделать его иммутабельным и заменять его полностью, как с помощью функции-редьюсера в Redux.
Это позволяет Vue.js автоматически получать сведения о том, какие директивы, при изменении состояния, нуждаются в повторном рендеринге. Вместо того, чтобы использовать специализированные редьюсеры, Vuex позволяет организовать управление состоянием приложения с использованием хранилищ, называемых модулями.
Хотя тут мы уходим в технические сферы, для многих разработчиков парадигмы кое-что значат. Если вы из тех, кто придерживается функционального подхода, тогда React, вероятно, окажется для вас более привлекательным (с возможным исключением тех, кто пользуется MobX). Если нет — тогда интереснее может оказаться Vue.
Дополнительные материалы
Недавно Дэн Абрамов довольно активно общался в Твиттере, высказываясь по поводу сравнений React и Vue, сделанные не в пользу первого. Думаю, на эти твиты стоит взглянуть. Дэн — это часть команды разработчиков React, и в его комментариях есть некоторая предвзятость, но они, всё равно, предоставляют дополнительную пищу для ума в отношении сравнения React и Vue.
Вот Дэн отвечает на критику простого примера с использованием React, говоря, что React нацелен на то, чтобы упростить понимание кода даже несмотря на растущую сложность требований к проекту, а не на то, чтобы сделать простые примеры как можно более короткими.
Здесь он рассказывает о том, что React реализует поток данных, направленный сверху вниз. Поэтому изменения перенаправляют поток данных по предсказуемым путям в кодовой базе вместо того, чтобы, если что-то поменялось, пускать их по произвольным маршрутам. Он говорит, что в некоторых случаях это означает больше кода. Но это ведёт к появлению кода, который, в долгосрочной перспективе, легче читать и поддерживать.
Тут он говорит, что простой и сложный код обычно выглядят практически одинаково. И нет пропасти, которую нужно перепрыгнуть для того, чтобы добиться большей выразительности программ. В случаях с привязками данных или с потоком управления, предоставленных некоей библиотекой, это часто не так. При этом он добавляет, что это не говорит о том, что Vue — это плохо (многим нравятся особенности этого фреймворка), но судить о фреймворках, основываясь на том, какой «Hello World» меньше, по его мнению, уводит от реальности.
Итоги
Как вы помните, итоги сравнения React и Vue мы подвели ещё в самом начале этого материала. Поэтому здесь я хочу привести цитату из интервью Эвана Ю, которое он дал Вивиан Кромвель. Разговор шёл о том, как выглядит Vue в сравнении с другими фреймворками.
Я думаю, если учитывать все существующие фреймворки, Vue, вероятно, сильнее прочих похож на React, но в более широком смысле, среди всех фреймворков, его можно назвать придуманным мной термином «прогрессивный фреймворк». Идея заключается в том, что Vue — это ядро, которое представляет собой привязку данных и компоненты, что делает его похожим на React. Оно решает очень точно определённый, ограниченный набор задач. В сравнении с React, Vue уделяет больше внимания доступности технологий. То есть, он нацелен на то, чтобы люди, которые знают основы, а именно — HTML, JavaScript и CSS, могли бы освоить его как можно быстрее.
Мы стараемся строить Vue как фреймворк с компактным, минималистичным ядром. Но, по мере роста сложности ваших приложений, перед вами, вполне естественно, встают новые проблемы. Например — маршрутизация, обмен данными между компонентами, разделение состояния в больших приложениях. В том же ряду — потребность в инструментах для сборки проектов, помогающих сделать кодовую базу модульной. Тут же можно задаться вопросами об организации стилей и различных дополнительных ресурсов, входящих в состав приложения. Многие фреймворки, которые можно назвать более завершёнными, охватывающими решение более широкого спектра задач, чем возлагается на ядро Vue, такие, как Ember или Angular, пытаются предложить разработчику решение всех задач, с которыми он может столкнуться, и пытаются сделать всё встроенным в фреймворк.
Это — некоторый компромисс. Чем больше предположений о том, как программисты будут пользоваться фреймворком, делается при его разработке, тем меньше гибкости, в итоге, такой фреймворк допускает. Ещё один вариант, противоположный первому — перекладывание решение всех вспомогательных задач на сообщество, как сделано в React, экосистема которого полна жизненных сил. Тут постоянно возникает множество идей, но в таком положении вещей есть и минусы. Vue пытается найти золотую середину, когда ядро предоставляет весьма ограниченный набор возможностей. Однако, в дополнение к этому, мы предлагаем решения, подходящие для поэтапного внедрения, вроде систем маршрутизации и систем управления состоянием приложения, вроде набора инструментов для сборки проектов и средств командной строки. Все они поддерживаются официально, хорошо документированы, спроектированы с расчётом на их совместное использование, но использовать их все разработчик не обязан. Я думаю, что это, вероятно, самое главное, что отличает Vue, как фреймворк, от других подобных решений.
Уважаемые читатели! Как вы полагаете, какая судьба ждёт React и Vue в будущем году?
Комментарии (45)
BaMIIuP3456
25.12.2017 16:42- Мне кажется, подобным сравнительным статьям не хватает несколько примеров с задачами на порядок выше HelloWorld и с демонстрацией решения. У меня есть небольшой опыт разработки под React и нет опыта в Vue. И мне бы было бы искренне интересно посмотреть на каких конкретных примерах лучше один из фреймворков. Читая подобные статьи, лично у меня создается какое-то поверхностное представление. И я понимаю, что, чтобы действительно разобраться, мне нужно самому попробовать, но при этом хотелось бы получить эти знания из сравнительной статьи. А так получается, что это ещё одна статья из множества про поверхностное сравнение фреймворков только обновленная.
- Вот например, разговор про CSS. Неужели это действительно важная и сложная проблема? Работая с React, никогда не возникало никаких проблем в этом плане. Во Vue, я так понимаю, таких проблем тоже нет. Тогда зачем об этом говорить? Неужели в React это сделано настолько хуже и это должно меня мотивировать использовать Vue?
- Сравнение HTML-шаблонов и JSX. Об этом наверно уже было очень много разговоров. И одно и тоже. Вот лично у меня была проблема с JSX. Представим ситуацию, когда необходимо, чтобы HTML и CSS мог редактировать человек, без пересборки билда и запуска webpack dev сервера или его аналогов. Лично у меня не нашлось адекватного решения. А то что мне известно про фреймворки на основе HTML-шаблонов, в этом нет никаких проблем, т.к. HTML отделен от JS. React же по сути только JS, зная что JSX-это обертка над JS-кодом.
- Если сравнивать эту статью с её многочисленными аналогами, то она лучше только за счет своей актуальности. Она не хуже других. Но в абсолютном значении, мне все также необходимо изучить Vue, чтобы понять то, что мне бы хотелось понять после её прочтения.
Ungla
25.12.2017 23:41По поводу пункта 3. dangerouslySetInnerHTML дал мне возможность отредактировать HTML страницы с бэкэнда, а для остального, уверен, править JS код руками контент-менеджера — плохое решение.
За React скажу, что можно долго обсуждать, что он не фреймворк, но после того как я начал использовать его с Redux, я полностью переосмыслил подход к написанию приложений с React. Сначала всё это кажется неоправданно сложно, но после того как разберешься все становится предельно просто, стройно и красиво.
Akuma
26.12.2017 00:453. Вы можете написанный JSX преобразовывать в обычный JS (React.createElement...) на сервере и затем подсовывать его в render() метод. Но честно, я не представляю когда такое может понадобиться.
movl
26.12.2017 02:56Хотелось бы несколько раскрыть пункт про CSS, так как я его понял. И дополнить пункт про шаблонизацию, где я вообще не понял автора.
2) В примере в статье показывается, что для гарантированный изоляции стилей, применяемых к одному vue-компоненту, достаточно добавить директиву
scopedв месте объявления блока со стилями. А если взять во внимание различные методологии, которые решают проблемы изоляции, именования и прочие, то эта директива может оказаться очень простым решением. Хотя и нельзя сказать, что в случае react подобное сделать сильно сложнее.
3) Так как в Vue есть поддержка JSX, это вообще наверное нельзя называть пунктом для сравнения, по крайней мере актуальным пунктом. Или должно быть явно сказано, что в одном случае счет 2, в другом — 1. Автор, конечно, забавно подметил, что не понимает тех кто в одном приложении будет пользоваться двумя подходами, как-будто кто-то заставляет, или как-будто это минус библиотеки, но при этом из текста явно не следует, что в Vue есть поддержка JSX. А так как в сравнении производительности приводится версия 2.x, где JSX есть, то я делаю вывод, что автор либо не особо изучал данный вопрос и понятия не имеет о чем пишет, либо как-то очень странно, художественно что ли, подходит к сравнению по этому пункту (хотя может тут и проблемы перевода, оригинал не читал).
Pongo
27.12.2017 17:551. Есть github.com/gothinkster/realworld в котором пилят клон Medium'а на разных технологиях. Решение на vue, правда, пока еще в процессе.
BaMIIuP3456
25.12.2017 17:215. Производительность. Как бы я, скорее всего, понял вторую часть этого раздела, не зная ничего про Vue и React: «В React-е необходимо много возиться с shouldComponentUpdate, а во Vue все работает из коробки.»
Но подождите? На самом деле в React достаточно наследовать класс от PureComponent вместо Component. И на моей практике этого всегда было достаточно, с точки зрения работы с методом shouldComponentUpdate. А если вы используете Redux, то и этого делать не нужно! Да там упомянули про PureComponent. Но для человека не работающего с React, может быть непонятно, что в этом нет проблем. А если это так, то зачем запутывать людей? Вы спросите, а почему это может запутать? Да потому что, когда ведётся сравнение, в детали обычно имеет смысл вдаваться только, когда объясняют разницу, а не сходство.
Суть той части в том, что и во Vue и в React проблем с настройкой производительности нет. Стоит ли об этом говорить, если это не отличие? Мне кажется, что нет. А может ли это запутать?…Akuma
26.12.2017 00:43Позвольте я немного перефразирую.
В Vue нужно возиться во все тех же случаях, что и в React с shouldComponentUpdate. Во всех остальных случаях все работает из коробки и там и там.VolCh
26.12.2017 10:36Vue тоже не производит глубокого сравнения объектов?
Akuma
26.12.2017 10:47А вы думаете глубокое сравнение объектов всегда быстрее рендера в виртуальный дом?
VolCh
26.12.2017 11:08Не в скорости дело, а в том, что можно долго искать почему компонент не перерендеривается когда точно знаешь, что значений свойства изменилось.
Akuma
26.12.2017 11:11Ну, у Реакта я с таким ни разу не сталкивался, хотя не первый год с ним работаю.
Разве что в связке с MobX, но это немного другая история. Хотя тоже всего пару раз «попадал».
BaMIIuP3456
27.12.2017 00:12А как это у вас получается? Что в документации для Redux, что для React, строго необходимо менять все объекты по пути к изменённому свойству. Исходя из этого, независимо от того на какой глубине произошло изменение, корневой объект всегда будет новый, и поэтому всегда будет достаточно ленивого сравнения. Т.е. shouldComponentUpdate если все делать правильно никогда ненужно трогать, если происходит наследование от PureComponent. Считаю это справедливым для чистого React и React + Redux. Насчет React + MobX ничего не могу сказать.
VolCh
27.12.2017 15:51Redux я сейчас не рассматриваю. При наследовании от PureComponent нужно отдельно следить, чтобы свойства и пр. не требовали глубокого сравнения. При наследовании от Component — не нужно, но, возможно, потребуется использовать shouldComponentUpdate для приемлемой скорости
BOM
25.12.2017 22:06Господа, я что-то пропустил? Когда React успел стать фреймворком?
movl
26.12.2017 03:03Когда автор не вкладывает в это понятие, то что вы вкладываете. Считаю бессмысленным спор про определения, так как в статья явно указывается, что сравниваются две очень похожие сущности, созданные для решения одинаковых проблем.
BOM
26.12.2017 09:28Может тогда лучше использовать то определение, которое используют сами разработчики?
A JavaScript library for building user interfaces © reactjs.org
A declarative, efficient, and flexible JavaScript library for building user interfaces © github.com/facebook/react
FoterIS
26.12.2017 08:04Спасибо за статью, но не хватает более живых примеров из сложных проектов. Сам только изучаю React и параллельно посматриваю на Vue. Пока Vue мне нравится немного больше, по следующим пунктам:
- Документация, видимо потому-что к ней приложил руку Дэн Абрамов
- работа с анимацией, по крайне мере документация по ней сделана лучше, чем в React
- директивы v-if, v-else, v-show
Но т.к. пока изучаю React вчера столкнулся с таким решением скрытия элемента и как это реализовано в Vue мне нравится гораздо больше.
React... { errors.length > 0 ? Errors(id, errors) : null } ... const Errors = (id: string, errors: string[]) => { <ul className="mme-input__error"> { ... } </ul> }Akuma
26.12.2017 11:16{errors.length > 0 ? <ul className="mme-input__error"> ... </ul> :null}
Я не думаю, что вам нужны все эти объявления из вашего примера. JSX — просто JS, вы можете писать код как вам угодно.
Вы, как и многие другие, приводите два примера с разным количеством действий и, соответственно, разным количеством кода. А потом удивляетесь, чего Реакт-код такой объемный :)VolCh
26.12.2017 11:29У меня вопросы скорее к vue коду, его читаемость мне кажется худшей из трёх вариантов. Что ul может не отображаться вообще становится заметно только после полного изучения его атрибутов, а условие может оказаться где-то за пределами экрана или просто затеряться среди десятка обычных атрибутов.
Akuma
26.12.2017 11:32Опять же, зависит от разработчика.
Поидее, надо переносить все vue-атрибуты в начало, чтобы их было видно. А длина строки, по хорошему, должна ограничиваться IDE и переноситься на следующую строку. Тогда все будет видно и понятно.
Но в нашей реальности получается как получается :) А потом виноват фреймворк :)VolCh
26.12.2017 11:53Один из (основной?) переводов слова "фреймворк" — "рамки". Таки да, фреймворк виноват, что не загнал пользователя в жёсткие рамки :)
Akuma
26.12.2017 11:59Я не писал про то, что фрейморк загнал нас в рамки :)
Я писал, что программист криворукий (никого конкретно не имею ввиду) и написал код, который усложняет восприятие и работу в целом :)
Грубо говоря, вот вам разница:
Фрейморк не виноват в этом случае.VolCh
26.12.2017 12:02Так если не загнал — значит виноват :) Должен был загнать, например кидать ошибку если атрибуты v-* не первые в списке атрибутов :)
Akuma
26.12.2017 12:05Вот вам еще одно преимущество React.
Поскольку там JS, я могу настроить JSLint и вставить себе в колеса такие палки, что Vue и не снилось :)
P.S. Но вы можете подать идею в Vue, чтобы шаблоны не работали, если их атрибуты «забыты» в конце. Будет весело )
FoterIS
26.12.2017 15:10Я ни в коем случае не виню JSX и не грешу на длину кода, в данном примере я все же больше хотел сделать акцент на обязательный null в случае если не надо отображать элемент, либо можно без null но тогда придется обернуть в if(...){...} и это классно что у нас есть такая гибкость, лично для мне более лаконичным и приятным взгляду было бы использование директивы.
karapetyansa
26.12.2017 20:49null не нужен
{errors.length > 0 && <ul className="mme-input__error"> ... </ul> }
reactjs.org/docs/conditional-rendering.html#inline-if-with-logical--operator
Wentris
28.12.2017 13:55Да вот даже так…
{ !!errors.length && <ul className="mme-input__error">...</ul> }
justboris
27.12.2017 00:34не нравится инлайновые условия, напишите себе хелпер.
function If({condition, children}) { return <>{children}</> }
Получится даже лучше Vue, потому что одним if можно скрывать сразу несколько соседних элементов
<If condition={hideBlock}> <h1>Block title</h1> <p>Block content</p> </If>VolCh
27.12.2017 15:52Прямо ангуляр какой-то получается :)
P.S. Но выглядит лучше чем с Vue и даже не из-за группировки, а из-за того, что if в самом начале конструкции.
justboris
27.12.2017 15:58Как-то так. Об этом даже была полноразмерная статья.
UPD. Там еще полезную библиотеку jsx-control-statements упомянули.
gigachel
27.12.2017 18:00Что-то похожее и на Vue можно:
<template v-if="ok"> <h1>Заголовок</h1> <p>Абзац 1</p> <p>Абзац 2</p> </template>
Поскольку v-if — это директива, она должна быть указана в одном конкретном теге. В данном случае template — это псевдоэлемент, который служит невидимой обёрткой и сам в результатах рендеринга не появляется.
beduin01
React это какой-то PHP для клиентской части. От чего ушли к тому пришли. Мешать код с шаблоном это полностью упоротое решение. Vue в этом отношении на голову выше.
defaultvoice
Из раза в раз в каждой статье, где упомянут реакт, находится человек, который пишет такой комментарий.
Может, это традиция такая? :)
bitver
А вы не мешайте код с шаблоном, никто не заставляет.
Но как из банального массива вывести данные без цикла? Мне приятнее на js смотреть в плане циклов и прочего, чем на странные атрибуты в html. Вкусовщина, не более.
VolCh
XSLT :D
Akuma
О ужас, кто-то еще помнит этого монстра :)
movl
По поводу вкуса, мне лично нравится подход, который используется в blaze, но там усатые шаблоны, что может не для всех будет выглядеть эстетично. С другой стороны можно использовать pug и его нативные условия, итераций, переменные и т. д. Все никак не могу себя заставить дописать плагин, для компиляции pug в код шаблонов vue, именно не трансляцию в html и подключение в качестве результата шаблона, а трансляцию pug в код на js. То есть что бы работал код ниже:
Вообще странным считаю, что никто еще такого не сделал, видел подобное опять же для метеора, со своими синтаксическими особенностями правда, что в прочем не мешало. И для react, трансляцию pug в jsx, но работает это достаточно странно, из-за ограничений при интерполяции.
Ungla
Мне кажется вы лучше разбираетесь в поисках острых словечек, нежели истины или выбора. Я больше года топил за Angular, занимаясь бэкэндом. Ведь это фреймворк, это важно, очень важно, чтобы фронт был написан с использованием именно фреймворка! Но поработав с BackBone, например, и затем поработав (именно поработав, оба проекта были чужие) с React, а особенно с React+Redux, я резко изменил свою позицию. Есть отличный аргумент не в пользу реакта, «каждый проект — зоопарк технологий», но корни этого аргумента в том, что на практике реакт предоставляет гибкость, которая не снилась ни одному фреймворку.
Akuma
«Вы просто не умеете его готовить».
В PHP в шаблонах нет ничего плохого. Все шаблонизаторы — лишь синтаксический сахар. Сказки про «ограничения для чистоты кода» годятся только для совсем уж новичков. На том же Twig можно так упороть шаблон, что PHP и не снилось.
С React та же история. Вас никто не заставляет мешать код с шаблоном. Просто вы никак не признаете, что в современном вебе JS-шаблон без кода никому не нужен.
bro-dev
В пхп с шаблонами как раз таки всё норм он для этого и придуман, но там весь остальной код написан на том же языке что и шаблоны.
VolCh
Толсто.