Комментарии 40
закачивают пачку других реакт-библиотек
React + MobX + Typescript и всё, теперь это человеческий и реактивный инструмент.
В отличии от ущербной связки react + redux(effecor и т.д и т.п.) или вообще голый react.
То что можно обвесить исходный пакет кучей других пакетов и собрать из этого свой фреймворк еще не делает изначальный пакет фреймворком. С таким успехом можно и jquery отнести туда же.
Да, да, и не вздумайте назвать Angular фреймворком! У них на сайте большим шрифтом написано: "The modern web
developer's platform".
Все таки от статьи "Впечатления о Vue.js после React" хотелось бы больше личных впечатлений, особенно мнение насчет различия некоторых подходов, плюсы и минусы одного по сравнению с другим. А то получается, что тут в основном базовая информации из доков по Vue.
Vue правильнее сравнивать не с Реактом, а с божественной связкой React+MobX, тогда будет что-то схожее.
По поводу шаблонов я так и не понял вот что:
v-on:change="todo.completed = !todo.completed"-будет ли внутри кавычек работать тайпчекинг (TS) и автокомплит (WebStorm, к примеру)?
Вообще субъективно мне не нравится код в строке. Непонятно, что за переменные, из какого они скоупа, и т.д. Вот чем хорош JSX/TSX — там всё как в обычном JS/TS, с переменными понятно, в частности.
Это совершенно не то, что вы думаете подставляю сюда голый реакт или реакт + редакс(и т.п.).
React + MobX это вообще абсолютно другой подход, именно человеческий, для людей. В этом подходе всё тоже элементарно и максимально просто. И писать тонны говнокода не требуется. Автокомплит работает идеально, 100% поддержка тайпскрипта, средства IDE задействованы по максимуму без ограничений.
this.handleSubmit = this.handleSubmit.bind(this)
Теперь принято вот так:
class Demo extends React.Component {
handleSubmit = () => {
}
}и возможность так делать зависит от версии babel/typescript, а не самого реакта.
const Demo = () => {
const handleSubmit = () => {
}
}
С хуками выглядит намного хуже — слой работы с событиями таким образом помещается в функцию рендеринга, раздувая ее. Также есть кейсы, когда это роляет на перфоманс, если не обернуть в useCallback. Еще туда же хранилище пихают и асинхронные сайд-эффекты, получается лапша "все в одном".
Так что проще только на самый поверхностный взгляд, работать с этим впоследствии сложнее.
По моему, там нужен специальный proposal-dependеncy в package.json добавлять.
И мы почти полностью перешли на функциональные компоненты
К сожалению, не увидел ничего, кроме туториала.
Оставлю своё мнение.
После реакта я немного работал с vue, те же яйца, только в профиль.
Переход с одной стороны — легко: концептуально одно и то же.
А с другой — запоминаешь новые нюансы функционирования системы: темплейты, нейминг, vuex и т.д.
И, в итоге, всё сводится к личным предпочтениям разработчика, а не к каким-то объективным метрикам, влияющим на разработку.
Также важно отметить то, что в теге template должен быть 1 дочерний элементНе увидел, про какую версию vue.js говорится. В третьей версии можно создавать несколько корневых элементов. Хоть бы уточнили, что говорите именно о второй версии
Ну и конечно, лучше было готовить материал на основе самой свежей версии фреймворка.
Но в целом и так понятно, когда замечаешь в шаблоне использование фильтров, убранных из 3й версииНикак не возражаю. Просто во фронтенде я чуть больше чем нуль. Временами работаю на фронте и также изучаю технологии во фронтенде, просто потому что «а почему бы и нет». Но я не занимаюсь разработкой на фронте, только что-то по мелочи исключительно для себя. Но даже я хоть какую-то теорию по новым фичам vue знаю. Статью написал, как я понял, разработчик react. И это странно (ИМХО), что он не интересуется «соседними» либами/фреймворками. Я сам PHP-разработчик, но активно слежу за node.js, django/flask, немного интересуюсь .Net (знаю основы c#, но бэкенд на нем не делал, но все равно интересно, что там происходит, что добавляют) и т.д. Наверно, слишком много воды сейчас написал. Проще говоря, автор сам frontend-разработчик на react, но, видимо, вообще не интересуется, что творится по соседству
React — это мощный и замечательный инструмент, однако вы вряд ли сможете найти хотя бы 2 одинаково структурированных проекта на этом фреймворке. [...]
Наш сегодняшний герой позволит вам не допускать путаниц и каких-то проблем с тем, когда вы, например, садитесь на новый проект.
Стандартный стек из коробки это, конечно, хорошо, но задача "быстро найти файл, который отвечает за эту кнопку" нормально не решается ни там, ни там
С этой задачей справляются CSS Modules с именованием классов [folderName]_[className]. В веб-инспекторе видишь class="FormCreateUser_submitButton", за 1 поиск по проекту находишь файл FormCreateUser.scss либо FormCreateUser.tsx, в зависимости от того, что нужно поправить, и 1 поиск по файлу для телепортации в нужное место. Все остальные способы (девтулзы, поиск по тексту), кроме поиска по уникальному id (если есть система автотестов, опирающихся на них, то они будут), намного длиннее и сложнее.
В chrome dev tools есть react Dev tools. С помощью немного можно мышцы тыкнув на кнопку узнать всю родительскую иерархию, что за пару секунд позволит узнать какой файл за это отвечает
<еslint>computed пишется перед watch</еslint>
Vue3 написан на тайпскрипте что означает полную его поддержку.
Приложения на Vue3 можно писать с использованием более продвинутого синтаксиса — с использованием Composion Api (идея которого была появилась после релиза реакт хуков). После Vue2 я стал страстным поклонником этого подхода.
Минута пиара: помимо нпм загрузок есть куча других статистик по которым можно наглядно сравнивать библиотеки друг с другом — на моем проекте Moiva.io так например выглядит статистика по популярным фреймворкам moiva.io/?compare=@angular/core+react+svelte+vue
Впечатления о Vue.js после React