React components naming convention
![](data:image/svg+xml;charset=utf-8,<svg width="800" height="598.9150100596386" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
Photo by https://unsplash.com/photos/POMpXtcVYHo
How we scaled our React large app
There are only two hard things in Computer Science:
cache invalidation and naming things.
— Phil Karlton
Our application is divided into 2 products: A line platform (private) and
A Community (public).
A Community (public).
Those products share the same code base and most of the time the same components, in a set of 300+ React Components.
We needed to find a good naming convention to prevent complexity and technical debt.
Choosing or “creating” a naming convention is hard because:
- it should be understandable by everyone
(no EntityForListItem) - it should be simple to use
(no SimpleBeanFactoryAwareAspectInstanceFactory)
Bringing these requirements to the technical level results in :
- making component responsibilities understandable in a glance
- describing the component “type”
- describing component product belonging
- making component easy to find (file name coherence)
Here how our naming convention works (well).
The convention
[Domain]|[Page/Context]|ComponentName|[Type]
Parts surrounded by “[]” are optional. ⤴️
Examples:
“The Domain”
Which product owns this component?
The domain basically refers to the product scope.
In our case, when missing, this means that the component can be present in any product.
It’s the case of the Sidebar or Navbar components.
It’s the case of the Sidebar or Navbar components.
“The Page or Context”
what is the parent component?
which product subpart/page this component belongs ?
which product subpart/page this component belongs ?
In case of a “root component” — a component without a parent, directly instantiated by a <Route> — we sometimes add the product page where this component is expected to be.
In the other cases, if a component can be found in many “pages” of a product but only inside another component, we add a “Context”, basically the name of the parent component.
If the component is nested in more than one other component, we only keep the closest one to avoid redundancy.
Example: ChatConversationName is not SidebarChatConversationName
If the component is nested in more than one other component, we only keep the closest one to avoid redundancy.
Example: ChatConversationName is not SidebarChatConversationName
When missing, we expect to find this component at a “root level”.
How to name a Component
The name of the component refers to its responsibilities, in short
“what this component do ?”
The Sidebar component is a Sidebar.
The ACommunityAddToShortListButton is a button component of ACommunity responsible for adding profiles to a shortlist.
The ChatConversationName component is only responsible for displaying the name of a chat conversation.
Component types
For now, we identified only 5 types of components:
- View component: only display a rendering of data (no API calls or internal actions)
- Button component: only display an actionable view
- Connect component: legacy connect components
- forms components: Input , Upload , etc …
- in case of HoC components, we add Component to the wrapped component, and the HoC take the original component name
This avoids the components consumer to know the underneath HoC complexity.
When missing, we assume that a component is a View component by default.
Last words
This convention helped us to grow our big SPA very fast without a coherence issue.
And more, it’s fully compatible with Sublime/VSCode fuzzy search! 🌟
Going further
For a language and framework agnostic article on naming,
I highly recommend this article: Software Complexity: Naming
I highly recommend this article: Software Complexity: Naming
We use cookies to collect statistics through Google Analytics.