Комментарии 62
Поэтому мы и видим статьи вроде: «Мы реализовали крупный проект на React. Все круто» или «Мы реализовали крупный проект на Angular, но есть подводные камни».
И не видим «Мы переписали с Angular на Vue и получили большой профит»
А потом выясняется, что бесплатного сыра таки не бывает, внутрь магии таки надо лезть, и, в общем, применять с осторожностью. Пока разберёшься — уже выйдет какая-нибудь четвёртая версия фреймворка, в которой в очередной раз всё переделали «с нуля» и несовместимо, вместо того, чтобы довести до ума первую.
Но.
Не имеет абсолютно никакого желания тратить на это своё время, а также учитывать миллион нюансов при каждой поездке.
На мой взгляд современные фронт-энд фреймворки не достигли уровня, когда их можно просто использовать, решая более высокоуровневые задачи.
- Избегать большого количества connect-ов, т.к. они все вызываются при каждом изменении stor-а. В сложных случаях можно даже свою, какую-нибудь иерархическую версию запилить.
- Использовать PureComputed практически повсеместно, опираясь на то, что у нас всё древо данных immutable.
- Внимательно следить за тем, что и куда мы передаём в качестве props, чтобы не получалось ситуаций, когда мы каждый раз зазря генерируем новым объект, хотя можно было бы обойтись старым, воспользовавшись мемоизацией.
- В целом много-много селекторов и прочих мемоизаторов. Можно даже на основе WeakMap-а.
- В целях борьбы с props-hell использовать контекст в ключевых местах.
- Профилировать при малейшем подозрении на тормоза. Отслеживать те места, которые подозрительно много считают. Потом "чинить" их, реорганизовывая их потоки данных.
И т.д… В общем нужно добиться того, чтобы render vtree лишний раз не происходил. Чтобы он настигал только те компоненты, которые и правда зависят от тех данных, что были изменены.
MobX + React Context API? Для очень сложных вещей MobX State Tree
А вот как управлять в Vue сложными реляционными данными (по типу MobX State Tree) я и сам не знаю.
Вообще, у Реакта самые продвинутые средства управления состоянием. Потому что он, в отличие от других фреймворков, не лезет в это сам, а предоставляет эту роль сторонним библиотекам.
А он умеет работать с нормализованными реляционными данными?
Вот пример с MST. Изнутри хранилище выглядит так:
{
authors: {
123: { id: 123, name: "John Doe", books: [4567] }
},
books: {
4567: { id: 4567, title: "VueX vs MobX", author: 123 }
}
}И инициализировать мы его можем выхлопом Normalizr. А потребителю данных они уже предоставляются в объектном виде (ссылки и массивы Id преобразуются в computed поля):
type Author = { id: number; name: string; books: Book[] };
type Book = { id: number; title: string; author: Author };Причем, поддерживается Reference Integrity:
store.authors[123].books[0] === store.books[4567].author
Из коробки как и чистый mobX нет — но есть либы которые добавляют ему эту функциональность вроде vuex-orm
Я был вынужден отказаться от redux из-за этого. Попробуйте mobx, в нем нету описанных вам проблем, есть action, есть store, первое умеет менять второе, все! Остальное библиотека сделает сама. такое решение гораздо лучше масштабируется на больших приложениях.
В случае Vue, можно полностью отделить мух от котлет и не думать о коде, т.е. условно можно легко разделить дизайн и код, в то время как написание на React мало отличается от написания на чём угодно другом (от бейсика до C#), со всеми вытекающими отсюда последствиями (в основном негативными).
PS: Можно много спорить о «правильности» подходов, но всё же более удобно и логично разделять код и данные. Возможно, кому-то без разницы, но иногда стоит думать о том что изменения придётся вносить кому-то другому, и ему может быть не всё равно.
Потому что у кого-то слова сильно длиннее, чем в default language, у кого-то падежей больше одного, а некоторые вообще задом наперёд пишут. И правкой строк это не решается никак.
Или вот в той же цивилизации 6, постоянно надписи типа «по приглашению ацтекск. правительства...». Ну не положено словам склоняться, по мнению разработчиков, так что покупатели их игрулек должны страдать. Хотя здесь ещё переводчики попытались хоть как-то уложиться в требования языка.
Китайцы, которые vue делали, очевидно хорошо знакомы с проблемой. И поэтому всё сразу сделали правильно.
Всё не так просто. Даже расположение элементов на форме может отличаться в зависимости от языка. Вот для примера. На русском языке: от [ввод-даты] до [ввод-даты]. А на казахском: [ввод-даты] бастап [ввод-даты] бойынша. Полагаю, это ещё цветочки. Я думаю, что в реально сложных случаях может потребоваться треть формы перекроить.
В немецком, например, бывают просто очень длинные слова. 40, 60 символов. Которые никак не лезут в отведённое им место и нормально не переносятся. Даже уменьшение шрифта не поможет, нужно перепиливать форму.
В иврите не только обратный порядок букв, там обратный порядок всего. Т.е. кнопки нужно двигать влево и т.д.
В восточно-азиатских языках (с иероглифами) другие виды списков, не такие, как у европейцев. См. тег <ruby>. Да там всё другое, те же даты записывают как-то так: 2018年8月7日.
Во франции за коверканье языка штрафуют, и больно.
В ближневосточных языках не 2 набора букв (прописные/строчные), а 4, и за неверный выбор набора можно неиллюзорно огрести от имама.
Да куча всего.
То, что миллионы быдлокодеров за фикс прайс с апворка делают иначе — не показатель.
То, что так делают прыщавые стартаперы из долины, которым нужно быстро выкатить MVP для внутреннего рынка — не показатель. А потом им видите ли лень рефакторить своё уг, пусть эти аборигены жрут что дают.
И да, plural forms решают проблему примерно никак.
И да, переводчикам отдаётся только html-код (часть template в листинге в статье), но при желании они могут дописать кусок style. И они отлично умеют с этим работать.
Если про игры говорить, то вот Ведьмак, например, сделан правильно. Линейка (ла2) и вообще игры ncsoft тоже. В-общем, всё, что сделано не американцами, как правило, таких проблем не имеет.
Так всё-таки как же во Vue отделить мух от котлет и сделать интернационализированную корзину?
Да делайте как хотите. У вас на каждый язык — свой фрагмент html. Внутри вы можете дёргать любые функции (стандартные или свои), использовать условные и тернарные операторы, лепить нужные стили — всё, что вам угодно. И вся эта логика представления инкапсулирована в отдельном файле, никак не зависит от логики компонента и не мешает ни обновлению компонента, ни обновлению других языковых шаблонов.
Битрикс же сам по себе пример плохого дизайна системы.
Ну, конкретно в этом месте у них отличный дизайн. И да, они поддерживают «из коробки» 17, что-ли, языков — как в стандартных шаблонах, так и в админке. И вы ни на одном языке не увидите «2 товар(ов)». Ну, если внедряльщики не постараются.
И не надо считать технических переводчиков идиотами, как правило это инженеры, получившие второе образование (или типа того), а не просто какие-то там девочки «с филфака и в декрет». Разобраться чисто в html вёрстке и паре несложных функций они вполне могут. Ну, если мы про нормальный продукт говорим, а не про херак-херак и в продакшн, пусть пипл хавает.
И да, какая же всё-таки схема с переводами использована в Линейке и Ведьмаке?
Вы таки не поверите, но там внутре все диалоги, формы и т.д. — это фрагменты html. Просто у каждого варианта, например, в диалоге прибит гвоздями уникальный id.
Да да. Вспомнить только сколько было и есть багов, связанных с раскладками клавиатуры и горячими клавишами. И ведь именитые конторы и продукты! Я лично сталкивался с подобными проблемами от Adobe. И ладно бы горячие клавиши просто не работали, но блин были даже проблемы, когда что-то не работало если в имени профиля пользователя есть кириллица! Adobe! Ну как так? :) А QT4? А SublimeText? Да тысячи этих "кривых" приложений.
ПО написанное в чисто англоязычной компании с большой степенью вероятности огребает от всех возможных костылей связанных с локализацией, раскладками, RTL, fonts, etc.
Но постойте! Почему при установке большинства англоязычных модов локализация сбивается и местами пропадает?
Перевод понятно. Но сама технология, HTML in JS, это же то, от чего мы так долго уходили в js, так было круто, когда появился Backbone со своими разделяемыми шаблонами, и наконец можно было создавать нормальные приложения на MVC подобной архитектуре. И тут вышел ReactJS, появились новоиспеченные разработчики, которые еще не поняли, почему старики так боятся писать шаблоны в логике.
Самое главное, в C# сообществе давно ругают Windows Forms (пусть грубое сравнение, но это аналогичный компонентный подход), все ругают VCL, и в других языках люди пишут на MVC красотах типа Laravel, Django и.т.д., а мы на фронту кричим какой крутой и модный ReactJS. Понятно, что изоляция компонентов это круто, так можно без проблем создавать ортогональные системы, но реализация в ReactJS очень грубая, куда лучше в Vue с его компонентами на .vue и scoped стилями.
Может я реально старый, но я не испытываю удовольствие от написания/чтения кода на JSX, это какая-та лапша набитая логикой, разметкой и стилями. Vue глоток чистого воздуха, пиши шаблоны на чем хочешь, хочешь на html, хочешь на pug. Можешь разделять шаблоны от логики, а можешь писать прямо в компоненте или юзать JSX.
Всё хуже. Тут недавно товарищ отстаивал позицию, что css-стили написанные через интерполяцию, с анонимными методами и вложенными тернарными операторами, в строках-шаблонах — читаются легче и лучше, чем в SCSS. А каждый топик про несчастный Svelte переполнен хейтерами любого возможного DSL. Дескать даёшь везде встраиваемый JS, пусть даже написанный ногами с нагромождением всех видов кавычек, скобок и хаков вроде && ... ||. Мол JS мы уже знаем. Бррр. Мне не понять. Я даже для тестов часто новый DSL создаю исходя из задачи. А тут шаг в лево, шаг в право, "мой редактор не умеет ваш суржик, закопать!".
Сравнение React и Vue на практическом примере