Comments 43
Естественно, плохо писать можно на любом языке и применяя какой угодно фреймворк. Но касательно данной статьи, накосячить в React гораздо проще.
И таких приколов масса.
Самый лютый: приложение (на Vuex) в какой-то момент вообще просто перестает работать и выдается какая-то ошибка странная (забыл уже конкретно какая). Эта ошибка не гуглится и не исправляется вообще никак. Но если удалить node_modules и переставить заново, то все работает.
Что остальное хорошо?
С другими технологиями баги если и были, то всегда причина была в том где-то я что-то не понимал и делал не так. А тут именно во фреймворке дело.
На чём ещё писали, просто интересно.
Реакт, нокаут, бэкбон.
Вы просто первый встретившийся мне пока человек с такой ситуацией.
Из скольки?
Эта ошибка не гуглится и не исправляется вообще никак. Но если удалить node_modules и переставить заново, то все работает
Это рецепт решения многих проблем в js/ts мире. Я вот давеча наткнулся на то, что npm устанавливал кое-какой пакет версии 2.14 вместе требуемой 3.15 без каких-либо на то вменяемых причин. И это ломало типизацию. TS просто превратил все связанные через пятое колено типы в any и у меня по всему приложению any расползлось как вирус (несмотря на strict: all). Было очень странно в итоге выяснить, что дело в каком-то баге резолва зависимостей npm.
И я не один такой. У всех двух моих коллег эта же ситуация повторялась.
Это точно не конфликт версий
Но если удалить node_modules и переставить заново, то все работает.
Исходя из чего вы делаете вывод, что это не конфликт версий, если переустановка node_modules что-либо меняет? У вас вариантов то всего остаётся:
- конфликт версий (подверсий, подподверсий, ...)
- баг компилятора\транспилятора\чегоугодноатора
- и то и другое
Не очень понимаю причём тут вообще Vue. Во Vue встроен полтергейст?
Исходя из чего вы делаете вывод, что это не конфликт версий, если переустановка node_modules что-либо меняет?
Если бы это был конфликт версий, то
1. Появление ошибки было бы связано с управлением зависимостями. А оно не было связано. Никто никаких новых модулей не ставил, не удалял, вообще не трогал ничего, связанного с модулями. И файлы вне рабочей области не трогал.
2. Простая переустановка модулей ничего бы не чинила. Поскольку их никто не трогал, то ставятся ровно те же модули, который и были до этого. А поскольку ошибка была очень устойчивой: проявлялась в течении всего проекта у всех фронтендеров, то это точно не конфликт версий.
Ну, слушайте. Будь это баг платформы, это быстро бы появилось в ишуях платформы и не работало бы у всех. А я очень внимательно просмотрел актуальные баги на тот момент и не было ничего, что могло бы заафектить.
Так что единственный подозреваемый — фреймворк.
Во Vue встроен полтергейст?
Уж не знаю, полтергейст там или нет, но баги адовые — точно встроены.
Поскольку их никто не трогал, то ставятся ровно те же модули, который и были до этого.
Я полагаю ошибка тут. Как именно вы переустанавливали зависимости? Случаем не посредством npm install. Если да, то вы ошибаетесь и зависимости установятся не те же самые.
Будь это баг платформы, это быстро бы появилось в ишуях платформы и не работало бы у всех.
Неа. Не у всех. Если баг мутный то для его воспроизведения нужно чтобы совпало очень много факторов — конкретная комбинация конкретных пакетов и конкретная платформа. К сожалению даже в MacOS и Linux инструменты работают не полностью идентично. Это сильно усложняет разбор полётов.
package-lock.json. А значит, ставятся ровно те же самые версии.Кроме того, вы не внимательно читали. Смотрите.
0. Никто зависимости не трогает.
1. Возникает ошибка.
2. Ее чинят переустановкой зависимостей.
3. Через какое-то время снова возникает ошибка. И опять зависимости никто не трогал.
Не у всех. Если баг мутный то для его воспроизведения нужно чтобы совпало очень много факторов — конкретная комбинация конкретных пакетов и конкретная платформа.
У ноды/бабеля миллионы пользователей. Это очень популярное ПО. Если не было заведено ошибки, очень вероятно, что ее не было.
В общем, я вам точно говорю. Три человека над ней билось несколько дней. Это проблема фреймворка.
Я пожалуй задам ещё раз свой вопрос. Как именно вы переустанавливаете зависимости? Посредством 'npm install'? Несмотря на локающиеся зависимости в package-lock.json они им, тем не менее, не используются. И он ставит другие зависимости. Вот если вы использовали npm ci, то это было бы уже интересно.
То что вы не трогали зависимости сами, никак не меняет суть дела. Их не обязательно трогать чтобы получить проблемы.
У ноды/бабеля миллионы пользователей. Это очень популярное ПО. Если не было заведено ошибки, очень вероятно, что ее не было.
У npm бесчисленное количество глупых багов. И они годами не чинятся. Я уже даже перестал подписываться на них на гитхабе. Это ОЧЕНЬ проблемный инструмент. Вероятно, что ваша проблема там имеет не 1 ишью, а сразу штук 5 :)
Три человека над ней билось несколько дней
Вот адресуйте мой вопрос выше всем троим. Возможно вы удивитесь.
И пожалуй добавлю откуда у вас столько минусов выше. Вы обвиняете библиотеку в том, что она является источником багов, которые лечатся её переустановкой. Библиотеки. Переустановкой. Вы понимаете насколько забавно это звучит? Кусок кода глючит со временем, но когда вы его накатываете (по вашим словам) абсолютно тем же куском кода, то он не глючит. Шта? Я вам гарантирую что у вас что-то отличается в этих двух случаях. Либо какие-нибудь кеши в node_modules/.cache, либо зависимости ставятся другие (хоть вы и считаете, что те же самые), либо какие-нибудь хитрости с npm link, ручными симлинками, сайд эффектами на post install каких-нибудь пакетов (которые могут к примеру иметь какие-нибудь свои кеши).
Наткнувшись на такую проблему в будущем возмите md5 от "до" и от "после". Они либо у вас не сойдутся, либо проблема переустановкой не лечится.
Т.е. вероятность того что исполняемая часть Vue является источником проблемы и содержит "адовые баги" скорее наименее вероятный сценарий. Но вы это заявляете весьма уверенно :)
Да, очевидно, что это какая то беда не буквально с самой библиотекой, а со всей экосистемой, ассоциированной с ней.
Но в данном случае это роли не играет. Программист ведь выбирает не одну или две библиотеки, а всю экосистему — кучу библиотек и их зависимостей. И если косяк где-то в глубине — это бросает тень на всю экосистему.
Ни в нокауте, ни в реакте, ни в бэкбоне таких адских проблем, как со вью у меня не было.
Есть ощущение, что статья либо старая, либо автор не в теме вообще. Про попытку сравнения библиотеки и фреймворка я вообще молчу и игнор многих ключевых преимуществ того и того подхода. Но во вью нет cli, шта?
Холивары, что считать фреймворком, что библиотекой — вечны. Де-факто, React — целая огромная экосистема с кучей своих инструментов вокруг центральной библиотеки. В материале автор попытался сделать достаточно широкое сравнение и ответить на вопрос об использовании того или иного набора: React или Vue.
Автор, судя по биографии, разбирается во Vue весьма неплохо:
I'm a Vue Community Partner, curator of the weekly Vue.js Developers Newsletter, and the founder of vuejsdevelopers.com, an online community for web professionals who love Vue.js
Если переменная message прокидывается дальше как свойство (prop) в дочерние компоненты, то библиотека об этом помнит, и дочерние компоненты также будут автоматически перерисованы. Именно поэтому в библиотеке Vue нет нужды в методе жизненного цикла, аналогичном реактовскому shouldComponentUpdate.Вы не поверите, но в Реакте всё то же самое, только можно выбирать между Stateless (перерисовывать при изменении пропсов) и Stateful (перерисовывать всегда), и к явному использованию shouldComponentUpdate это не имеет никакого отношения. Явно его переопределять нужно только для тонкой настройки того, когда нужно, а когда не нужно перерисовывать компонент, т.ч. причём тут автоматическая перерисовка детей — непонятно.
Например, хук created из примера выше запускается тогда, когда готово состояние (state) компонента, но до того, как компонент прикрепляется к странице. Аналог из мира React — getDerivedStateFromProps.
Но есть одна большая разница: в библиотеке Vue нет аналога реактовского shouldComponentUpdate. В этом нет необходимости ввиду наличия в Vue системы реактивности.
Здесь неточности. Конструктор в React (ранее — componentWillMount) — это aналог created, выполняется для инстанса единожды. А getDerivedStateFromProps выполняется многократно, ближайший аналог в Vue — watch, также может быть не нужен из-за реактивности.
Для изменения состояния в Vue вам не нужно вызывать отдельный метод this.setState, как это делается в React. Вы просто пишете изменения напрямую:
// React
this.setState({ message: 'Hello World' });
// Vue
this.message = 'Hello World';
во VueJS так делать нельзя. Изменять состояние нужно вот так:
Vue.set(this, 'message', 'Hello World')иначе будут проблемы с реактивностью
во VueJS так делать нельзя.
Можно и нужно.
Если в секции data компонента объявлена переменная message:
data() {
return {
message = '',
}
}
то
this.message = 'Hello World'; будет работать.
Vue не может обнаружить добавление или удаление свойства. Так как Vue добавляет геттер/сеттер на этапе инициализации экземпляра, свойство должно присутствовать в объекте data для того чтобы Vue преобразован его и сделал реактивным.
О чём я и написал выше. И это стандартный способ работы с реактивными свойствами во Vue.
Ваш же комментарий — это к случаю:
Во Vue нельзя динамически добавлять новые корневые реактивные свойства в уже существующий экземпляр. Тем не менее, можно добавить реактивное свойство во вложенные объекты, используя метод Vue.set(object, propertyName, value)
в документации говорится обратное
Не говорится. Нет здесь никакой магии. Vue2 использует getter-ы и setter-ы. Это позволяет отлавливать и трекать все обращения в computed-контексте, и позволяет трекать все изменения. Но вот чего нельзя делать, так это пытаться присвоить значение туда, где ничего и не было. Потому что Vue2 заранее определяет какие поля будут observable, а какие нет. Во Vue3 будут Proxy, там можно будет даже это.
Скажите, а вы правда во всём своём коде пишете Vue.set? :-)
… Возможность писать в стиле jQuery, ну все перехожу.
— ошибка?
— ошибка.
Когда фронтенд-разработчику стоит перейти с React на Vue, а когда это усложнит разработку