Front end system design interview - UI components
Front End Interview Handbook is now part of GreatFrontEnd! We are working to migrate the content over and you may find the latest version of this page on GreatFrontEnd.
Examples
- Autocomplete: Read example solution (Free)
- Image carousel: Read example solution (Paid)
- Dropdown menu: Read example solution (Paid)
- Modal dialog: Read example solution (Paid)
- Poll widget: Read example solution (Paid)
- Selector which loads options over the network
To find out more, check out GreatFrontEnd, which shows you how to approach front end system design interviews with their front end system design guide and case studies. There are also blogs that will cover some of the following topics in more detail.
Framework
In system design interviews, candidates are supposed to lead the conversation. Here's a framework you can use to give an outline to the interviewer as to what you are going to cover. This framework is called RADIO and it is made up of the first character of each step. You can write this structure down on the whiteboard/online editor so that you don't forget.
- Requirements exploration: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions.
- Architecture / High-level design: Identify the key components of the product and how they are related to each other.
- Data model: Describe the various data entities, the fields they contain and which component(s) they belong to.
- Interface definition (API): Define the interface (API) between components in the product, functionality of each API, their parameters and responses.
- Optimizations and deep dive: Discuss about possible optimization opportunities and specific areas of interest when building the product.
Requirements exploration
Every system design interview (even for non-front end as well) should start with requirements gathering/clarifying requirements about the question, which is usually left underspecified on purpose. You are recommended to spend at least a few minutes clarifying the requirements. Do not start drawing the architecture before you are clear about the requirements!
Thankfully, components have well-defined scope and not try to do too many things. You likely have used such a component yourself and possibly know what you need from such a component.
Some considerations:
- What devices should the system support? Desktop web, mobile web, etc
- What's the primary device that users will access the system on?
- Which browsers should we support?
- Do we need to support internationalization?
- How much styling customization do we want to allow?
Architecture / High-level design
Architecture for front end interviews are typically focused on the client-side architecture, and not on large scale distributed systems where databases, load balancers and servers are involved.
For components, list down the various subcomponents that will exist within it and what data is being passed among each component.
Let's take an image carousel example. Subcomponents within an image carousel would be:
- Main image - An image that displays the photo in focus
- Thumbnail - Smaller images below the (Will there be thumbnails? You will only know if you clarified requirements earlier)
- Image store - A client side cache of the list of photos to display
If you have a whiteboard/online drawing tool, it would also be helpful to draw diagrams to illustrate the entities and their relationships. Which subcomponent communicates with which when a user interaction occurs.
Data model
Data model for components will refer to the component state. The concept of state should be familiar to most front end developers who have used front end UI libraries/frameworks such as React, Angular, Vue, Svelte, etc. In every of these libraries/frameworks, state is a common concept.
Deciding what data to put in state is essential to doing well for this portion. Few factors to consider when deciding what goes into component state:
- State is allowed to change over time during the lifecycle of the component, typically as a result of user interactions.
- Each component should maintain its own independent state which allows multiple instances of the component to coexist on a single page. The state of a component instance should not affect the state of another instance.
- Components are easier to reason about (read/understand) the fewer the fields there are in the state. We should strive to reduce the amount of state needed. If a component uses a value which can be derived from another piece of state, then that value should most likely not be part of the state. For example if your component is rendering a list of items and you want to display a message when there are no items to render, there shouldn't be an additional
isEmpty
state because it can be derived from the length of theitems
. - If a component has multiple subcomponents, it'll be best if it's possible to consolidate the state within the top level and the rest of the components are pure and stateless.
Interface definition (API)
The key idea behind components is for them to be reused and abstract complexities. Good components are designed in a way that they can be reused in multiple scenarios, and users do not have to know how they work internally before using them. In the case of components, API refers to configuration options that the component developer would expose to other developers for specification.
- What are the configuration options you would allow for the component? (
props
in React). What would be reasonable defaults? - Follow the Open-closed principle - the component should be open for extension but closed for modification.
- If your component is meant to be part of a UI library that doesn't bother about the appearance and leaves the styling to the user, extra care has to go into the design of the props and to allow users to customize the look and feel of the components. There are a few ways to go about this in React:
- Composition - Props which accept React components which also promotes code reuse.
- Render props are function props that a component uses to know what to render. It also helps in reusing behavior without bothering about the appearance.
className
orstyle
props - Allows users to inject class names and/or styling attributes to inner DOM elements. This could have negative consequences but is still a common way of allowing user to customize component appearance.
- Possible configuration options:
- Lifecycle/event hooks -
onClick
,onChange
,onBlur
,onFocus
, etc.
- Lifecycle/event hooks -
Optimization and deep dives
With the basics of the component covered, we can now delve into specific areas that may require special attention. It is important to note that due to time constraints, it may not be possible to cover every area, and not all areas may be highly relevant to the specific component at hand.
Showing knowledge about these areas and being able to dive deep into them are traits of senior front end engineers.
User experience (UX)
UX might not fall squarely under engineering but good front end engineers have good understanding of UX and building UI with great UX. There are too many UX practices to be aware of, but the most common ones/low hanging fruits are:
- Reflect state of the component to the user - If there's a pending background request, show a spinner. If there's an error, make sure to display it instead of silently failing.
- Display an empty state if there are no items in a list, instead of not rendering anything.
- Destructive actions should have a confirmation step, especially irreversible ones.
- Disable interactive elements if they trigger an async request! Prevents double firing of events in the case of accidental double clicking (possible for people with motor disabilities).
- If there are search inputs involved, each keystroke should not fire a network request.
- Handle extreme cases
- Strings can be really long/short and your UI should not look weird in either case. For long strings, they can have their contents truncated and hidden behind a "View more" button.
- If there are many items to display within a component, they shouldn't all be displayed on the screen at once and making the page extremely long/wide. Paginate the items or contain them within a container with a maximum width/height.
- Keyboard friendliness - This involves making sure the component is keyboard-friendly
- Add shortcuts to make the component more usable by keyboard-only users
- Ensure that elements can be focused and tab order within the component is correct
- Accessibility is part of UX but will be covered in a later section