тоже норм. но лучше гардом всё же)

Окей. Спасибо. А чем гард будет лучше?

В двух словах

в кратце ничем

но профит есть все же

1. ты не вешаешь лишний ватчер

2. ты можешь узнать откуда пришел и куда ушел

потому что вочерам не доверяют, плохое влияние ангуляра :)

как бы сказать, у тебя роут и так вызвает callback на каждый переход, поэтому лучше им воспользоваться, чем ватчить изменения роута

я ватчер предложил потому, что сам использовал его раньше постоянно для такой ситуации, а потом вспомнил про гуарды и начал на них переходить

Окей. Спасибо

гуарды - что за слово такое, что значит

типа что то кэлбэков

страж

по идеи

я ватчер предложил потому, что сам использовал его раньше постоянно для такой ситуации, а потом вспомнил про гуарды и начал на них переходить

ну раньше иначе особо и нельзя было. beforeRouteUpdate ввели с 2.2. глянул, когда это было - год назад, однако. быстро время летит

ну раньше иначе особо и нельзя было. beforeRouteUpdate ввели с 2.2. глянул, когда это было - год назад, однако. быстро время летит

оул, точно, я же с 2.1 версии

по идеи

только не забудь next() в конце прожимать

я с 2,0 :)

ну я сделал уже

А разве scope стили не будут решать эту проблему? ты же про наименования классов?

Да про именования. Нет не решит

хм, забавно

попытался переписать в проекте на beforeRouteUpdate

и чето не зашло

и чето не зашло

что пошло не так?

ну сейчас у меня компонент ориентируется на пропсы

потому, что в роуте я сделал { props: true }

на этот пропс весит ватчер который делает запрос данных

и функции которые делали запрос, берут данные из this.props, а не через аргументы

и при попытки сделать запрос в beforeRouteUpdate, я получаю старые данные, так как пропс еще не обновился

а это значти, мне надо переписать функцию по запросу данных, чтоб она работала с аргументами

а функция, это метод в этом же компоненте?

да

beforeRouteUpdate (to, from, next) { this.myMethod(to.propName); } не вариант?

ведь этот метод никто, кроме гарда не вызовет, наверняка

не, эта функция как раз без аргументов работала, а сама доставала нужное из this

я решил вопрос просто

myMethod(props = this.props) {}

у меня просто метод вызывается еще же в created

можно вместо created, заюзать beforeRouteCreate, но тогда ux поменяется.

этот компонент по сути является вьюхой? в том смысле, что заточен на роутер?

да

это страница

там ещё beforeRouteEnter есть. Может он вместо created сгодится. но у него свои заморочки с this)

ну тебе наверняка виднее, как там лучше

там ещё beforeRouteEnter есть. Может он вместо created сгодится. но у него свои заморочки с this)

у него нет же this

есть, но через next()

но ux все равно поменяется

мне нравится когда сначала произошел переход, а потом запрос данных, а не запрос данных, а потом переход

а я как раз наоборот сейчас впиливаю. сперва запрос, потом переход

в том числе из-за code splitting. при переходе ещё и сам async компонент тянется

в том числе из-за code splitting. при переходе ещё и сам async компонент тянется

я в одном проекте просто сделал глобальный лоадер

для async компонентов

типо если переход задерживается на 100 мс, то я открываю лоадер и по beforeEnd (или как там) закрываю лоадер

но так как у меня в самом компоненте свой лоадер, то переход между лоадерами не заметин)

beforeResolve, скорее всего

не, beforeEach и afterEach заюзал

вот да. сижу обдумываю. дважды лоадер в голову лезет. смущает внутреннего перфекицониста

ладно, спасибо за беседу. пойду кодить)

давай

Друзья, как реализовать такую простую вещь: есть компонент, который принимает значальные значения. потом их пользовательн может поменять и по этом упризнаку внутри компонента флаг changed определяется в true, потом если пользователь сохранил значение - я вызываю с родительского компонента update и мне нужно сбросить changed на false где правильно это сделать? updated: function().. не подходит потому что он фаирится когда пользователь меняет значение руками, mounted - не подходит потому что один раз только вызывается.. какой патерн?

watch: { prop() {} }

watch: { prop() {} }

оо, а чо так можно было? Уотчить можно еще и пропсы?

Смотря что вы передаете в пропсы, если объект, то можно

вот тут как раз делаю watch

и первая часть работает

а разве просы можно биндить?

но когда делается update объекта - перезагрузка с сервера, то changed остается в true

Смотря что вы передаете в пропсы, если объект, то можно

Если при передаче вы его не клоните с Object.assign

а мне нужно его ставить в false

Можно v-model указать пропс?

где это првильно делать?

но когда делается update объекта - перезагрузка с сервера, то changed остается в true

После перезагрузки сами меняйте на false

После перезагрузки сами меняйте на false

вот, как отловить внутри компонента ивент "обновился" ?

Если пропсы можно уотчить, то в теле уотчера я бы сделал копирование из пропсов в дата. Ну и каждый раз какой нибудь рандом-ид передавать, чтобы изменялось адекватно

но обновился объект только от родитлся

но обновился объект только от родитлся

если уотч работает и с пропсами, то в теле уотчера

но обновился объект только от родитлся

Пропс не прописывайте на прямую, а делайте через computed

Пропс не прописывайте на прямую, а делайте через computed

а чего?