Menu for hiding and showing columns

[chriddyp]

• Ability to add / remove columns from a predefined list of columns using a contextual menu.
• All columns would appear in this contextual menu as a checklist
• The visible columns would be “checked” and the hidden columns would be “unchecked”
• The user could click on an icon in the header to display the menu
• This feature would be toggled on/off with a top-level table property
• These settings would be “save-able” in the user’s browser session. So, if a user selected a series of columns, they could “save” these options (to the browser’s localstorage) and when they re-visit the app, the same set of columns would be displayed.
• This would only work on the user’s browser. It would not work across computers.
• This would use localstorage to save data
• This menu would be “global” for the table. It would not be displayed on a per-column basis.

The UI for this (and the other features) will be considered in a separate issue

[Marc-Andre-Rivet]

Use local storage and revert to cookies if local storage is not available (the browser's configuration needs to be tested as some browsers / settings will mark the feature as available but allow 0 bytes to be saved). Session storage is useless here as it is not persisted between visits.

Determine initialization model for table: Gets loaded with XYZ values for columns -- when and how does the stored value kick in, when is it applied / ignored. Or, is hidden really part of the table's column API or just something derived from other settings like filtering, sorting, pagination influencing derived_**_data.

Storage must support multiple tables for a given path (use id) -- generated id might be problematic for unnamed tables.

Implement internally as a standalone component for isolation and future flexibility.

Use generic icon from some package (e.g. font-awesome -- in this specific case explicit es6 pruning the font library is a must -- one-on-one basis for other packages) or do we have a in-house icon source.

All in all, probably ~1 week of work here to build the UI, answer these questions to some satisfaction and test.

[Marc-Andre-Rivet]

With Dash 1.0 removing column.hidden, need to make sure hidden columns are taken into consideration on export (#313) -- will require its own additional test.

[vivekvs1]

With the "hidden" option removed in DASH 1.0, is there a temporary alternative method to achieve the same? Now my app breaks and I am unable to use it anymore.

[alexcjohnson]

@vivekvs1 you can put extra fields in data that have no counterpart in columns - ie any column that you previously marked hidden, just remove it. Does that cover your use case?

[vivekvs1]

I used toggle switches to show and hide sets of columns. So i initialized them with 'hidden':'False' and changed some of them to 'hidden':True though a callback, based on which toggle switch was triggered.

[notatallshaw]

Feel free to delete this comment if it ends up littering this issue thread but I would like to make it clear the hidden feature on Dash Table 3.7.0 is used by all my important projects.

This wasn't some obscure feature hardly used, it's heavily relied on and stops upgrading of most of my projects. Which either use it to sort data not visible to the user (e.g. a status with visible colours but a hidden "serverity" columns to show the red colours at the top) or for users to hide or show columns themselves a configuration UI that I developed.

you can put extra fields in data that have no counterpart in columns - ie any column that you previously marked hidden, just remove it. Does that cover your use case?

FYI this doesn't cover my use cases as if the column is removed I can't sort by it, which is a feature that I rely on on use case 1 and a feature I offer to the user in use case 2.

[alexcjohnson]

@notatallshaw I apologize for the disruption. It was important for us to get hidden out of columns so it could be modified without having to edit the whole columns object. And since it's a breaking change this had to happen in 1.0, but unfortunately its replacement wasn't ready in time.

This is one of our top priority features for table 4.1 / dash 1.1, so hang tight and you'll be able to upgrade as soon as we get the next release out.

[notatallshaw]

This is one of our top priority features for table 4.1 / dash 1.1, so hang tight and you'll be able to upgrade as soon as we get the next release out.

Thanks! Please be aware I'm very greatful for all your efforts as I don't pay for your team's great work on this library.

When I am using obscure features and they break I mostly find workarounds, I just wanted help by pointing out as far as I'm aware this is actually a commonly used feature.

[chriddyp]

This menu would be “global” for the table. It would not be displayed on a per-column basis.

For now, maybe let's defer the global UI work and make this a per-column UI. Originally I thought this needed to be a "global" UI because I thought that the columns would be completely hidden, meaning that there wouldn't be any way to "un-hide" the column unless the UI was elsewhere.

But, if we partially hide the columns (i.e. make them really skinny), then we could leave enough room to keep a tiny icon to un-hide them.

Similar to #318 (comment), this behaviour could be customized by the dash developer to start to satisfy particular structured workflows and then expanded separately as part of #316 in the future to enable the end-user to customize them.

To start, the UI could look like:

• To hide the columns:
  1. Option 1 - Override the x to hide the column
  2. Option 2 - Introduce a new icon (like an eye?)
• To un-hide the columns:
  1. Option 1 - When the column is collapsed / hidden, we could either keep it skinny with an inverted icon (eye with a diagonal line through it?)
  2. Option 2 - We could completely hide it but add a floating sideways triangle at the edge of the column to bring it back.
     

---

Regarding the API: we already have columns.deletable, which doesn't lend itself well to custom behaviour like hiding behaviour & content clearing (#315). So, we could introduce new mutually exclusive properties:

columns: PropTypes.arrayOf(PropTypes.exact({
    deletable: PropTypes.oneOfType([
        PropTypes.bool,
        PropTypes.arrayOf(PropTypes.bool)
    ]),

    clearable: PropTypes.oneOfType([
        PropTypes.bool,
        PropTypes.arrayOf(PropTypes.bool)    
    ]),

    hideable: PropTypes.oneOfType([
        PropTypes.bool,
        PropTypes.arrayOf(PropTypes.bool)    
    ]),
}),

To start, if multiple properties are provided for the same column, then we raise a JS exception which will be visible to the end-user thanks to dev-tools. In the future, we could allow multiple behaviours with perhaps a context menu or lining up multiple icons next to each other.

column_ui=PropTypes.oneOf(['icons', 'context_menu'])

[Marc-Andre-Rivet]

Discussion notes: Introduce a new icon to hide + 'Option 2 - We could completely hide it but add a floating sideways triangle at the edge of the column to bring it back.' (or some variant) + columns.hideable as described above + hidden_columns for the currently hidden columns -- hideable will drive the capacity to hide but not the capacity to bring back a column.

Persistence will be done as a 2nd PR or branched out into a 2nd issue.

[Marc-Andre-Rivet]

Digging into this there's some complications

1. The floating menu interferes with other actions / is over them -- as we don't have these "selector" column cells that are not part of the headers.
2. While "hide" is partially like "delete", it's reversible and making it possible to unhide merged cells makes this complicated if we can hide multiple cells with a single action, the hover menu ends up having to exist for each row of the header, making the whole hide/unhide functionality confusing and complicated.

Overall the smarter feature described above feels muddled at the moment. I'm suggesting that we go back to the simpler implementation for now. Hiding columns individually is consistent with the spreadsheet experience it is attempting to match. Merged cells/columns is a visual trick, not a first class concept for the underlying grid.

Side note: Using the opportunity to bump up the "icons" in the table headers from unicode characters to the FontAwesome free icon sets. These are not perfect but they are more consistent and aligned with each other than the unicode characters. This is done through @fortawesome and allows for tree shaking -- we include only the icons we are using + bootstrap code (~35kB), not the whole library, which would take hundreds of kBs.