robere2
commented
1 year ago I've decided to split the logic up for each type, at least for now. Having a generic component for all data types may be applying the DRY principle too aggressively. In my initial experiments, I found the code to be overly complex, and the end result was too uniform. While different dashboard pages were all laid out the same, the user experience seemed to involve more steps and button presses to accomplish what should be common tasks. In reality, while we want our dashboard pages to be laid out similarly to each other, each page has a vastly different purpose and set of data to display. Thus, each dashboard page should be (for the most part) designed independently, in my opinion.
With that change in direction, this issue is no longer necessarily to complete all dashboard tables. Instead, we should focus on the critical ones, and others can be implemented down the line. The original issue will be edited to reflect this.
Some groundwork has been laid for the admin tables in the dashboard in the Groups page, however it's not complete, and it needs to be standardized for all dashboard table pages. Ideally, there would be one component which takes in set(s) of properties that can be created/edited/displayed/etc.The direction of this issue has been changed to instead focus on creating unique tables for each data type. While this may involve more repetition within code that seemingly serve the same purpose, each data type needs to be represented in vastly different ways. Creating unique components for each type seems to make the most sense (at least in the short term). Thus, this issue is now focused on only getting dashboard pages completed for the core data types: