Learning How to Leverage Component Based Design In Modal Building

Why Use Modals? 

Modals are powerful web page elements that direct users towards important information and actions that require immediate attention. They are helpful in isolating complex systems components, into pieces that the user can digest, while ignoring any background noise. 

At Taplytics, our Journey Builder consists of numerous actions and triggers, in the form of ‘nodes’ that allow a user to build a customized journey for their users. Journey nodes are made customizable through the use of modals.

Don’t All Modals Look the Same? 

As seen in our Journey Builder, each node’s respective modal is very similar. They may contain a different combination of actions or messages, but they have the same theme and overall feel. It is almost as if there are a defined set of pieces that have been carefully rearranged and tweaked for each modal. If each modal were built from scratch, it would involve a large amount of repeated code and wasted resources. To avoid this, we have taken advantage of component-based design in the Journey Builder. 

To read more about why we use component-based design at Taplytics, check out how we take advantage of it for our No-Code-Web-Editor. 

Walking Through the Process of Building a New Modal: Outbound Webhook Modal

When faced with building a new modal for the Journey Builder, there are likely already existing components that can be used as-is, ones that are almost what we need them to be, and new components that need to be built. It is best to distinguish this in the grooming phase, prior to actually beginning the process of writing any code. It is both wasteful and discouraging to start building a new feature only to discover that there were already existing components that could have been used.

Outbound Webhooks is an upcoming new action that will be available in the Journey Builder. Users will be able to trigger actions based on specific events. The modal below allows users to customize the name, webhook URL, post body, and send a test request. It opens from the associated ‘Webhook Node’. 

Read more about co-op Michael’s experience working on Webhook Nodes.

Upon examining the modal design, various pieces can be identified, such as the buttons or the input fields. Isolating these aspects of the design into pieces can help you look at a design as a collection of components, rather than one big picture. 

Outlined in blue are a few of the existing reusable components that were identified during the grooming process. These components were able to easily be incorporated into the modal without having to make any modifications, such as adding new props or style variations. For example, the message displayed at the bottom of the modal uses our existing TLStatusMessage component. 

TLStatusMessage has been built to accept a variety of optional props, to fit common status use cases across our platform, such as warning or error messages. For the Outbound Webhook modal, we were able to pass in a customized icon using the customIcon prop, and display the appropriate message between the TLStatusMessage tags. The reusable component took care of the styling, such as coloring and spacing, making it super easy to achieve the desired look. 

Outlined in red is a component that did not exist before building the Outbound Webhook modal, but during grooming, it was decided that it might be beneficial to future development to isolate it into its own reusable component. 

TLDropdownInput is actually a combination of two already existing reusable components that have received some customized styling to make the dropdown portion, and the input portion, appear as one. It accepts props that allow customization on placeholder values, dropdown options, and handlers for both the input and dropdown portions. Additionally, the widths for each of these portions are accepted as props. Under the hood, these props are just passed down to our TLDropdown and TLInput components.

How To Decide If You Should Build A Reusable Component? 

It is difficult to determine if a component should be made reusable without being able to see the future. In the case of TLDropdownInput, this component is commonly used across many different platforms, and we concluded that it will likely be seen in the designs for our future features. Finding the answer to this question is not always this clear cut, but it helps ensure that your components library does not become cluttered with ‘reusable components’ that aren’t actually ever used. A cluttered library often is a result of large, unfocused components, that may include one-off variations or optional props that were added and then never used again.

If there are doubts as to whether a component will be reused in the future, it is better to focus on writing clean, function-specific components within the feature you are developing. It can then be later extracted into a reusable component if more use cases arise. Observing more use cases makes it easier to determine which props should be available for customization, and what functionality and styling should be a part of the core component.

Learning How To Think ‘In Components’

As we continue to leverage reusable components for our Journey Builder modals, we are learning how to think about designs as focused pieces that fit together to build entire features, right from the start. Similar to how our modals allow users to focus on one particular action in the Journey they are creating, our reusable components are focused around one particular function or purpose. Incorporating this thought process from the initial grooming phase both quickens the developing phase and ensures that we are building out our component library with intentional, useful reusable components.