Open ShahriarKh opened 6 months ago
That's a good catch and it makes sense that it shouldn't trigger on URL states like these. I have some ideas in mind I'll try out! ✌️
I've had a look at this behaviour and it is not trivial to prevent this - because it is correct behaviour (as you noted). The only thing I can think of at the moment is passing an ignorePaths
prop to HolyLoader with an array of paths to exclude.
It could look something like this (accepting regex):
<HolyLoader ignorePaths={[/^\/browse\?query=.*/, /\?terms/]} />
Which would then prevent triggering HolyLoader if the new URL matches any of the patterns in ignorePaths.
+1 to an ignore paths option since it gives a lot of flexibility
For us, an ignoreSearchParams
options would be sufficient (… and quite important too, if we want to stick with HolyLoader. current UX is quite weird).
It would be awesome if we had the option to exclude specific routes. For example, I do use url query params as the state of my search page:
site.com/search?term=something
and the progress bar is animated many times as the user types. The behavior is correct, because the url is changing (the value ofterm
= the value of search input where the user types), and I tried to fix it a bit by debouncing. However, I'd like to exclude this route from holy loader. (Other use cases are page filters and anything that uses "url-based" state management)In some cases, having the delay option (#2) might be better, but being able to completely exclude some routes or some params will make the library more awesome.