Reusability: How to Take out Abstract Logics from the Requirements

March 06, 2019

Have you encountered a time when you develop similar functions and write similar codes again and again?

If yes, then it’s time for you to think about software reusability.

After working as a software engineer for a few year, I gradually realise how important it is to write reusable code, especially in modern front-end web development world, where components are everywhere.

A component is centralised with its own logics and decoupled from the other components with loose relationships.

In a project, there are many components working together. Sometimes, you would find that some components are behaving in a similar way. For example, there are so many listing view in an enterprise application.

In HR module, there may be payroll record listing, candidate listing, available job listing. In Finance module, there may be invoice listing, account listing and supplier listing.

A junior developer may think, oh, I have so many listing pages to develop, it will costs me weeks to make everything nice and correct.

To maximise the efficiency of application development, is there any convenient way?

If you think about the similarity of all kinds of listing, you would notice that they share the same properties, which are column defintions, sort field, pagination settings and filter parameters. (Probably there would be theme options if you would like to beautify the boring enterprise UI. LOL)

With these properties, we can actually make a general component to generate all kinds of listing view. As a cost, developers only have to pass in configuration settings about those properties (field settings, sort field, pagination settings, filter parameters).

Hence, instead of writing similar and redundant codes for specific listing pages, you only have to maintain one component and all the rest you need to do is to find a place to pass in the configurations.

For example, a sample user listing configuration in JSON format might be

{
    "columnDefinitions": [{
            "name": "id",
            "displayName": "ID",
            "pinned": "left",
            "sortable": true,
            "searchable": false
        },
        {
            "name": "username",
            "displayName": "User Name",
            "pinned": "none",
            "sortable": true,
            "searchable": true
        },
        {
            "name": "status",
            "displayName": "Status",
            "pinned": "none",
            "sortable": true,
            "searchable": true
        }
    ],
    "sortField": {
        "column": "username",
        "asc": true
    },
    "paginationSetting": {
        "page": 0,
        "totalPage": 10,
        "itemPerPage": 2,
        "totalItem": 12
    },
    "filterParams": [{
            "filter": "status",
            "type": "equals",
            "value": "disabled"
        },
        {
            "filter": "name",
            "type": "contains",
            "value": "liu"
        }
    ]
}

This JSON can be interpreted to display a list

with 3 columns, namely ID, user name and account status
sorted by user name in ascending order
at page 1 with 10 items per page and the total of 12 items and 2 pages
filtered by 2 conditions, status being “disabled” and name contains “liu”

Then in the general listing component, you need to organise your code to achieve these abstract logics.

For every different listing pages, just by making the JSON configurations different, you can use one component to quickly show the listing result. Thus, it makes our code reusable.