From Bricks to Views: Hierarchical Architecture 101 🧱👨‍🏫

Łukasz Fiuk

Jun 16 2023 8 minutes read ⏳

Why Code Structure Matters? 🤔

In the world of agile web development, code structure is the hidden hero of efficiency, maintainability, and scalability. But why architecture is it so important? Let's see:

🐣 Readability: When code is well-structured, it's easier to read and understand. This is not just beneficial for the original developer, but crucial for any one who needs to review, debug, or build upon that code.
🔁 Reusability: A good code structure promotes reusability. When we structure our code into self-contained, modular components, we can use these components in multiple places throughout our application (and beyond!).
🔧 Maintainability: You'll have to modify, fix and maintain your code. This might become a painful experience if your codebase is messy. Organized structure reduces the chance of creating bugs in seemingly unrelated parts of the application.
📈 Scalability: Clean code is easier to scale. Consistent methodology and conventions make your code predictable and therefore easy to build upon.
🧑🏻‍🤝‍🧑🏾 Collaboration: Finally a sound code structure simplifies collaboration. It's much easier to work your teammate code, if you are all working with the same patterns.

I believe that many projects suffer from a weak file structure because it's easy to overlook or ignore this aspect during the initial stages of development. However, as the project progresses, reconfiguring the structure becomes a hell of a task that nobody has the time for. ☠️

How to do it right? Quick look at Hierarchical Architecture 🤠

Here's a little sneak peek into how I like to structure my code: 📂🪄

💾 >_ txt
/src/
├── 1_components/
├── 2_sections/
├── 3_containers/
├── hooks/
├── states/
├── styles/
├── types/
├── utils/
└── anything else that you need

As you may have noticed, the first three folders are numbered. This intentional strategy aims to visually order the most critical project folders and impose a hierarchy. 👪

The core idea revolves around partitioning the project into three main blocks. Imagine constructing a house: 🏠

1_components: Components are our foundational building blocks. They should be simple, reusable, and generic. In the context of web development, a component is a reusable, self-contained piece of code that encapsulates a piece of functionality or user interface. Examples might include a Button or a Typography component.
2_sections: Sections are like the walls of our house. Each section represents a specific fragment of the page and is composed of multiple components. They are more specific than components and often contain styles and positioning unique to that section. Examples may include a Navbar, Footer, or HeroBanner.
3_containers: Containers are the rooms in our house. Each container is composed of several sections and represents a particular view, such as a HomePage, ProductPage or ProfilePage.

This approach is dead simple, readable and allows for great flexibility both for developers, and clients. In fact, it is a simplified blend of Atomic Design, and BEM methodologies - preserving their principles while emphasizing simplicity.

Rules and Definitions 🗝️

Components 🧱

Components are the basic building blocks of the application. They are self-contained, reusable pieces of code that encapsulate specific functionality or user interface elements.

No Positioning 🔺: Components shouldn't be positioned. Their placement should be determined by the parent section in which they're used.
Simplicity and Encapsulation 📐: Components should be simple and encapsulated. All things related to a single component should live within the same folder.
Generality 🐧: Components should be generic, designed to be used in multiple contexts throughout the application.
Tested 🧪: If possible, components should be tested as they will be reused in multiple places. This will help to ensure their robustness and reliability.
Extra Care ❤️: Components should be written/edited with extra care, as they are meant to be reused in many places, possibly across many projects.

Component Folder Structure Example: 🗂️

💾 >_ txt
Button/
├── Button.tsx
├── Button.styled.ts
└── Button.utils.ts

You can group components as you see fit. For example:

💾 >_ txt
Buttons/
├── PrimaryButton/
└── SecondaryButton/

Sections

Sections are larger blocks of content made up of various components arranged together.

Subfolders for Complexity 🗂️: If a section is complex, create subfolders to split code into smaller pieces.
Composition 🧩: Aim to use composition to make these blocks more versatile.
Reuse Components 🍰: Sections should be built from reusable components, and elements specific to the section, such as wrappers etc.
Uniqueness 📍: While components are generic, sections should have a specific purpose in the application.

Containers

Containers are specific views or templates within an application. They are constructed from one or more sections and if needed - wrappers.

Built from Sections🧩: Containers should be primarily built from sections, not single components. This keeps the complexity of each part manageable and enforces the hierarchy of components -> sections -> containers.
Single Responsibility 🔐: Each container should have a single responsibility. This follows the single-responsibility principle (SRP), making the code easier to maintain and understand.
Naming Convention 🗿: Containers should be named based on their functionality. For example, a container for the homepage could be named LandingPage and template for blogpost could be named ArticlePage

Component Driven Development 🦉

Building large applications or websites isn't easy because usually there are many abstract connections and concepts that you have to constantly keep in mind. With tangled pieces and large, unfocused components, things could quickly get out of hand.

Because of this, it's a good idea to focus on individual parts of your app at a time. Take your time to build generic components, and consider creating a UI library with tools such as Storybook to work in isolation. 📚 Add tests and check if your components are up to spec. If you are using Storybook you might want to check Chromatic for automated UI tests. 🧪

Once the generic components are in place, building larger parts will be much simpler, and you'll avoid a lot of frustration ( trust me! ). While I'm aware that it's not always possible, as designs may evolve as you go, I firmly believe that striving to work in this manner is the way to go. ✨

Final notes 🐸

I think that it is important to acknowledge that there is no 'one-size-fits-all' solution. Just as every digital project is unique, with its own set of goals, challenges, and scope, the structure that best supports it will vary.

While there may be no single 'perfect' structure, the importance of adopting some form of organized structure is undeniable.

I truly believe that upgrading 'small' things such as code structure or file naming conventions had one of the biggest positive impact on my coding in general. Nice, clean and consistent code brings peace and joy to my heart and I hope you'll like it too. Happy Hecking! 👋

Comments 💬

Boosting Framer Motion Performance & Accessibility 🚅💨

Back in the good ol' days, we had to choose between fast websites or nicely animated websites. Well, those days are over, and we can have it all now 😎. And to make life even sweeter, we can also optimize accessibility of our animations with single prop 🌈

Quick note: Framer motion has great guides on that topic, so you might want to check those out instead 💀
optimizing bundle size
accessibility guide

Step 1: Replace motion tags 🐥

Framer Motion is full of features, and to be fair you're most likely not using some of them, but there's high chance that you are loading it all with motion tags 🤷‍♂️. Let's fix that by replacing all motion (33KB zipped) tags with m (7KB zipped) tag 🔥. Why m tag is so much lighter? Because it's not loading any features by default - you have to specify what, and how to load. More about that in next step. ⏭️

💾 >_ tsx
import { motion } from "framer-motion"
import { m } from "framer-motion"

//  Before
<motion.button>
   I'm just a button
<motion.button>

// After
<m.button>
   I'm super cool button ✨
<m.button>

Pro tip: use vscode "search" Shift ⌘ F functionality to find and replace all motion instances.

Step 2: Lazy Load needed features 🦋

Replacing all your motion tags with m will break your animations as we are missing essential features. To fix that, we must first re-export the necessary Framer Motion features, as shown below:

💾 >_ tsx
// Used for lazy-loading Framer motion features.
// Docs: https://www.framer.com/motion/guide-reduce-bundle-size/#lazy-loading

import { domAnimation } from "framer-motion";
export default domAnimation;

There are currently two feature packages you can load:

domAnimation: This provides support for animations, variants, exit animations, and tap/hover/focus gestures. (+15kb)

domMax: This provides support for all of the above, plus pan/drag gestures and layout animations. (+25kb)

Now let's put it all together. Open your top level component, eg. _app.tsx load features and wrap your app with <LazyMotion/>.

💾 >_ tsx
import { LazyMotion } from "framer-motion"

// Make sure to return the specific export containing the feature bundle.
const loadFeatures = () =>
  import("./features.js").then(res => res.default)

// This animation will run when loadFeatures resolves.
export const  App = () => {
  return (
    <LazyMotion features={loadFeatures} strict>
            <Component {...pageProps} /> 
    </LazyMotion>
  )
}

Strict prop will throw errors ⚠️ if you, or anyone in your team will try lo load motion tags anywhere in your app. That's good because from now on you'd like to use lighter and optimized m tag.

Step 3: Optimizing Accessibility ♿

Since your app is already blazingly fast, we might spend a minute to optimize accessibility. 🌈 Adding <MotionConfig/> with reducedMotion="user" prop, will disable all animations except opacity and background-color for users who prefers reduced animations.

💾 >_ tsx
import { LazyMotion, MotionConfig } from "framer-motion";

export const App = () => {
  return (
    <MotionConfig reducedMotion="user">
      <LazyMotion features={loadFeatures} strict>
        <Component {...pageProps} />
      </LazyMotion>
    </MotionConfig>
  );
};

Wrapping Up 🍬

That's is folks - your animations are now fast, inclusive and sweet. 🍩 Happy Hecking! ✨