Let’s write examples with Package by Feature approach on React Native

Artem Dudinskyi
Jan 18, 2019 · 5 min read

People tend to follow the code style and project structure which is presented to them in examples and later use it at work.

Team work

I see that almost all React Native examples have created with Package by Layer(PBL) approach. In PBL, the highest level packages reflect the various application “layers” like components, actions, reducers etc. It even applies to influent developers. For example you can check out these articles Todo app and Facebook Messenger clone which use it as the structure of choice.

My goal is to motivate React Native Community writing examples with Package by Feature approach

Let’s see what’s wrong with PBL from the practical point of view.

PBL has lack of modularity, vague separation-by-concerns. Each package contains items that usually aren’t closely related to each other. This structure approach is one of the major reasons causing tight coupling. It’s not only deal for huge project. For example, having Feature toggle with PBL is very difficult, because we often have to manipulate with features which are tightly coupled in our codebase.

Please ask yourself these two questions:

  • Is it easy to see all the features implemented in your project after people clone it?
  • Is it easy to understand what files are related to a feature when people decide to copy/remove/add/modify it?

Package by Feature helps you answer to those questions

PBF uses packages to reflect the feature set. It increases the cohesion within the same module and gets low coupling between packages. Package by Feature approach enables us to maintain the structure properly and also increases the readability of the code. PDF has high modularity.

I find it interesting that modularity seems to be
sensitive to what I call ‘the simple deletion test’: if the deletion
of feature X is a single operation (for example, the deletion of a
single file or a single directory), then the implementation is very
likely modular. — John O’Hanley

Here is an example of PBF on React Native

I’m not going to concentrate on details and characteristic of how to organize PBL approach on React Native because there is already a wonderful article about it. But I’m really sad that many people still don’t create project with PBF approach.

Several very practical Robert Martin’s Package Principles

CRP The Common Reuse Principle Classes that are used together are packaged together.

CCP The Common Closure Principle Classes that change together are packaged together.

PBF disadvantages

  • Sometimes it’s difficult to understand how we should organize your feature packages and understand to what package we should put our new file.
  • When you have a growing number of classes in a single package it’s some kind of a mess. You can solve such problem by identifying similar concerns (something like sub-feature) and extract package that way.

One big piece of advice though if you go down this approach: be very thoughtful about your dependencies and in particular avoid circular dependencies between packages. A good design should look like a dependency tree — with the higher level areas of functionality depending on a set of common services which depend upon libraries of utility functions etc.

What kind of approach Android Native Developer chooses?

I just want to bring all the best from my Android Native Development experience into React Native Development where I have worked for over 7 years. I saw the massive rejection from PBL on Android which was started like 4 years ago. It was like an evolutionary process on Android with package structuring. Google Architecture Samples wrote with Package by Feature(PBF) approach. So it’s very common to use PBF in Android Native Development.

The Android source package evolution looks like this:



Companies like Uber, Google, Wix prefer to use Modularised structure for Mobile Projects.


PBL makes it easier to learn library integration as all the related code are kept in the same place. But PBF approach gets more readable of your project in term of understanding how features works and relationship between them. Native (iOS, Android) developers already use this for examples and job.
Let’s write projects with PBF approach on React Native and people will have much more understanding of your code than with PBL approach.

Don `t doubt that your code style and project structure on GitHub or blogging sites have a really big impact to the Community

Additional Resources:

Principles of Object Oriented Design
Package by features, not layers
How to structure your project and manage static resources in React Native

Thanks to Alexander Buchkovsky Viktoriia Reznik László Taras Matsyk Oleksandr Dudinskyi who took time to answer questions and contribute to the creation of this article.

Twitter Facebook Linkedin Github

If this post was helpful, please click the clap 👏 button below a few times to show your support! ⬇⬇

React Native Training

Stories and tutorials for developers interested in React Native

Thanks to Alexander Buchkovsky

Artem Dudinskyi

Written by

In ❤ with📱. Android & React Native Consultant. prev: @Nordstrom @ooVoo @Lalafo

React Native Training

Stories and tutorials for developers interested in React Native

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade