Add the ability to navigate to a download or form submission

[domenic]

In offline discussion, @annevk mentioned that, in the spirit of navigation.navigate() being "a better location.assign()", maybe it should also get the ability to initiate a download or form submission. E.g.

navigation.navigate(url, { download: true });
navigation.navigate(url, { formData });

It seems likely that these capabilities can already be done today, by constructing the appropriate <a> and click()ing it, or the appropriate <form> and submit()ing it. So adding them here would not be costly. However, we'd want to double-check; e.g. I think there might be a user activation requirement for downloads?

[Yay295]

This seems to be getting out of the scope of an App History API and moving towards a Navigation API.

[domenic]

History and navigation are very intertwined, so I don't think it's fruitful to draw a distinction based on the fairly-arbitrary name chosen for the top-level global.

[frehner]

Could appHistory potentially make working with download links that need authentication (such as an auth header) easier? (e.g. a CSV report that requires auth)

Currently a click on an <a> doesn't add those things, so developers usually have to use JS to fetch the link instead.

Would that be considered part of this, or out of scope?

[domenic]

Hmm, interesting. It's possible, but it seems a bit unlikely, as we don't allow (and don't want to allow) adding arbitary headers to navigations in general, and special-casing downloads seems like it goes against the grain of this issue.

[frehner]

Hmm, interesting. It's possible, but it seems a bit unlikely, as we don't allow (and don't want to allow) adding arbitary headers to navigations in general, and special-casing downloads seems like it goes against the grain of this issue.

Makes sense. In a way, you could still probably have an easier time of it by just utilizing the navigate event with respondWith() ?

appHistory.onnavigate = (evt) => {
  if(evt.canRespond && evt.target.nodeName === 'A' && evt.target.getAttribute('download') === 'true') {
    evt.respondWith(fetch(evt.target.url, headers)) // and so on
  }
}

or something.

So adding a similar-type ability to push() to indicate a download would probably make sense too?

[domenic]

Other things which <a> can do which appHistory.navigate() cannot:

• Hyperlink auditing, i.e. ping=""
• Set the referrer policy
• Set the window target/open a new window (I'd much rather leave this off though)

[Yay295]

• Hyperlink auditing, i.e. ping=""

Seems to me like you could just use a fetch() for this if you want it.

fetch(url, {method: 'POST', body: 'PING'});

Having a way to do this built in to appHistory.navigate() could be convenient, but it's not difficult to do manually either and I think it could be added on in the future without conflict if there's enough demand.

• Set the referrer policy

This would probably be good to have.

• Set the window target/open a new window (I'd much rather leave this off though)

The current documentation says that appHistory.navigate() is similar to location.assign() and location.replace(), and they don't support setting the target either, so I don't think it will be missed. Again though since appHistory.navigate() takes an object as its second argument, this could be added in the future without conflict.