Fixed header without Virtual Scrolling

[franklixuefei]

Requesting a Feature

• Use case In my project, I need to have a fixed header because my table has a fixed height, and I would like the header to be sticky, just like the behavior in Virtual Scrolling
• Interfaces Ideally we should just have two table DOM elements, one holding the "header" components, like the table header, the filter, etc., and the other holding the table body, just like what VirtualTable does.
• Existing libraries Just look at VirtualTable.

Your Environment

devextreme-reactive: 1.1.1 react: 16.2.0 material-ui: yes

[kvet]

Hi,   It is unclear why you can't use the VirtualTable plugin. It's optimized for your use case. And it is implemented with the use of two table elements. Could you explain the request in greater detail?

[franklixuefei]

@kvet Thanks! Actually, I tried VirtualTable, but it didn't fit my need for 2 reasons.

1. I don't have a lot of data, so I don't really need VirtualTable, and I still want pagination rather than infinite scrolling like VirtualTable.
2. Currently VirtualTable has a small gitch where if you scroll very fast to the end, sometimes the last few rows won't be rendered, leaving blanks.

I really would like the sticky table header to work for ordinary Table as well, because my table has a fixed height(100% height relative to parent), so the table body is scrollable. When it scrolls, it would be ideal to have the table header, including the toolbar, to be fixed (sticky).

Thanks!

[kvet]

Thanks for the detailed info. I will convert the issue to an enhancement. But I am afraid that it will have a lower priority because we don't have so many requests for this feature.

[franklixuefei]

@kvet That's great to hear! Thanks a lot for taking this into consideration!

[franklixuefei]

@kvet Just as a note, when you guys get on this, I think it would be ideal if a user can choose whether he or she wants the header to be sticky or not, by adding an option to the <Table> component, something like stickyHeader: boolean

[emjayoh]

Any idea on an expected date to have this started/completed? My team is very antsy to get this completed to the point of me maybe custom coding it.

Also, has anyone added this custom? Any links to StackOverflow or other would be greatly appreciated.

Thank you for your grid. It is awesome.

[kvet]

Hi, @emjayoh.   Could you please explain why such a functionality is required? The Virtual Table implements the required functionality.   For now, we don't plan to implement this feature in the near future as we don't see its advantages over the Virtual Table.

[emjayoh]

I just realized that the virtual table handles this lol. I didn't realize u could keep paging with the virtual table. Thanks @kvet

[DrOFay]

Does VirtualTable support remote paging? I have to render search results using a Spring-backed (Java) REST endpoint that returns paged data. I would like to be able to display that data in a table with a sticky header, so if VirtualTable doesn't support remote paging, then this feature request would be very important to me.

I tried using VirtualTable with CustomPaging and PagingState, but that didn't work for me. I set a test page size of 10 and then added 14 rows of data. The VirtualTable displayed the first 10 rows but then stopped scrolling and the onCurrentPageChange callback was never called (not sure how it would get called in a virtual table unless it happened automagically when scrolling to the bottom of the current "virtual page"). Perhaps I'm just using the components incorrectly?

Below is the component I have defined:

<Grid>
  <PagingState currentPage={this.state.currentPage} onCurrentPageChange={this.loadMyData}
          pageSize={pageSize}/> // defined elsewhere
  <CustomPaging totalCount={this.state.totalElements}/>
  <VirtualTable/>
  <TableHeaderRow/>
</Grid>

[DrOFay]

Ok, so remote paging on a <VirtualTable/> is not currently supported. There is a workaround which can be found by following this thread from the Dev Express Support Center, but I'd say that a supported feature such as sticky columns for a <Table/> of paged data is a significantly better solution that anything labeled as a "workaround".

[franklixuefei]

@DrOFay Why it is not supported? You can just send the paging request from remote paging plugin to the backend server and the server will return whatever data out of that request, and you feed that data to the grid as you would usually do, isn't it? After that, just replace <Table> with <VirtualTable> and you are done. This is exactly what I'm doing in my current project, and it works great.

[lin-zy1229]

Dear, support team! We are really frustrated in using this grid for fixed header. When do you plan to implement this simple feature? We don't understand why you recommend to use VirtualTable, instead of pagination. Pagination with Fixed Header is really necessary functionality in table.

We hope you do this ASAP!

[alex153490]

I am a bit confused finding the right design. What I would like to achieve is the full-page table with the fixed header (mandatory) and fixed column (optionally) (page can have additional header (navigation) and footer (command buttons) but this can easily be achived by fixed panels/divs and additional padding of the grid that goes beneath those panels) and browser scrollbars prefereably.

There are 3 options how to align grid in the page:

1) grid takes fully the available space that is left by the mandatory elements of the page (e.g. by navigator, command panel) and grid can create its inner scrollbars. Page is organized in such a way, that no browser scrollbars appear. Virtual table is excellent for this scenario, especially after some tweakings in the last year. I wanted to stick with this scenario but in some cases VirtualTable creates infinite browser vertical scrolling, I have not managed to catch the cause of this, But it prevents me from this use case.

2) grid has fixed width and height. This is the most appropriate scenario for the grid. But result is quite confusing - as grid takes fixed portion of the screen, then the broser scrollbars (both) appears and disappears on each resize of the browser. It is confusing that sometimes the browser-window can have 2 sets of scrollbars - one from browser and another from the grid. Well, maybe it is acceptable scenario in the web development, but such duplicted scrollbars are really confusing;

3) (this is the best scenario) and at last comes the best scenario that was intended apparently by the initial requst - grid should take as much page space as it needs and it should create vertical and (possibly) horizontal browser scrollbars when necessary and such grid should have fixed header (under the fixed navigator provided by the page) and fixed footer (above the fixed panel of command buttons) and possibly fixed columns. This can not be achieved with VirtualTable that is why this request has been created.

Sometimes I am thinking that DevExpress should do something at bit differently. You are really great at creating grid, that is fine. But grid is very strange component for the responsive web design (as opposity to the desktop programming (e.g. VLC) where it fits perfectly) and so - maybe it would be great investment in Your product if You would gather and compile list of the best advices, uses cases, success stories how the grid may fit in the web page that follows the principles of the responsive web design. Currently efforts to search such "visual design patterns" is left to the responsibility of the end-users of the grid and they are consfused what can and what can not be achieved with the grid and so on. If the design patterns of the grid use existed then You could realign the grid according to those design patterns and all would be happy.

As it stands today, I feel that 3) is the best design pattern for the grid but it is not supported by this grid. This request was all about that. Well, I don't know where I will go from now on, but it was so simple and naturally with the DevExpress grid in desktop and it is confusing with grid in the responsive web design. It may be possible that noone has solved this problem and found such design patterns, it may be possible that grid is not the component for the responsive web. I don't know.

[alex153490]

https://www.ag-grid.com/example-runner/vanilla.php?section=javascript-grid-responsiveness&example=example&generated=1&grid=%7B%22theme%22%3A%22ag-theme-balham%22%2C%22noStyle%22%3A0%2C%22height%22%3A%22100%25%22%2C%22width%22%3A%22100%25%22%2C%22enterprise%22%3Anull%7D is the example what I am talking about for option 3)

[ushkal]

Hi @alex153490 ,   I recommend you follow the first approach since the second one is not so flexible and the 3rd one is not supported yet. We've discussed this layout in issue #1929 . There you can find a sample project for your reference.

if You would gather and compile list of the best advices, uses cases, success stories how the grid may fit in the web page that follows the principles of the responsive web design

Thank you for this great suggestion, we will consider it and perhaps publish some guide with such design patterns.

As it stands today, I feel that 3) is the best design pattern for the grid but it is not supported by this grid.

This solution is not prefect, mostly because it doesn't use the Virtual Table plugin advantages.

Well, I don't know where I will go from now on, but it was so simple and naturally with the DevExpress grid in desktop and it is confusing with grid in the responsive web design.

Thank you for the detailed feedback, we'll improve this.

[alex153490]

I just wanted to inform that I am not sure whether I am still voting for this issue. Today I checked SAP S/4 HANA (I guess the best EPR system available which definitely should have the best UX and the best grids) test solution to see how their grids are designed and found that their tables (e.g. in the Sales Order management - page with the list of sales orders) have no horizontal scroll - there is no inner (table) horizontal scroll and no outer (browser) horizontal scroll. If the grid has too many columns to be displayed in the page (without horizontal scroll), then the grid automaticall makes the column-name-column-value list for each record for the columns that do not fit in to the horizontal space (see the attached pictures for explanation). So - I don't know what I will do further with my projects. It is not recommended to allow horizontal scroll (I guess - any kind of) for the mobile solutions and the web pages should be designed with "mobile first" approach. So - this is very general open question - how the grids fit into responsive web design, of course, the answer will not be found in one thread/issue. So, my answer gives nothing to determine the direction of changes, but, I hope, it expands outlook and help for deliberation. From the other sides - there can be use case when horizontal scroll is required even when it goes at odds with mobile design guidelines, so, maybe feuature is still worth to be implemented.

[ushkal]

Hi @alex153490 ,   We have plans to implement a Card View for the dx-react-grid - this view is more user-friendly for mobile devices. As for column-name-column-value approach used in SAP, it can be implemented in our grid too. Here's a sample project. Let me know if it helps.

[emjayoh]

Update here: we can no longer enable sticky header with virtual scroll because of the pesky bug where fast-scrolling causes the rows to not render/freeze.

This is very frustrating as we devoted hundreds of hours of development resources on this grid.

We are currently looking to switch to AG Grid as it has a perfect sticky header implementation.

[ushkal]

Hi @emjayoh ,

It is sad to hear that our grid does not meet your requirements. However, it is not clear what bug you mean. Would you please clarify?

[emjayoh]

https://github.com/DevExpress/devextreme-reactive/issues/2126#issuecomment-506652258

[ushkal]

@emjayoh Thank you for your clarification. Let's discuss this issue in the context of the #2126 ticket.

[grbspltt]

@emjayoh thanks for the recommendation for AG-Grid! sticky header out of the box, perfect.

[calvinl]

@ushkal @kvet I'd like to bring up another use case for this feature:

It'd actually be very useful for situations where you don't want to use virtual scrolling, since virtualization requires that all your rows be of consistent height (in order to accurately estimate the total height of the table). In situations where we have simple rows that need to be of variable height (such as in the case of word-wrapped columns), the normal table view is better. However, if you have more than 10-20 rows per page it begins to feel like it would be much more convenient with fixed headers so you can still reference the header.

[churkin]

Hi @calvinl, Thank you for the feedback. I think it is one of real use-cases. We will keep it in mind during the feature implementation.

[franklixuefei]

Hi @churkin , Do you still plan to enable fixed header for non-virtual tables? As you can see, many of us long for this feature. Thanks!

[tmaiaroto]

I know this is dead, but would be good to at least try and beg for the feature again :)

The problem with the VirtualTable is that it's too much of a performance problem with a few cell formatters. When users scroll it really fast, it'll crash their browser because of each of the cells mounting/unmounting. Unless VirtualTable gets more efficient with caching things, lazy loading, and useMemo or something...some of us are going to be limited here.

(it's a relatively common problem for larger tables. for example, see: https://github.com/DevExpress/devextreme-reactive/issues/2656 ...and it's not just limited to that sizer bug really, it happens regardless)

Also could be solved the other way around - by using fixed header with VirtualTable (not adding it to Table) but adding a prop to change VirtualTable's behavior to not unload cells that are scrolled out of view. At least left/right.

[grbspltt]

@tmaiaroto just use AG-Grid, sticky header out of the box. I made the switch with all my other projects, works great.

[tmaiaroto]

I'll probably end up making a custom component / plugin for this. Devextreme's grid is the best one by far in terms of features. The plugin system is decent too.

One of the only things I wish for is some more control over the virtualtable. Unmounting any cell (not just the row, but the cell) when not in the viewport is one of those strategies that sounds good in theory, but in practice usually creates worse performance. Max call depth is extremely easy to reach with virtualtable.

[tmaiaroto]

Actually, here's what I did: https://codesandbox.io/s/goofy-river-2n40y

I made a component for tableComponent prop that was a copy of the existing Material UI table in the source code and I added the two props from Material UI's documentation for the sticky header. Then I adjusted the styles for thead th to include z-index and position sticky. Wasn't too bad. I wish this was a simple prop to pass, but I imagine replicating the same behavior across the other design frameworks would be more involved. Material UI so happens to make this easy.

[lock[bot]]

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests.