UI Components and Code Complexity Considerations

How can developers create great-looking user interfaces while reducing code complexity and decreasing development time? Modern front-end frameworks such as React, Angular, or Flutter make use of reusable components to help users bring their own designs to life. While any particular component is easy enough to implement, oftentimes these require special customizations, after all, we are in the business of building something new. This in turn leads developers and all stakeholders to have to make some decisions regarding the user interface as a whole, preferably before any code is written. Getting these decisions right can make a huge difference in both the developer and user experience, which helps ensure that even complex UI has simple maintainable code and can be quickly iterated upon. 

Consider a hypothetical new app by a new start-up. Usually, front-end development can begin after requirements have been gathered and at least some initial design mockups are in place. It would be beneficial if the designer and developer got together during this process to nail some of the standard design features to be used throughout the app, the most obvious one being the Theme/Color palette. Having this in place is extremely beneficial and having a clear understanding of this allows the developer to set up global theming in some frameworks, thereby reducing repeating code. It is also during the design process that any need for custom components should be discussed. After all, there are business implications to this. For example, the designer could come up with a great-looking but extremely complex table, which sorts and filters and highlights, in short, has all the bells and whistles one could add to it, but this table could take up development time, thereby increasing costs. It is conceivable that another, not-so-custom component such as a search field could solve the UI problem and this could be much faster to implement, for instance. If one takes into consideration the actual goal, the user story, or the problem to be solved it will be clear what needs custom developments, what can be created from simpler building blocks, and what can be reused.

Considering code, if a design calls for multiple instances of a custom component then it may be worth abstracting into its own more complex component, which takes in parameters that are passed to it wherever it is called. If an app has some button that has its own unique shape, color, and font, for instance, and this button is used in seventeen places throughout the entire app, then it might make sense to create a file for that button, write the proper documentation for its parameters, make sure this part of the source code is maintained and cared for. If, however, the app uses standard-looking buttons in a few places with some mild styling, which can be kept separate and reusable on its own, then it might not make sense to abstract a new button component. To give one more example. Consider an app that happens to have two tables within it. At first glance, it might seem like it makes sense to create a new table component to be used in both places, out of the table building blocks provided by HTML, for example. If one does this, however, there may be three files, two where the component is being called and one for the component itself, all of which should have their own documentation and be maintained by developers. Say we then want to add some filters to the first table but not the second one, and some buttons on the second one but not the first. Now the component file needs to be updated to optionally handle both these cases and the files where the component is being used need to be updated with new parameters as well. If each place where a table was needed had its own table, however, it would be much simpler to add a filter where a filter is needed and a button where a button is needed.  This has the added effect of making the code more maintainable by allowing new developers to quickly understand UI that is built out of components that they know and are familiar with instead of having to learn how the company button works, especially if no one takes the time to properly document it.

Thus, to speed up development it is necessary to have an eye out for component complexity from the beginning before any code is written, and possibly try to plan ahead for any places in the app that may require complex UI. During development, it is important to constantly question and evaluate any need for abstraction, and make sure to properly maintain and document the code wherever custom components are needed.