suddjian opened a new issue #8655: [SIP-30] Remove Tabs in SQL Lab URL: https://github.com/apache/incubator-superset/issues/8655 ## [SIP-30] Remove Tabs in SQL Lab ### Motivation SQL Lab is devoting screen space to a custom tab UI that is less effective than that offered natively by the browser. Other upcoming features such as more powerful edit history/undo, and better navigation/discovery make tabs less important. The new design directions coming from the superset design group specify a tabless UI. Browser-based tabs would be a better solution for nearly every SQL Lab use case. ### Proposed Change - Remove the tab bar in SQL Lab - Include the id of the current `queryEditor` in the SQL Lab url: `myapp.com/superset/sqllab/42` - Links throughout Superset referencing SQL Lab queries should use urls with a `queryEditor` id - Implement a user-level flag to switch between the tabful and tabless UI - Stabilize backend-managed SQL Lab state, and make it the default option. This change can actually be made without significant changes to state management. SQL Lab state includes some number of `queryEditor`s ("tabs"). Instead of each `queryEditor` referencing an in-page tab, the SQL Lab url will contain the id of the `queryEditor` being used. This will depend on the [backend implementation of state management for SQL Lab](https://github.com/apache/incubator-superset/pull/8060) which is currently behind a feature flag. Without backend SQL Lab state, your local state would accumulate until there is too much to manage, without a practical way to clean it besides clearing your localStorage or editing it laboriously. One change that will be tricky is offering users a quality migration experience to the tabless UI. More details on that down the page. #### A note on preventing lost work in a tabless UI Nobody wants to write a query, then close their browser and lose it forever. Mitigating that in this new design will be important. The full UI/UX redesigns call for a robust history feature, but there are some things we can do to protect people's work without the history feature. When you navigate to SQL Lab without specifying an id in the URL, an id will be generated for you just as if you had clicked the "+ tab" button in the current UI. This will allow users to re-open a closed tab from the browser history, even if they didn't save the query. If a user wrote a query but didn't save it, and closes the browser tab, SQLLab should also warn and offer to save the query before the tab closes. If you run or save your query, those will also be ways to recover your work. Just for reference, here's the design we're working towards. This SIP is not about implementing everything on this screen, only replacing the in-page tabs with browser tabs. <img width="1360" alt="Screen Shot 2019-11-25 at 7 04 12 PM" src="https://user-images.githubusercontent.com/1858430/69596121-60293800-0fb6-11ea-9a8c-e231544eee78.png"> ### New or Changed Public Interfaces - "Run query in a new tab" button in the query history will open a new browser tab. - "Share query" should use the new url format, and should save the query if it hasn't been saved. - Links in the saved queries screen and query search should use the new url format. - Remove the ctrl-t keyboard shortcut? ### Migration Plan and Compatibility We should allow users to migrate to the new system at their own pace. Tabs are a heavily-used feature, and should not be ripped out without a proper transition phase to educate and re-orient users. A per-user feature flag will be added indicating whether they are using the tabful or tabless version of SQLLab. SQLLab will appear unchanged as long as a user's flag is off, with the exception of a small banner in the corner notifying the user of the new tabless experience, and allowing them to flip the flag on. Once they flip the flag SQLLab will change to the tabless UI. There should be an explanation of the change, with useful info on how to navigate this brave new world. After some time, we can turn this flag on by default for new users. Eventually when the tabless UI is deemed stable, people are happy with the change, and we've made sure that there isn't a negative impact to existing user needs, we can switch everyone over. ### Rejected Alternatives - Keeping in-page tabs - too cumbersome to use, not as accessible, adds unnecessary state complexity - Switching over immediately to a tabless UI without a feature flag - too jarring to users, want to give them the opportunity to change to the new system when it's convenient for them. - Developing the new SQL Lab designs in a separate screen alongside the original SQL Lab - too much code complexity and chance of breaking changes, not enough opportunity to reuse existing components. - Re-organizing SQL Lab frontend state around a tabless UI - too much work for now, and breaks compatibility between the new and old version of the page. It will likely make sense to re-organize state in a future release once all users have migrated to the tabless UI.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
