I’m new to Browser.application; feeling my way around routing.
And tearing my hair out trying to implement what, on the face of it, is a simple task:
Each page will have its own help view, such that by tapping the help button, the help view is displayed in place of the usual page view. Tap help again, and the usual view is restored.
One complication is that I need to capture the viewport size (into a dictionary) each time the view changes so that I can restore the help page to it’s original position for those occasions when the user is jumping back-and-forth between the normal view and the help view.
I started off trying to implement it with: /some/page ↔ /some/page/help
but ran into complications.
So then I’ve tried: /some/page ↔ /some/page?help=true
but this is also far more difficult to implement than it should be.
In the second case, the problem appears to be caused by the ‘gap’ between UrlRequest and UrlChange: the function that toggles the route of the help button is executing after UrlRequest but before UrlChange, so it’s operating on a stale value of model.url. The result is that I can get to the help page, but not back from it.
My third thought is to have a value in model such as showHelp : Bool.
And to reset it to False when the url changes.
Currently investigating…
My code is probably very buggy, so I’m not posting code here.
I simply have one question:
I like the idea of having the help state as a query param. To me it makes the URL read as /where/i/am and ?page=augments.
What difficulty are you having with this?
What is the ‘gap’ you’re referring to, between url request and change?
Regardless of how you address this in your URL, you’ll still have to store it in your Model somehow because your view is always a function from your Model to Html. How you do that may vary a little depending on whether this ‘help’ state is available everywhere or only on select pages.
Hi wolfadex. Thank you for your reply.
It could just be that my code it overly complex and buggy.
I have a toggle function that switches the help link between /some/page and /some/page?help=true.
When help is clicked the url is captured by UrlRequest
UrlRequest runs a command to get the viewport.
This is captured by StoreViewportThenPushUrl which then runs the command Nav.pushUrl model.key requestedUrlPathQuery.
Somewhere before the url is actually updated, the toggle function gets called, so it’s operating on an old value of the url. I haven’t got my head round it, but /some/page becomes /some/page?help=true at the start, so I can get to the help view. But then it gets stuck and doesn’t toggle back to /some/page.
If this makes any sense at all
Doubtless having to get and store the viewport in the middle doesn’t help.
I’m investigating my third option, showHelp : Bool… which doesn’t require all the complex manipulation of the path and query.
You could add a returnTo query param to your url so that your help page knows where to return to, maybe that would work for you.
What about using Browser.back? Will that not construct your previous url when the user toggles off your help page?
You could grab the current page where the click came from in your main update function when you respond to onUrlRequest. From there you could store a reference to it in your main model, or inject a reference to it into your help page so that it knows where to return to when the user toggles off the page.
I usually put help information into a modal if there’s a lot for the user to read, then its just a matter of showing and hiding the modal, the page the help relates to doesn’t go anywhere. If it’s just a small amount of ‘help’ then I might use a tooltip or put it inline depending on the page layout.
That was something I forgot to mention in the original post: whatever the solution, everyone reaches for the back button on Android mobile, so this must also remove the help page.
This therefore, I think, precludes the option of using a modal. I’d rather not dig into Javascript to somehow intercept the browsers back function and remove the modal instead of going back one in the url history.
Of course, this problem is also present in my showHelp : Bool idea
Maybe a combination of appending /help to the url and Browser.back — this first option should have been simple. Perhaps it was buggy.
Of course I might simply try making my app so intuitive that no help view is needed
You wouldn’t need to do any of that, it could work something like this:
The User clicks the help button which results in a change to the url so that it has a help=true query parameter.
Your router picks up the changed url, and tells your current page to show its help modal.
The User clicks the close button on the modal - which results in Browser.Navigation.pushUrl being called to reset the url to the current page without the query param.
Your router picks up the changed url and informs the current page to close the modal.
The above should interact with the Browsers back button fine.
User presses the Android back button (or uses swipe-to-go-back on iOS)
Outcomes to choose between:
User ends up back on page A
Help modal closes (sees page B again)
Scenario 2
User visits page A
User presses link to page B
User opens the help modal on page B
User presses an on-page button to close the help modal
User presses the Android back button (or uses swipe-to-go-back on iOS)
Outcomes to choose between:
Help modal shows again (on top of page B)
User ends up back on page A
Notes
If you choose:
The first outcome both times, you can simply do Browser.Navigation.pushUrl (or use <a> elements) all the time.
The second outcome both times, it’s kind of possible but tricky and requires trade-offs.
For the second outcome, do what Paul said, plus a tweak at step 3, for the click handler of the on-page modal close button:
if handWavySafeToUseBrowserBack then
Browser.Navigation.back key 1
else
-- or replaceUrl if it results in better tradeoff-UX
Browser.Navigation.pushUrl key url
How to implement handWavySafeToUseBrowserBack? You need to keep track of things in your Model. It is only safe to use Browser.Navigation.back if you know where the user came from and where they are. Remember that if you have a URL to the help modal (like /something/help or ?show=help) then it’s possible to reach that URL via Google, or even just refresh the page while on it. You probably don’t want the modal close button to take you back to Google, or do nothing.
That quickly gets very tricky and mind-bending but it is doable, although not perfectly. We do this at work for a long question flow with back and forward buttons at work (play with the form if you want.)
