From Mind to Screen
Creating and building anything is a process. Whether your process is lengthy and meticulous or spontaneous and abstract, each of us follows our own creed. When it comes to designing React <Components />, while each is unique, they share some philosophies. This is my quick and dirty guide on which of those philosophies have reigned supreme in my design choices for creating them.
The beginning of the design process is often the most difficult moment. Your first questions to yourself can be the difference between building something you are proud of or not, and may also save you refactoring in the long-run.
What is a component and why does this need to be a component?
While this might not be the first question you always ask yourself, it is good to remind yourself of what exactly you are venturing into. Tackling the first part of the question is easy; components are partitions divided to separate out a project into easily maintained and distinguishable parts.
Now, let’s focus on the second part of the question. Take a moment to imagine scrolling through a file with over one-thousand lines of code. Just the thought of it can put strain on even the most veteran of developers. Separating logic into smaller components helps reduce this strain and helps to simplify your code base.
Heavy lifting now out of the way, let’s focus on boiling down a component’s design to understand what your component really needs.
Is your component presentational or a container?
Initially coined by Dan Abramov, these terms were later described as dumb and smart.
Presentational Components
- Display Focused
- Simple and Unaware of State
- Singularly Focused on its Goal/Concern
Container Components
- Informed and Data-rich
- Gathering Data and Formatting it
- Think of Warehouses
Next, we should think about our design for the structure of your components. Does your component fit into a depth or breadth structure?
Depth: Data trickles down through a vertical structure of child components.
Breadth: Data is disbursed to a horizontal structure of child components.
Knowing where the component fits in our structure we then ask: What does our component do? How does it behave? With that in mind, we can then decide upon the separation of concerns or responsibilities. Subjectivity comes into play here, do methods within a component each have their own specific duty, or do some functions contain multiple duties. While going through this process it is important to recall existing components and functions. How can we incorporate them or refactor them to apply in this situation. Segueing into our next design choice, we should ask ourselves if this component completes a duty we are looking to repeat in the future as a pattern.
Certain patterns arise within our code that can be recognized, and benefiting from that awareness is a key skill developed through the design process. Utilizing knowledge of repeating components is part of this. Will our component we create have further use down the road of development, or is it a specified and singularly tuned cog.
I received some advice when I first began coding that I always try to remember during the creative process of development:
Writing code is easy; designing eloquent, useful code is hard.
This quote illustrates the difference between mindful and thoughtless coding. Anyone can plow through development; however, dedicating time to your designs and conventions can help avoid hampering yourself with potentially cumbersome, inconsistent code. Following this mantra may allow better direction and clarity for you and your team’s projects.
PS. Join us at the Embassy, we’re hiring!
