Share Code between React and React Native Apps – Hacker Noon

  • Share Code between React and React Native AppsDevelopers are adopting Higher Order Components (HOC) Stateless Functional Components, and for good reason: they make it easier to achieve code reuse, a coveted aspiration of developers.There are many articles on HOC and Functional Stateless Components.
  • But here are a few benefits to consider:UX consistency, both within an application and across devicesMake cross-cutting upgrades: improve a component and update all its uses easilyreuse routing and authorization rulesSwitch libraries (for example, the apps below uses MobX for state management, but Redux could be swapped in)I’ll focus on using HOC and Functional Stateless Components to achieve reuse.
  • It will not use routes nor multiple scenes as the focus is on component reuse.We will add a second pair of applications (React and React Native), which will reuse the components we extract.This GitHub repo branch has the baseline applications (The final result is here.)
  • You have to “see” the duplication, which might require rearranging code blocks.Applying these ideas is like moving puzzle pieces around, to find where they meet and what patterns they reveal.Let’s start by looking for duplication.Seeing DuplicationThe web and mobile applications have two main components.In the web application, App.jsIn the mobile application, SearchView.jsThe following outlines their structure.Almost the same, but the platform differences between React and React Native are in the way.The two components have similar structures.
  • But they are in the README for the GitHub repo branch.Instead, I’ll focus on the refactoring to a common SearchBox, which our web (React) and mobile (React Native) applications will both use.Extracting a Shared Component for Web and MobileFor clarity, I’ve renamed SearchInput.js, SearchResults.js and SearchBox.js to WebSearchInput.js, WebSearchResults.js and WebSearchBox.js, respectively.Let’s look at (Web)SearchBox.jsLines 2–10, 19, 20, 26, 27 are specific to React.MuiThemeProvider, a container for Material UI components, is the only direct dependency on Material UI.

Developers are adopting Higher Order Components (HOC) Stateless Functional Components, and for good reason: they make it easier to achieve code reuse, a coveted aspiration of developers. There are…

@jetrubyagency: If you don’t know this yet – you should 😉 Share Code between React and #ReactNative Apps …

Share Code between React and React Native Apps

Developers are adopting Higher Order Components (HOC) Stateless Functional Components, and for good reason: they make it easier to achieve code reuse, a coveted aspiration of developers.

There are many articles on HOC and Functional Stateless Components. Some are introductions and others describe deep technical aspects; I’ll explore refactoring existing components to create reusable elements.

You might think that code reuse is overrated. Or it’s too hard, especially when looking to share code between the web and mobile. But here are a few benefits to consider:

I’ll focus on using HOC and Functional Stateless Components to achieve reuse. You should already be familiar with the basics of React and React Native. Alexis Mangin has a good post explaining their differences as well.

There is a lot of detail in the post; I explain the incremental process for refactoring the components. But if you are already familiar with these ideas (such as HOC), short on time, or just impatient, you can jump ahead to The Payoff: Reusing the Components. (Final GitHub repo) You can see the result and how easy it is to create additional applications with the reused components.

What are Higher Order Components and Stateless Functional Components?

). I’ll comment more on this later and defer examples till later in this tutorial.

Cory House has a good introduction here.

Higher Order Components (HOC) are functions that create a new component. They wrap another component (or components), encapsulating the wrapped components. For example, let’s imagine you have a simple text box. You’d like to add autocomplete functionality. You could create a HOC and use the result as a new component.

const AutocompleteTextBox = makeAutocomplete(TextBox);

export AutocompleteTextBox;

//…later

import {AutoCompleteTextBox} from ‘./somefile’;

The Facebook documentation is here. franleplant has a detailed post as well.

We’ll use both HOC and Stateless Functional Components in a few moments.

We’ll start with a very simple application: a simple search box. Enter a query and get a list of results. In this case, we’ll search for colors, by name.

It will be a one screen application. It will not use routes nor multiple scenes as the focus is on component reuse.

We will add a second pair of applications (React and React Native), which will reuse the components we extract.

This GitHub repo branch has the baseline applications (The final result is here.). I include the full details on building the React (web) and React Native (mobile) apps in the GitHub README, but here is an outline:

https://colors-search-box.firebaseapp.com/ is a running demo of the web version. Screenshots of both are below (web, then mobile):

Refactoring to Reuse

The basics of code reuse are simple. You extract methods (or classes or components) from one code base, replacing enclosed values with parameters. You then use the result in another code base. But the mileage of the reused element is often low and maintaining the shared code can become costly.

I’ve achieved the sustained reuse by applying a few guidelines: Separation of Concerns, Single Responsibility Principle, and the removal of duplication.

Separation of Concerns (SoC) and Single Responsibility Principle (SRP) are two sides of the same coin; the main idea is that a given code element should have one primary purpose. If there is one purpose, separation of concerns is a natural by-product; an element with one purpose probably won’t mix two areas of responsibility.

Many IDE’s and developer tools can automate the consolidation of duplicate code. But removing duplication amongst similar designs is more difficult. You have to “see” the duplication, which might require rearranging code blocks.

Applying these ideas is like moving puzzle pieces around, to find where they meet and what patterns they reveal.

Let’s start by looking for duplication.

The web and mobile applications have two main components.

The following outlines their structure.

The two components have similar structures. Ideally they would share components and look something like this:

And in pseudo-code,

Unfortunately though, in the two applications, there is very little actual code in common. The components used in React (Material UI in this case) are different from those in React Native. But we can remove the conceptual duplication by first separating concerns and then refactoring the components to each have a single responsibility.

mix domain logic (our app logic) with the platform implementation and library integrations. We can improve the design if we isolate

Finally, refactoring should be done with automated tests, to ensure nothing breaks as you make changes. I’ll add some simple “smoke” tests, which can be found in this GitHub repo/tag.

Let’s start with the easy and obvious when refactoring. React is about components, so let’s separate our components. We’ll use Stateless Functional Components, as they are easy to read.

as follows:

The essence of React is a UI /View framework and that is what we now have in this component.

, no Colors, etc.

Event handling is delegated to the handlers (given as parameters), with the exception of watching for the Enter key press. But this is an implementation concern of the input box and should be encapsulated in this component. (For example, a different UI widget library might include submit-on-enter-key behavior.)

. For its refactoring, we have a few options.

(1) would look like this:

(2) fixes these concerns.

, to make the concept and reusability clearer.)

, we would have,

Compare it to the following:

, encapsulating the specific search result component it uses.

a HOC as follows.

looks more like the pseduo-code in the earlier section, Seeing Duplication. We’ll further refine it a bit later.

. But they are in the README for the GitHub repo branch.

, which our web (React) and mobile (React Native) applications will both use.

, respectively.

Lines 2–10, 19, 20, 26, 27 are specific to React.

This looks just like our pseduo-code from Seeing Duplication.

to

HOC.

. More about the children prop can be found here.

as part of the HOC composition.

We now have our set of reusable components. (Here is the GitHub repo/branch. Note, some directories were renamed for clarity.)

The Payoff: Reusing the Components

We’ll create GitHub repository search apps. (GitHub allows for API use without an API key, which is convenient for this tutorial.)

I’ll skip the bootstrapping details, but here is a summary

(It’s unit test is here.)

We’ll copy some common files, for simplicity. The GitHub repo uses webpack to copy the files, as a slight convenience improvement. Sharing files/modules across Javascript projects is commonly done with NPM or Bower. (You can pay for private module registries.) You can also use Git submodules, though they can be clunky. Since our focus is component reuse and not module publishing, we’ll do the hacky thing and copy files.)

with

the github-web app, you should see

(You can also go to https://github-repo-search-box.firebaseapp.com for a live version.)

contents to

We may have worked hard to refactor, but reusing the components to build two new apps was easy.

Let’s look at a diagram of our components:

It’s nice to see the refactoring pay off. We could focus on the specific domain logic for the new applications. We only had to define the GitHub API client and how to render repository results. The rest comes for “free”.

call is made.

It will be easier to extract components and reuse them, after you apply these techniques a few times. You may even write a reusable component at the start of a new view element, as the patterns become a norm in your coding.

Also, I encourage to look into libraries like recompose, which make it easier to write HOCs.

Take a look at the final GitHub repo and let me know how it goes with own refactoring of reusable components.

Up Next: Microinteractions and Animations in React. Please ♡ this post and follow me for updates, on Medium, or on twitter (csepulv).

Share Code between React and React Native Apps – Hacker Noon