-
-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Fixed columns #131
base: master
Are you sure you want to change the base?
[WIP] Fixed columns #131
Conversation
most of layout done. TODO: - [ ] fixed/standard wrapper for headers - [ ] remove inline css - [ ] remove style warnings - [ ] fix ember-infinity
@cball This is.. this is awesome! Im super excited for this. I think we are gonna have to make the font size on the navbar smaller to fit all these features in 😏 From a quick glance, I noticed that you're branch is a bit behind master. I would suggest to rebase since it has a lot of changes that resolve some critical issues and that will prolly conflict with some of your code. In terms of the trackpad scroll emulation, I think @taras would be your man. |
@cball this is awesome! I ended up adding Trackpad Scroll Emulation because we have fixed headers and footers which are setup as separate tables. With regular scrollbars, the columns in the header didn't line up with the body because they had different widths, caused by scrollbar being added to the body. I'd love a simpler solutions. It'd mean that we'd be able to remove a dependency and reduce complexity. If you have any suggests in regards to how to manage the content width issue caused by body scrollbar, I'd love to hear them. |
Thanks! I'll rebase and get this finished / cleaned up. In the first pass of this feature, I want to keep the existing virtual scroll behavior in tables without fixed columns. We should be able to normalize the scroll behaviors in all tables with a followup PR. tldr there I think will be measuring scrollbars and explicitly setting widths. We should also be able to simplify the codebase a bit in the future by making all tables without fixed columns operate the same as the standard columns from the fixed version. |
I'm concerned about this. So far, I've been very intentional about not getting into a situation where we're managing dimensions of elements through state and rely on the browser to size elements appropriately. Mixing state managed sizes and DOM sizes quickly leads to having to manage all sizes through state. This is part of the reason why we're using I would prefer for us to continue to evolve this pattern rather than getting into setting widths and heights via state. I'm going to work on a prototype that has nested My other concern is that collapsible rows will not work with fixed columns(without doing some complex height management). This is the reason for my comment in #114. I was hoping we'd be able to use something like |
It doesn't look like nested I'll keep you posted on my progress. In the meantime, I'm curious what your thoughts are regarding collapsible rows and fixed columns. |
Ember scrollable is already measuring the scrollbar and setting widths/heights, not sure how is this different? Fixed columns are implemented using 2 absolute positioned containers with separate tables, as such they need widths and heights set. I can certainly use Re: collapsable rows, yes we'll probably have to do some height management so things don't get out of sync. I think I'd probably start by firing an action from the High level question: Should an expanded row take on the width of the entire table (both fixed and standard columns) or just the non-fixed side?. Agree its too bad about |
This is a very exciting feature, this behavior could be very useful in regard to expanding the responsive design aspects of this table component. |
Where does this feature currently stand? I'd be glad to help push it along |
@rwwagner90 I was waiting on feedback on how to proceed. I unfortunately don't have any free cycles at the moment, but if this is a direction that @offirgolan and @taras would like to go with this library (I'm unsure if it is) then help moving things along would be greatly appreciated. |
Is there any progress with the PR? I have been waiting for this feature to be merged. |
@offirgolan @taras can you guys weigh in here please? I would be glad to help with implementing this, but do not want to put effort in, if it is not something that is desired for this addon. |
This PR has been in a bit of standstill mostly because we're not sure the best way to proceed. We would like for this feature to happen, but we weren't 100% what approach to take. @cball proposed a solution, but we inadvertently blocked him by not providing a path for moving forward. @alexander-alvarez has a PR in the works for Would you be interested in picking this up when that PR lands? Primarily, we need to figure out how the solution proposed in this PR is affected by that change. What do you think? |
has there been there any progress with this? |
It looks like the ember-scrollable PR has been merged. After a year, is there any news on this feature? |
@cball @taras @offirgolan I'm guessing this PR will probably need a rebase and some reworking, but now that I think it would be a very popular feature - tables being responsive and usable at small viewports is a huge deal! |
This has a decent amount more for me to do before I'd consider it mergeable but I wanted to open it up for discussion.
This library is gaining traction, so I wanted to look at adding some of the high level features developed in https://github.com/cball/justa-table so that I can put resources towards this library instead. We currently have 3 projects that need fixed column support and I know others that have expressed the need for that feature as well. @taras had concerns using fixed columns in #114. While complicated to implement, it is a pretty common ask for complex tables and I don't think you can always just implement a different UI.
First, the largest issue: Trackpad Scroll Emulator which is used by
ember-scrollable
can only scroll 1 way. (see https://github.com/jnicol/trackpad-scroll-emulator#5-limitations). As such, in this PR when there are fixed columns present, native scrollbars are used instead. I'd actually argue to put the work in to make native scrollbars work across the board but that's a separate issue.TODOs before I think this is ready: