"By Feature" Approach, Scaffolding React Native

There are many ways to write our React Native projects, the way you organize your project has a great impact on its quality, today we will see "By Feature", in other words "Package by Feature approach". There is also another way of calling it "Feature-Driven Development (FDD)".

‍

Package by Feature approach

Having so many forms of structure in our code we find ourselves in the challenge of how to know that we are really applying a technique or not? well in the case of React Native Package by Feature, we can solve it with a simple question.

"Elimination test", if the elimination of a feature is a single operation, then it is a really modular clean implementation or by feature. For example, if deleting a feature involves deleting only one directory, it means that it is modular, but if instead we have to go to many places to delete severe files, then it is not really modular.

But first let's talk about a couple of concepts, concepts that we are going to see very often with our clients.

‍

Loose coupling

In simple words, the Loose coupling means that they are mostly independent. If the only knowledge that class A has about class B, is what class B has exposed through its interface, then class A and class B are said to be Loose coupling, it is the opposite of the next term.

‍

Tightly coupled

In general, tightly coupled means that the two classes often switch together. In other words, if A knows more than it should about how B was implemented, then A and B are tightly coupled.

‍

Encapsulation

Encapsulation is the grouping of data and the methods that act on that data in such a way that access to that data is restricted from outside the package, or as Alan Kay describes it, "local hold and state process protection and concealment." In OOP, that means that an object stores its state privately, and only the object's methods have access to change it.

‍

Characteristics of the "Feature approach"

• The code is easier to refactor if necessary, since internally its private methods can be modified while the public ones can keep their signature and output.
• Treat each feature as an isolated implementation, seeing it almost as a separate world.
• In general, JS Imports should not be mixed between features, communication should be limited by public methods. (Do not break encapsulation)
• Possibility of Feature-flag, I term that is applied to enable / disable complete functionalities very easily.

‍

Example of a "Feature approach"

Let's use our login feature as an example, this feature will be exported keeping the principles mentioned above.

‍

Interesting challenges of the "Feature approach"

How is the code shared?

One of the simplest ways would be to create a shared folder which you can use to share utils and helpers for example. For example services like Api, Data Storage, security helpers, can go in that directory.

‍

In conclusion

In the article, I will show you how we can think when structuring React native projects and files, I hope you have found it really useful and like to subscribe for more articles, events and job opportunities!

‍

What do you think?

Share your opinion with us and your experiences, what did you think ?!

‍