>= 1.0-rc0
https://glitch.com/edit/#!/nuxt-rc0
https://nuxt-rc0.glitch.me/
https://nuxt-rc0.glitch.me/about
Load the page above, and start typing into the search field. The input element is set to trigger an update of the query string on keypress.
You should be able to continue typing after the first character, and the query string url should continue updating with what you type.
After every keypress, the form field loses focus and you have to click inside again to be able to type the next character.
Additionally, if the typing is done on the about page in the above demo, then it also scrolls to the top of the page after each keypress, despite the custom scroll Behaviour disabling that.
I noticed this change in behavior when I upgraded from 1.0.0-alpha.4 to 1.0.0-rc3, but after checking the previous versions it seems to have started in 1.0.0-rc0.
Links to a glitch to see a working previous version
https://glitch.com/edit/#!/nuxt-alpha4
https://nuxt-alpha4.glitch.me/
https://nuxt-alpha4.glitch.me/about
To rule out changes upstream in vue router causing this, I created a jsfiddle using version 2.7.0 of vue-router (same as nuxt 1.0.0-rc3 uses). The behaviour does not exist in that test:
https://jsfiddle.net/benosman/octu95ra/
Note: This issue has been rewritten, hopefully to make it clearer to understand what the problem is.
Any ideas on where the cause of this is likely to be - i've checked the commit list between the two versions but there is quite a lot to look at.
I checked it out. The Component re-renders after adding a search query to the url. I don't really know why that happens but i know it's not from vue-router :sweat_smile:
Thanks for checking it out, I did wonder if they were getting re-rendered, and was going to test that out.
Although i'm not using 'hash' based routing - I wonder if it's related to this issue:
Just tested with rc4 and issue still present
https://glitch.com/edit/#!/nuxt-rc4
https://nuxt-rc4.glitch.me/
https://nuxt-rc4.glitch.me/about
Verified that this bug is not present in 1.0.0-alpha.4.
Just tested with rc8 and issue still present
This is a major issue for my project and means I have to stay on alpha4.
But, it also seems like a major bug as it is impossible to use the router without the full page refreshing.
@Atinux @pi0 - could you confirm if you think this is a bug, and if you have any ideas on it?
Tested once again with rc11, and the issue is still present:
https://glitch.com/edit/#!/nuxt-rc11
https://nuxt-rc11.glitch.me/
https://nuxt-rc11.glitch.me/about
Hi @benosman
Here is a working version: https://glitch.com/edit/#!/polite-transport?path=components/search.vue:23:3
Demo: https://polite-transport.glitch.me/
Actually when changing the route, Nuxt.js call directly asyncData and data for you, but the component are re-mounted, so you can add the focus on the mounted
hook :)
@Atinux
Thanks for the work around, but there is quite a screen flicker when using this, because the components do seem to be recreated, which didn't use to be the case.
Also I have multiple components (search filters) so it may be quite fiddly to get the focus to work on all of them like this.
I believe that you should add a throttle before changing the url to wait for the user to stop typing, see https://css-tricks.com/debouncing-throttling-explained-examples/
@Atinux - yes, I do use debouncing on the app itself - but still there will be a flicker after the period is up.
I really think this is a bug, certainly a big behaviour change introduced after alpha 4, that doesn't exist when using vanilla vuejs/vue-router. It seems inefficient to rebuild the components when the page is the same.
I haven't had the chance yet due to other commitments - but I intend to go through commit by commit to see where exactly the behaviour changed.
I finally got the chance to look into this, commit by commit :flushed:
The change in behaviour was introduced with the nuxtChildKey
attribute implementation in pull request #1022.
The reason is that the key is determined by the full router path with just the hash fragment removed. So, in my case every query string change updates the key.
It would be good if nuxt.config had an option to choose how to determine the key, but in any case it is now straight forward to override the key using a custom layout:
<template>
<nuxt :nuxtChildKey="routerViewKey"/>
</template>
<script>
export default {
computed: {
routerViewKey () {
// If current route has no children, set view key, otherwise pass.
if (this.$route.matched.length <= 1) {
return this.$route.fullPath.split(/[?|#]/)[0]
}
}
},
}
</script>
@benosman I faced the same problem when trying to store some information in the query string.
I tried your :nuxtChildKey="routerViewKey"
computed property, but the page transition still occurs... 馃槩
I can't find any way to stop the page from reloading, did your method worked for you?
The method to update query string:
this.$router.replace({
query: { open: val }
})
and the default layout:
<div>
<MyHeader />
<nuxt :nuxtChildKey="routerViewKey" />
<MyFooter />
</div>
@DaxChen - hmm, you are right, it does seem to have regressed for me too. I will investigate this again and post back with my findings.
@Atinux Can you point us a direction so we can find a proper workaround that can really prevent the re-rendering?
Because I want to sync state to the query string in a two-way manner, and using the example you provided will cause Velocity animations to fire multiple times.
@DaxChen - It does seem like @Atinux is working on this area
See this commit (currently unreleased):
https://github.com/nuxt/nuxt.js/commit/e80a77782af1369923617cd4c70d7ea3f8d872b5
That may make this workaround unnecessary as he is using the path property rather than fullPath, and it also looks configurable.
@DaxChen - It turned out the regression I was having was unrelated to this workaround. (The cause was my input control had a wrapper div with a v-if surrounding which was being set to true too late, therefore was being rebuilt)
Going back to my simple test showed it to be working just fine. What's more, the changes in the upcoming nuxt release should remove the need for the workaround.
I've updated my workaround to incorporate the recent changes mentioned above, you can try this but most likely won't change the behaviour from the previous one.
I have created a working glitch, which has console output on navigation to show what is happening
https://nuxt-key.glitch.me/
If you are still having issues, try remixing this glitch and try to reproduce your issue
https://glitch.com/edit/#!/nuxt-key
<template>
<nuxt :nuxtChildKey="routerViewKey"/>
</template>
<script>
export default {
computed: {
routerViewKey () {
if (this.$route.matched.length <= 1) {
const Component = this.$route.matched[0].components.default
if (Component && Component.options && Component.options.key) {
return (typeof Component.options.key === 'function' ? Component.options.key(this.$route) : Component.options.key)
}
return this.$route.path
}
}
},
}
</script>
@benosman and @Atinux
I've finally made the Accordion
component with Velocity
animation I was talking about on to glitch for this problem reproduction.
source: https://glitch.com/edit/#!/cliff-quail?path=pages/index.vue:93:6
demo: https://cliff-quail.glitch.me
I really appreciate all the time you put in.
Thank you so much again!
@DaxChen
I took a look at your reproduction, the issue seems to be the the inital values of open = false
in the data()
function. When you set the query string it navigates and runs the data function again and overrides the previous toggled value.
I've made a few changes to set those values correctly by default and also improve how the query string is set when open is 0 or null. (look for comments with // Change
)
https://glitch.com/edit/#!/abrasive-harp?path=pages/index.vue:46:4
OMG!!
Originally the questions
array was fetched/required in asyncData
, where this.selected
is not available, and on the other hand, questions
array is also not available in data
, so I tried all kinds of ways, like updated
hook or various watchers, but nothing worked. I'll have to find a way to move them to a place where both are available.
Thank you so much @benosman!!!
But BTW, as you mentioned, I also noticed that the data
function (along with asyncData
too) reruns every time query string changes, is this the expected behavior (even if using the same new key
property)?
@DaxChen - glad I could be of some help :)
Yes, this is expected behaviour, even with the new key property.
Since you use this.$router.replace()
to set the query string, this does trigger a page navigation along with all the relevant lifecycle hooks. The routerViewKey avoids recreating and rerendering all components on the page during a transition.
For your use case, you might find it easier to use javascript's history.replaceState()
or history.pushState()
functions which will avoid all those hooks.
Alternatively, you could use the store to populate the data on first load, then on subsequent toggles you could check the store for the data.
Actually, with next release, we won't watch for query changes to call asyncData
anymore, you will have to watch it manually or use wathQuery
:)
@Atinux
Do whe know when the next release is coming out? (atleast approximately)
Hey guys, is this watchQuery
and key
documented somewhere?
@SinisaG not yet but we have an example to show you how it works: https://github.com/nuxt/nuxt.js/blob/3235b037a075c4927c56c8891d7d80c2a4fe54d7/examples/routes-transitions/pages/users.vue#L22
@Atinux is it possible to watch any query change with watchQuery? Because I have bunch of dynamic parameters in my store catalog.
Use watchQuery: true
@vanpav
huh that was a breaking change in my case for my paginations, took me some time to spot this issue 馃槄
( "page" query param in url )
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
Actually, with next release, we won't watch for query changes to call
asyncData
anymore, you will have to watch it manually or usewathQuery
:)