Open blafond opened 5 years ago
Right now we have only one table used in the codebase, here.
The idea behind the ExtensionIntegrationsTable
component is to provide an abstraction over the underlying table library, with columns and the overall table behavior already defined for the consumer. So to use it one needs to pass only the data array - of the right shape - and the select handler.
This doesn't mean that there is a lot of thought behind this solution. What do you think about this pattern? Would it work for you?
Thx Riccardo,
This is a start.
our UX mockups currently have 2 table scenarios.
The first is a summary table of the columns defined for a "View" which basically shows a known number of columns (id, isKey, name, datatype, etc..). So the pattern in ExtensionIntegrationsTable component should work.
The 2nd scenario involves displaying a table of data returned from a query that could contain any number of columns. This would require data dynamically driving the column definitions (#columns, header titles, cell datatype, etc...)
Barry
Data integration mockups include Table like functionality. Patternfly 3 examples reflect a minimal level of Table definition/examples based on Rectabular however, it would be helpful to define a common implementation pattern for adding tables as components and within components.