Firstly, thanks for the discussion yesterday:
How to handle outbound links in desktop PWA?
Ben Halpern ・ May 21 '19 ・ 1 min read
I took the feedback and made a couple PRs:
Add PWA target blank functionality #2921
What type of PR is this? (check all applicable)
- [ ] Refactor
- [x] Feature
- [ ] Bug Fix
- [ ] Documentation Update
target="_blank" to anchor tags if the page is being rendered by a desktop PWA. It seems like this is the appropriate functionality for a computer device, but touch screens should keep opening in the pseudobrowser.
Quick solution while we experiment with PWA functionality.
Now I'm curious about another PWA feature I haven't been able to track down.
We've implemented navigation buttons right into the DEV desktop PWA like such:
team pink mode 💕
They work easily enough using
window.history.back(); but right now, they have no "on/off" state because I'm not sure how to determine of a user "can go back or forward". I know that this is not available in the typical window API but given that we're responsible for the back button ourselves in PWA I was wondering if there is anything exposed that would help determine this?
Top comments (13)
you can attach custom object when calling history.pushState()
We solved it with storing 'depth' parameter. Each time user goes down we increase it by +1.
Then you can decide if the back button should be on/off with history.state.depth > 0
I'm not sure this feature would be really helpful since I'm using the PWA in my phone (Android) and I never feel the need to use the back button (and of course, same goes to the desktop website).
If I wanna go back I just press the DEV logo, and that's pretty convenient!
The great part about DEV is that it has a non-dense site map... just the home page which leads to different places (articles, settings, notifications, DMs).
Back button does work in Android PWA. Just a habit on Android to use back button lol, is a lot closer to my thumb than the dev button.
Maybe you are looking for
window.history.length? UPD: just double checked, it doesn't subtract the number when you use back button :/
Maybe there's a way to do some programming magic and get that to work?
Between that and other persistence like
localStorageetc, there is probably a technically possible way to make it happen. We only have to worry about on-site situations because this is for the standalone app.
This is a pretty generalizeable situation so if anyone wanted to build a library for this I'm all for it! 😄
There's a proposal to add field to the Web Manifest to hint that navigation should be shown that would work across devices. Here's a better thread. In the meantime, there is a CSS media query that you could use to determine when to show your navigation.
I might be mistaken, but it seems like
minimal-uimode doesn't work on the desktop. It looks like
standaloneno matter which I use.
Right now for this issue of deciding whether a user can go back, I essentially hide the back button when the current route is "/" (root)
As I'm assuming the user enters via the root route and then navs forwards, this seems to work.
I had also to add this type of navigation for a site that was used inside an iframe inside of a browser extension.
Check this example. I had to track navigation myself.
I have come a across this issue before in another project.
On document.referrer it holds the previous page, if it contains a URL with dev.to you can then use window.history.back() (other wise prevent it going back as to not leave the page/app unless required)
Thing I can't remember is, ain't there a history list API that returns back all the previous pages you were at?
I tried it like so. Seems to work.
Don't use standalone or fullscreen if you want navigation buttons.