Front-end Architecture: Stable and Volatile Dependencies

Front-end Architecture: Stable and Volatile Dependencies

Designing correctly the dependencies, both stable and volatile ones, is an important skill to architect Front-end applications.

Many components (of libraries like React, Vue, Angular) use the functionality of utility libraries.

Let’s consider a React component that displays the number of words in the provided text:

import words from 'lodash.words';

function CountWords({ text }: { text: string }): JSX.Element {
  const count = words(text).length;
  return (
    <div className="words-count">{count}</div>
  );
}

The component CountWords uses the library lodash.words to count the number of words in the string text.

CountWords component has a dependency on lodash.words library.

The components using dependencies benefit from the code reuse: you simply import the necessary library and use it.

However, your component might need diverse dependency implementations for various environments (client-side, server-side, testing environment). In such a case importing directly a dependency is a risk.

Designing correctly the dependencies is an important skill to architect Front-end applications. The first step to creating a good design is to identify the stable and volatile dependencies and treat them accordingly. In this post, you’re going to find out how.

Table of Contents

1. Stable dependencies

Let’s recall the example component CountWords from the introduction:

import words from 'lodash.words';

function CountWords({ text }: { text: string }): JSX.Element {
  const count = words(text).length;
  return (
    <div className="words-count">{count}</div>
  );
}

The component CountWords is going to use the same library lodash.words no matter the environment: be it on client-side, be it running on the server-side (if you implement Server-Side Rendering), or even when running unit tests.

At the same time, lodash.words is a simple utility function:

const arrayOfWords = words(string);

The signature of words function won’t change much in the future.

Because the dependent component always uses one dependency implementation, and the dependency won’t change in the future — such dependency is considered stable.

Stable dependency

Examples of stable dependencies are the utility libraries like lodashramda.

Moreover, the JavaScript language itself provides:

  • Utility functions, like Object.keys()Array.from()
  • Methods on primitives and objects, like string.slice()array.includes()object.toString()

All the built-in functions that the language provides are also considered stable dependencies. You can use them safely and depend directly upon them.

However, aside from stable ones, some dependencies may change under certain circumstances. Such volatile dependencies have to be segregated from stable ones and designed differently.

Let’s see what volatile dependencies are in the next section.

architecture clean code dependency

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Static Code Analysis: What It Is? How to Use It?

Static code analysis is a method of debugging by examining source code before a program is run. It's done by analyzing a set of code against a set (or multiple sets) of coding rules. Static code analysis and static analysis are often used interchangeably, along with source code analysis.

How to Find the Stinky Parts of Your Code (Part II)

There are more code smells. Let’s keep changing the aromas. We see several symptoms and situations that make us doubt the quality of our development. Let's look at some possible solutions.

ECS: Residential & Commercial Cleaning Services in London

ECS Commercial Cleaning Company offers remarkable cleaning services for both commercial and residential clients in London.

How to Find the Stinky Parts of Your Code (Part I)

The code smells bad. Let’s see how to change the aromas. In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most of these smells are just hints of something that might be wrong. They are not rigid rules.

Let’s Clean that Code

Reading Time: 8 minutes Writing a clean code that nobody mocks is a little difficult, but by cultivating a habit, following best practices, it is not impossible to achieve.