Creating Generic Table using Angular Material Design

This is the second part of the series to create generic components in angular. In order to see all the articles please visit this link.

Generic Angular Component Series:

Part 1: Creating Generic Restful Services in Angular

Part 2: Creating Generic Table in Angular Material Design

Part 3: Creating CRUD table based on Restful APIs in Angular [In Prorgress]

As usual, let's start off the journey with gathering the requirements for the generic table first:

Requirement 1: Allow the table to have dynamic columns (allow the parent component to pass in the column definition).

Requirement 2: Allow all the CRUD operations on the Table data, e.g: Create a new item, View details of an item, Update the existing item, and Delete the existing item.

Requirement 3: Allow search functionality on the table, and based on the user need, allow the search to be a real-time backend call or just a simple search on the data that is already loaded.

Requirement 4: Enable pagination on the table data, and based on the user needs, allow it to be configurable, as in allow it to be either real-time backend call or just pagination on the already loaded data.

Requirement 5: Allow to pass in the tooltips to display when the user hovers over the respective elements.

Requirement 6: Allow configuring which of the CRUD operations must be shown or supported on the table.

Requirement 7: Enable sorting of the table data based on customer's actions.

Based on the requirements these are the following properties which must be taken as input for the base component:

  1. columnDefinition => type: key value pair, description: key should contains the columns Id in the tableData, where as value should contain the column display heading
  2. tableData => type: array, description: array containing the input data to the table
  3. enableBackendPagination => type: boolean, description: decide whether to make api call when changing pages on the table.
  4. enableBackendSearch => type: boolean, description: decide whether to make api call when search text is typed.
  5. displayEditAction => type: boolean, description: decide whether to include edit icon as part of CRUD operations.
  6. displayDeleteAction => type: boolean, description: decide whether to include edit delete as part of CRUD operations.
  7. displayDetailAction => type: boolean, description: decide whether to include view details icon as part of CRUD operations.
  8. displayCreateAction => type: boolean, description: decide whether to include add icon as part of CRUD operations.

Since searching, pagination, and crud operations are also supported, therefore, the base component must be able to communicate with the parent component as well. Therefore if the necessary options are enabled via input variables, then the following parameter must be defined too:

  1. actionCalled => type: event emitter, description: sends users action along with the selected row object to the parent component, upon event reception the parent component can for example make some API calls.
  2. searchCalled => type: event emitter, description: sends users search text to the parent component, upon event reception the parent component can for example make some API calls.
  3. pageEventCalled => type: event emitter, description: sends users selecte page and items per page to the parent component, upon event reception the parent component can for example make some API calls.

P.S: Note that this is just the view layer, so no service needs to be injecting into this component, thus making it super usable.

The component code is here. In the coming articles I will discuss how to use this component and make it work with the backend services as well.

See you next time : )

--

--