Started discussion in https://github.com/elastic/kibana/pull/67259#issuecomment-747005155
@majagrubic :
When selecting the fullscreen option from the menu and clicking Back in the browser, I'm taken back to the Advanced Settings, ie. the last page I was on before Discover. I would expect this to take me back to Discover.
@chandlerprall
Would need to hook into the html5 history api for that. I don't know if that's functionality we'd want in EUI, though it seems like it so it would be consistent between all fullscreen grids.
so let's start to discuss
Just some 2 cents here in terms of UX. One of the deepest problems SPA's has is not utilizing the browser history enough. So I'm all for this, however you want to handle it technically, which most likely is not built into EUI but provides some sort of callback for applications to handle it.
To put in my two-penny worth, too, fullscreen of a datagrid is akin to a modal or, at a stretch, a flyout. If fullscreen were to be tracked in history, then I'd expect modals and flyouts to be, too. I think a feature like this has further implications than just datagrid
馃 This is interesting because I think I agree with both of you... So here's my rational:
Going to full-screen with datagrid (or anywhere else we allow it), I think, is not the same as semantically moving to another page. In this way, it shouldn't be in the browser history.
But, because it does obstruct the other page completely (as opposed to modals or flyouts) it's easy to forget how you got to where you are. I think there's a level of muscle memory in browsers of "if you got somewhere you don't want to be, hit 'back'". And if someone does that in a full-screen context, it will then drop them too far back.
So, though I think technically it's not what the back button is for, I think it ultimately does help the user if we did use it here. With back button support, the worst case for a user who was carefully following their browser history is that they have to click back an extra time. Without back button support, the worst case for a user who mistakenly thought they were on some new page, is losing state. Losing state seems like a much worse "worst case" than an extra button press.
I think whichever way we decide, it will certainly upset some folks. My strong _opinion_ is that back/forward should always be tied to URL changes representing the page's state. EUI should never modify or otherwise impact the URL or navigation actions as it is not our property. I think the best option is for datagrid to provide a callback for when fullscreen is entered/exited, and a way for the application to set it. This enables:
Exposing the fullscreen state + allowing an application to set it came up recently in an internal conversation which also included these same changes for a grid's density. This does not, however, solve uniformity between implementations.
Most helpful comment
I think whichever way we decide, it will certainly upset some folks. My strong _opinion_ is that back/forward should always be tied to URL changes representing the page's state. EUI should never modify or otherwise impact the URL or navigation actions as it is not our property. I think the best option is for datagrid to provide a callback for when fullscreen is entered/exited, and a way for the application to set it. This enables:
Exposing the fullscreen state + allowing an application to set it came up recently in an internal conversation which also included these same changes for a grid's density. This does not, however, solve uniformity between implementations.