Gozala
commented
9 years ago The larger issue we've being discussing is that history graph is maintained by the web view and is kind of hidden away. Unsurprisingly history graph is also linear given that's how today browsers present a history graph. It is unfortunate as it makes it difficult to do things differently like present sessions in non linear graph think of something like vim gundo
As a matter of fact this is the root of the issue that I think influences an API making it imperative instead of declarative. I would suggest to change API to make it more declarative and get rid of imperative knobs like goBack / goForward / reload etc.. All of that maybe expressed via src change assuming that user keeps the navigation history. Although if you do it right now you won't restore page from cache but would load it over. It would be great if API was adjusted to make it src based and have maybe an additional attribute cache or something along that line to allow restoring from cache vs reloading it. That attribute may also be used to enable / disable caching of the documents.
This is based on some conversations we had in browse.html
canGoBack()andcanGoForward()return booleans or promises as they do in mozbrowser. Promises make this API less ergonomic and are more prone to race conditions. Basically now we requestcanGoBack()andcanGoForward()on location change in order to update the rendered UI and later on we get results. It would make a lot more sense to include those values along with location change event and actually make webView maintain the state of those values for user instead. Also as far as I can tell atom-shell's web view does return boolean instead of promise for it: https://github.com/atom/atom-shell/blob/master/docs/api/web-view-tag.md#webviewcangoback I personally think those should be just getters + attributes that get updated when state changes.