3 ms·

One of the biggest "problems" with React is that it is such an out-of-your-way ecosystem that teams are able to build their own preferred abstractions whenever

by tmpz22 7y ago

One of the biggest "problems" with React is that it is such an out-of-your-way ecosystem that teams are able to build their own preferred abstractions whenever they want. In the mindset of many web developers, we're all geniuses who surely can invent the more optimal wheel - whether that's because we work at $BIG_CORP and have the time, or because we work in a start-up like environment with nobody to audit us and tell us we're collectively acting like dumb asses. I've personally wasted several hundred hours this year implementing custom table logic and design through the react-virtualized-table/react-window libraries. They are great libraries! But it was not a good use of my time customizing it into a perfect incantation/API. I over-engineered how the virtualization tied into our REST API and many of our junior developers couldn't keep up with the increased abstraction. Let my story be a lesson that you should probably grab hold of a library like this, swallow the fact that you're conforming to someone else's API and concepts, and just get stuff done. I'll seriously evaluate and likely use this library in future react projects instead of other more involved implementations. Great docs too!

tannerlinsley 7y ago
The beginning of your comment made me uneasy, but then you endorsed the library! Phew! Thanks!
nightski 7y ago
I too have gone down the same road as you. I wish I could share your sentiment of - just go with React Table. But React Table is headless. Which is nice, but it's not going to automatically virtualize rendering. From what I can tell you are going to have to manually render using react virtualized/window or some other solution to get that to work. It also doesn't support things like fixed rows or columns out of the box since it doesn't provide UI. My initial reaction is that this is a rather complicated API to group, sort, filter, expand, re-order, and select rows within data structures. It also uses a lot of prop spreading which is not my favorite. I'm not sold that you wasted your time. But I'm going to give it a little more time as my initial assessment could be inaccurate.
- tannerlinsley 7y ago
  I would love to hear how you would solve these problems yourself. Any ideas are very appreciated. Still, the patterns and tradeoffs built into React Table are not fleeting exploratory concepts that we hope will catch on, they are architected this way for a purpose. Sure, it doesn't come with any opinionated UI, but in the future, opinionated UIs for React Table will likely exist (some are already in development by 3rd parties). Until then, there are plenty of examples that show you just how easy it is to implement things like virtualization. Having control of the markup for a data grid can be intense and intimidating for those who aren't use to building their own tables, but again, once you see how little work there is to do in your own components, you'll see the power in the library (like having full control over styles, building your own UI APIs, prop patterns, state management paradigms, etc.) As for the prop spreading............... It's fantastic and I would love to see anyone convince me of a more elegant/composable pattern for decorating arbitrary and unknown markup.
- tmpz22 7y ago
  Fair take, but I also believe we should've thrown out virtualization/windowing entirely. It was of those shiny product-level features that sounds great but ultimately provides little to no value for most applications. Most of my point is engineer-oriented but I think it also applies at the product level. React allows you to build cool features easily - that doesn't mean every cool idea should be acted upon. At times this will mean "dumbing-down" design in the name of pragmatism > shininess. YMMV, ad-supported businesses are going to need that infinite scroll... but most don't.
  - tannerlinsley 7y ago
    Agreed. Most if not all of the production tables I have are using very simple architecture. Pagination + Data Exploration utilities like sort/filter/group/etc. In no way am I preaching that these plugins should used. However, I am proud that they can be used. And if you end up being one of the users that only needs a few things to make your production tables great, then you win again by being able to treeshake out all of the other stuff you choose not to use.
JMTQp8lwXL 7y ago
Why was the virtualization tied into to your Rest API? If I give you an array of N things, you render them. If you need more records, ask me, and I'll get them for you. The table should be just be a UI component with virtualization. It shouldn't need to know how to retrieve its data.
klemola 7y ago
I went through quite some trouble to get a react-table v6 based datagrid updated to v7. I found that the examples showed individual features well, but when you combine features you are on your own. The "Kitchen Sink" example is far from having all features enabled at once. The reason why I couldn't stay with v6 was that the virtualization examples used a deprecated API from an old minor version. I would have had to support a solution on a non-supported version (v6 has been pretty much abandoned). So, I had to get these features to coexist peacefully: - expanded rows - virtualization - sorting - custom cell rendering - click actions inside the cells (open a dialog, add the row entity to comparison) Mirroring the GP, I had to use react-window and deal with the complexity from the library. I think that virtualization should be a first-class citizen inside react-table, like sorting. On top of all of this the TypeScript support/typings are tricky to work with (IIRC you have to maintain a .d.ts file in your codebase and remember to update it when you update react-table). I literally had a headache for hours on while going through the refactoring. In the end I managed to get everything to work without any bugs or weird behavior. I really was enthusiastic about v7, but was left with a bad feel of it. I'm sure that things will get better, and luckily most folks don't beed all of these features. It's really the virtualization that makes things complicated. The thing is, pagination is not always a viable solution. To save other people trouble, I should update the Codesandbox that I originally built (https://codesandbox.io/s/react-table-virtualized-subcomponent-j6ho5 https://codesandbox.io/s/react-table-virtualized-subcomponen...).
runawaybottle 7y ago
Some of React’s data tables are not that great for anything other than the most conventional cases. You are mostly right, but I don’t think making your own table is equatable to like some of the dumbass things people inject into their ecosystem for a simple app. /signed - the dumbass that builds his own table components.

by tmpz22 7y ago

tannerlinsley 7y ago

The beginning of your comment made me uneasy, but then you endorsed the library! Phew! Thanks!

nightski 7y ago

I too have gone down the same road as you. I wish I could share your sentiment of - just go with React Table. But React Table is headless. Which is nice, but it's not going to automatically virtualize rendering. From what I can tell you are going to have to manually render using react virtualized/window or some other solution to get that to work. It also doesn't support things like fixed rows or columns out of the box since it doesn't provide UI. My initial reaction is that this is a rather complicated API to group, sort, filter, expand, re-order, and select rows within data structures. It also uses a lot of prop spreading which is not my favorite. I'm not sold that you wasted your time. But I'm going to give it a little more time as my initial assessment could be inaccurate.

tannerlinsley 7y ago
I would love to hear how you would solve these problems yourself. Any ideas are very appreciated. Still, the patterns and tradeoffs built into React Table are not fleeting exploratory concepts that we hope will catch on, they are architected this way for a purpose. Sure, it doesn't come with any opinionated UI, but in the future, opinionated UIs for React Table will likely exist (some are already in development by 3rd parties). Until then, there are plenty of examples that show you just how easy it is to implement things like virtualization. Having control of the markup for a data grid can be intense and intimidating for those who aren't use to building their own tables, but again, once you see how little work there is to do in your own components, you'll see the power in the library (like having full control over styles, building your own UI APIs, prop patterns, state management paradigms, etc.) As for the prop spreading............... It's fantastic and I would love to see anyone convince me of a more elegant/composable pattern for decorating arbitrary and unknown markup.
tmpz22 7y ago
Fair take, but I also believe we should've thrown out virtualization/windowing entirely. It was of those shiny product-level features that sounds great but ultimately provides little to no value for most applications. Most of my point is engineer-oriented but I think it also applies at the product level. React allows you to build cool features easily - that doesn't mean every cool idea should be acted upon. At times this will mean "dumbing-down" design in the name of pragmatism > shininess. YMMV, ad-supported businesses are going to need that infinite scroll... but most don't.
- tannerlinsley 7y ago
  Agreed. Most if not all of the production tables I have are using very simple architecture. Pagination + Data Exploration utilities like sort/filter/group/etc. In no way am I preaching that these plugins should used. However, I am proud that they can be used. And if you end up being one of the users that only needs a few things to make your production tables great, then you win again by being able to treeshake out all of the other stuff you choose not to use.

JMTQp8lwXL 7y ago

Why was the virtualization tied into to your Rest API? If I give you an array of N things, you render them. If you need more records, ask me, and I'll get them for you. The table should be just be a UI component with virtualization. It shouldn't need to know how to retrieve its data.

klemola 7y ago

I went through quite some trouble to get a react-table v6 based datagrid updated to v7. I found that the examples showed individual features well, but when you combine features you are on your own. The "Kitchen Sink" example is far from having all features enabled at once. The reason why I couldn't stay with v6 was that the virtualization examples used a deprecated API from an old minor version. I would have had to support a solution on a non-supported version (v6 has been pretty much abandoned). So, I had to get these features to coexist peacefully: - expanded rows - virtualization - sorting - custom cell rendering - click actions inside the cells (open a dialog, add the row entity to comparison) Mirroring the GP, I had to use react-window and deal with the complexity from the library. I think that virtualization should be a first-class citizen inside react-table, like sorting. On top of all of this the TypeScript support/typings are tricky to work with (IIRC you have to maintain a .d.ts file in your codebase and remember to update it when you update react-table). I literally had a headache for hours on while going through the refactoring. In the end I managed to get everything to work without any bugs or weird behavior. I really was enthusiastic about v7, but was left with a bad feel of it. I'm sure that things will get better, and luckily most folks don't beed all of these features. It's really the virtualization that makes things complicated. The thing is, pagination is not always a viable solution. To save other people trouble, I should update the Codesandbox that I originally built (https://codesandbox.io/s/react-table-virtualized-subcomponent-j6ho5 https://codesandbox.io/s/react-table-virtualized-subcomponen...).

runawaybottle 7y ago

Some of React’s data tables are not that great for anything other than the most conventional cases. You are mostly right, but I don’t think making your own table is equatable to like some of the dumbass things people inject into their ecosystem for a simple app. /signed - the dumbass that builds his own table components.