Have you ever felt the pain of writing & maintaining the same code pieces at multiple places?It may be a small code snippet or a third party component, the pain & frustration is constant.
- How to create a reusable view?
- How to make enhancements and change adoption faster with more consistency?
Understanding the Problem in deep
So the answer to the above questions is to create the common component and use it everywhere seems easy, right?
Wait… let’s take Tables as an example and think about the tables’ view with the below cases where
- Each table shows data fetched from various API
- Each table has a different number of columns where each column can have different types of data like strings, numbers, currency, links, or HTML elements.
- For Each table having different styles for various data types as follows
- If data is a string then align it to the center of the cell.
- If data is currency then align it to the right of the cell and show it with the “$” sign.
- If data is simple number align it to the left.
- If data is links want to show in a specific style and different behaviour
- Want to combine the value of two fields and show it in one cell.
- Want to provide the row selection on a few of the tables.
- Want to show a very specific message when there is no data available.
- Want to add data sorting capability for a specific columns or for all.
- Want to have the pre-selected rows on the table while loading the page.
- Want to hide the headers for some tables.
- Want to provide the global filter for specific or all columns of tables.
- Want to provide input box on certain columns and provide value changes
- Want to provide input box on certain columns with event which trigger on value change.
Assume if you need to support this on each page with tables that represent the different data how much redundant code one needs to write, so what’s the solution?
Dividing Problem into solvable chunks
- Presentation component.
- Table level Configs
- Column specification and Column level configs.
- Events to emit the actions on table or columns.
- Use the @Input to get the all required configs & data.
- Use the @Ouput to emit all the events happening on the table.
- Render the view of the table based on specific theme or UI frameworks like PrimeNg, Angular Material, or Bootstrap used within the application with the help of the configs and data
Table level Configs
selection: Specify weather to provide the row selection to table or not.
selectAll: Specify weather to provide default selection of all rows of table on load or not.
defaultSelectedData: Provide data that needs to be selected instead of all rows.
disableSelection: To disable the row level selection on the table.
showCheckbox: To Specify weather to show the checkbox for all rows or not.
showShort: Specify weather to provide sorting for each column or not.
showHeader: To show or hide the header on the table as its optional config default value will be true.
globalFilterFields: To specify on which field table level filter needs to provide as its optional config default value will be an empty array.
emptyMessage: To specify the message which needs to show when there is no data, as its optional config default value can be a generic message like “No Data Available”.
scrollHeight: To specify the height of the table after which needs to show the scroll in order to make sure table takes only specified space while there are huge data, its optional config when there is no value provided it will take the whole page in case of a huge amount of data rather than showing scroll on the table
Column specification and configs
Will take the all columns specification with column level config
Will create the type ITableColumns.ts which specifies the required and optional configs at table level
Benefits of creating such presentational component
- Presentational component works as the well defined interface which makes it easy to accommodate any changes from theme or different UI library with minimum effort and time.
- Let’s say here the table component is using the PrimeNG library for table view so in the future on PrimeNg upgrade if there are any breaking changes or property name changes then only a single point of change is there.
- Want to replace the PrimeNg completely with Angular Material then also there is a single point of changes and will update on the entire application
- Create room to focus on a new development rather than wasting time & effort on the same things repeatedly.
- Improve speed of the development and can enhance the presentation component as new requirements and needs come into the picture.
- Reduce the testing efforts
- Increase the code readability