-
Notifications
You must be signed in to change notification settings - Fork 327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-trigger hash routing #769
Comments
Our front-end implementation is based on the browser's hashchange event. If there is no change in the hash, the change event is not triggered, by definition. Lines 118 to 128 in d1980bb
We could change the front-end implementation to force-trigger the event regardless of whether it has changed, but this could break existing apps which rely on the current behavior and whose hash routing handlers are not idempotent. In this case, it seems to me like the correct way to implement flow is: when the user "operates on the new page", it should cause hash changes to something other than For example (changes in bold):
@mturoci What do you think? |
Changing hash to I have recently faced similar problem in h2oai/wave-apps#57. The problem there is that hash = q.args['#']
if hash == 'page1':
render_page1()
else:
render_homepage() If you, however, perform some actions on
If we could split this into 2 separate variables (current_hash and hash_clicked), it could give the best DX. I am aware this would be a major breaking change though. Note: I came up with storing the current hash myself into It would also resolve this issue since you would get the |
@mturoci Thanks for the detailed explanation. So, the problem is that " If so, the fix can be "always set This will mirror the state of the browser's hash in q.args, making the @psinger I understand your problem much better now :) |
@lo5 correct |
Is this something that is planned to be implemented on Wave side, or something that is doable on app development side? |
I would also prefer always setting |
@psinger This is something that needs to be implemented on Wave side. |
@mturoci alright great, hope this will be added |
@lo5 thanks for implementing I just have two follow-up questions: I understand that The second question is, if there is some way to flag whether a navigation button has been actively clicked, otherwise it is hard to escape the generic if sequence of:
Edit: |
I checked this as well yesterday and I can confirm that re-triggering isn't working as expected |
The issue title is misleading. The fix does not re-trigger links (see explanation: #769 (comment)). Instead, the fix sets Regardless, @psinger @AakashKumarNain, help me understand what's the need for the browser to trigger the app twice when clicking on the same link twice in succession. If that's the behavior you need, then the command should be using plain names ( Additonally, from v0.17+ if you need to detect changes to the '#' link, for whatever reason, you can do something like this: is_hash_changed = q.client.hash != q.args['#']
q.client.hash = q.args['#'] |
The use case is exactly how I described above. If you perform any other action on a page (non navigation) that leads you to a different part of the app, you might want to go back, and the natural thing to do is to click on the same navigation button again. But the hash never changed, because you did not perform navigation before, and apparently the navigation does not re-trigger in that case. Regarding your suggestion with detecting changes in hash: this also only works if the hash actually changed, not when the user re-clicked the same navigation button (which currently does not trigger though). |
To elaborate a bit more, I would give you an example. Let's say you are on a page, say
At every state, we can provide an option to Neither it is natural nor it is user friendly IMHO. More natural is to click the same tab so that you come back to the vey first state with that click |
Currently, whenever a user clicks twice on the same hash routing navigation, nothing happens the second time.
For example, following scenario:
#routing1
In simple terms, I would like to always trigger the hash routing, even if the same hash item is currently active.
The text was updated successfully, but these errors were encountered: