Bit drives a paradigm shift in the way we structure our software and collaborate on code. Its component-based approach produces more maintainable projects and more effective collaboration. However, the power of Bit is best harnessed when you adopt a certain mindset. This blog aims to guide you through the core principles and methodologies of building software with independent Bit components.

An image of a demo Bit organization working on a developer portfolio site, composed entirely of autonomous components

Principle 1: Build for the present, not for vague future needs

Bit components are easy-to-understand, reusable units of code with transparent dependency graphs. When you build software as a composition of Bit components, you inherently future-proof your codebase without any extra effort.

Interestingly, the most effective way to leverage Bit’s future-proofing capabilities is to focus solely on present needs. This approach not only prevents the wasteful allocation of resources on speculative future requirements but also enforces “dogfooding” or “eating your own dog food”.

By using the components you create, you validate the component’s functionality and reliability, thereby increasing overall confidence in the component’s utility for future projects.

The “building for the present” principle extends beyond just the number of components you build. It also entails limiting your components’ API and functionality to the current needs. Over-engineering a component’s API with features that are not currently needed can lead to a bloated, less maintainable component and, as mentioned above, even less reliable (since it's not fully tested by its maintainer).

Principle 2: Start from the most concrete component

The order of component creation/composition corresponds to the feature’s dependency graph

When rolling out a new feature or app, it’s best to start your development with the most concrete component and then work your way to more generic components.

For instance, if you’re constructing a new form, start by creating the ‘form’ component itself. From there, identify the components it requires. Search for existing ones on bit.cloud and use them in your form. If you can’t find what you need, extend existing components or create new ones.

This process continues recursively until you have all the components you need to compose your feature. For instance, if you can’t find the date picker you need for that form, create it, identify the components it requires, search for existing components, and repeat the process. The “base case” for this recursive process is when you reach the most concrete component that answers your current needs. This approach ensures a focused and efficient development process and promotes the reuse of existing components.

It’s worth noting that components are valuable even when they are not reusable. Concrete, specific components that serve a particular function within a feature or application are equally important. They contribute to the modularity and maintainability of your project, even when they are not reused in other places.

Furthermore, component development is an iterative process. A component that starts as a concrete, specific solution can evolve into a more reusable asset as needs change and grow. Over time, you may find that what began as a highly specialized component has gained features or attributes that make it applicable in a broader context, thereby naturally transitioning from a concrete to a reusable component.

Principle 3: Align component names with business objectives

An image of a demo Bit organization working on a developer portfolio site, composed entirely of autonomous components

Adopting a business-centric mindset is crucial when constructing, naming, and organizing Bit components. Component names should be descriptive and closely aligned with the specific business needs they address. Similarly, components should be organized into scopes in a manner that reflects their business structure and functionality.

This business-oriented naming convention serves multiple purposes. First, it makes the codebase more accessible to all stakeholders, including non-developers such as designers and product managers. This fosters a more inclusive and efficient collaboration, with an increased feedback loop among all team members.

Second, properly-named, business-centric components make component dependency graphs easier to understand, which, in turn, makes it easier to refactor code, identify, and resolve bugs.

Lastly, a business-oriented naming convention makes it easier to find and discover components, which, in turn, promotes component reuse and saves time and resources.