Modular Feature-Driven Development: The Smartphone Pattern (OS) with React and Redux

Front-end architecture is a very important aspect I consider when developing apps. I've been developing front end since around 2007, and since then, I've been interested in software architecture concepts, design patterns, and code organization.

Once, in a code review session, I was trying to explain a certain strategy I would have liked the code would be, then a colleague told me:

Not everyone thinks the same you do. That's hard to understand.

He was right. I was trying to explain what to right and was going through all the necessary parts, but I missed one thing: showing the big picture.

This article is focusing on an approach I'm taking when designing a feature. It is only then I can refer to directory structure and follow what makes sense. My goal is to share a perspective, show a way of thinking, a Style Guide (if I may), that I follow. I think it may help others as well.

Feature Driven Development from Wikipedia states:

Feature-driven development (FDD) is an iterative and incremental software development process.

The Big Picture

I was once told it's easier if you show us rather than tell us.

There are many good articles recommending a certain directory structure, where to have what, and how to divide the code files into parts. Smartphones and mobile devices have been around for quite some time now. When I'm coding or starting to design a feature, I consider a Smart Phone as the Mental Model for the app.

Simply put, when I need to add a feature to an existing app, I'm instantly thinking where it would have belonged if it was a smartphone feature that was built into the code operating system.

That's it in a nutshell: that's how I explain the Smartphone Pattern (SPP) - but there's more to it.

Rules of the Smartphone Pattern

In a smartphone, most of these basic features are included with the device's API: camera, user, contacts, geolocation, microphone, sound, etc. Usually, when an app is installed on the device, it asks the user to approve access for a few of these APIs. Most often, the user just confirms, meaning: the app relies on the device's API and the user's approval to access those APIs. This is the perspective that I look at when adding features to an app.

Coming into the web front end development world, chances are that the basic APIs would be included within these layers:

1. Containers/Pages layer: Component that reflects a certain view that is usually bound to a URL
2. State management: Some form of state layer (Redux, react-query, etc.) 
3. Components
4. Hooks (React)
5. Utilities
6. API layer
7. Modules/features (the goal of this article)

I consider items 2-6 as the building blocks of an app: it's the base framework on which the entire app relies. Once these exist, any feature that consumes any of these would probably be consumed in item #1, Containers/Pages.

Features/Modules take the role of an app in a smartphone. Let's see how this perspective translates in a React app.

Feature-Driven Development

First, I usually keep new features in the modules/features folder (or whatever works best for the team).

A feature can expose components, hooks, or utilities. Think of an npm package that accesses directly one of the layers I mentioned before. By using and importing a certain building block of one of the layers, the app "gives" permission to the feature (the smartphone app) to use these.

A feature can do whatever permissions it is granted, like to bind a feature around a store's slice. That means:

1. Updating the app state (phone settings, user's data, etc.)
2. Share state with other features (app within an app)
3. Link to other views within the app (in a smartphone, open other apps, open browser, etc.)

A good example would be a playlist component of a music app:

<Player>
  <MediaView />
  <Controls />
  <Playlist />
</Player>

There are a few principles to notice about the Playlist module/feature:

1. It doesn't take any props, although it might to set features on/off within the playlist component.
2. It has permissions to use these layers: state, API, components.
3. We understand this feature is consumed by the Playlist component.

Similarly to an app on the smartphone, a feature may expose more ways to interact with its data, i.e:

1. Exposing a <CurrentlyPlaying /> module (widgets in Android)
2. Exposing a hook to interact with the feature usePlaylistController()

Folder and Files Structure

A feature lives within the modules/features folder. As I mentioned before, it asks for permission to use any of the existing building blocks that exist in the app.

If the feature requires a state layer (in Redux), it is the "store" folder that includes all the state definitions and clean store API hooks.

- src
  - modules
    - Playlist
      - index.ts
      - Playlist
        - Playlist.tsx
      - CurrentlyPlaying
        - CurrentlyPlaying.tsx
      - hooks
        - index.ts
        - usePlaylistController.ts
        - useCurrentlyPlaying.ts
      - store
        - index.ts
        - playlist.slice.ts

Notice the Playlist/index.ts. This is the entry point of the module. This file includes all the relevant export statements this module is exposing for the app to consume. i.e:

export * from "./Playlist/Playlist"
export * from "./CurrentlyPlaying/CurrentlyPlaying"
export * from "./hooks"
export * from "./store"

I like this approach because eventually, I would like to consume these like that:

import { Playlist, CurrentlyPlaying } from "modules/Playlist"

Organizing features with this strategy is useful for a few reasons:

1. Isolated and incremental development
2. Feature flag ready
3. Easily testable
4. Low risk in touching any of the existing app's code
5. Plug and play within the app

During phases of development, a feature may introduce new components or hooks that expose a different kind of interaction or visual elements. Usually, when there's a requirement to use or view information from the feature's store, I tend to create either a new component inside the feature's folder. Doing that, I know any aspect of that feature's state is encapsulated and saved inside this feature's folders. It becomes intuitive to search and skim through when searching for anything related to that feature.

What Is the Limit of This Smartphone Modular Development?

Usually, a feature's component would be consumed in a container/page component. Like any other strategy, there are always exceptions. For me, when a new feature is agnostic and doesn't have to rely on a state layer, it would directly go into the components folder.

A feature may not include its own "store" folder, but rather use existing store slices.

I think feature-driven development should play a main role in the software development cycle. Being able to design and implement modular features contributes to an app's architecture, stability, and testability.