schrodinger
Default styling should make custom styling possible / easy
Expected Behavior
It should be easy to apply custom styles to the grid.
Current Behavior
The default styling does too much and is not well organized. This makes it difficult apply custom styling in many cases. A few examples are:
Wraps on default cell make styling hard. Can't style the border of FixedDataTableCellDefault Also when table width > total column width, it's difficult to style the extra header space.
Possible Solution
Consider making default styles into themes which can easily be applied or removed depending on the needs of each use case.
Steps to Reproduce (for bugs)
Your Environment
- Version used: 0.7.5
- Browser Name and version: Chrome 53
- Operating System and version (desktop or mobile): Mac OSX Yosemite
- Link to your project:
I want to keep them both open as they have distinct deliverables and may have separate conversations. We can mark them both as future enhancements though (post 1.0)
The table I built for work I was able to get Radium to take over instead of the CSS sheet. Helped in numerous ways in easily getting to production. This was our thought exactly, how can we easily modify styles going forward. I can probably get a PR with the basic setup for this over. I haven't noticed any sort of performance loss, but I don't know how hard you guys work the table.
Also, of course too many people on our team are anti-CSS so I was having a hard time getting anything except CSS-in-JS through review.
Cool, we're definitely looking to explore new ideas here. If you could create a PR or example of how you used Radium, I think that would be very useful as we plan for future FDT versions.
@wcjordan In the light of #531 - wouldn't a simple solution be to expose more classNames on the elements that could overwrite the defaults? Perhaps leave the very basic styling as default (just the positioning) and leave the rest to user ?
That would be an easy to implement solution. I think the downside is it may prove brittle and difficult to maintain if we change the tables DOM structure. One approach might be to add a way to set classnames on elements, but to name all the props with experimental so users aren't surprised if they break on upgrades.