At my company, we are developing pretty simple React Native and sometimes mobile-only React apps. Most of them have some similar logic, such as 'sign-in by phone' flow, some payments stuff, etc., and also some similar UI-components as well.
What we wanna do is take all those modules with similar logic, which is basically reducer+actions+selectors+sagas, and move them out into some place, from which we could reuse them in our new projects. The same with UI-components.

So, my questions are: is this even make sense? How would one do that? I'm thinking about some monorepo with one package for each module in it. Would this approach fit our needs?

  • It is difficult to know if this will fit your needs, because we need some more information about your needs. We also have very little information about these components. Do you need to customize these components at all? Feb 12 '20 at 13:35
  • Well, basically, what we want is to stop copying pieces of code from one project to another, and instead, just put it in someplace and be able to install it as a package. I think those modules are going to have some kind of config — API URI and probably something else. UI-components should be customized as well, but I didn't expect it to be a problem.
    – kuzkokov
    Feb 12 '20 at 21:50
  • I guess I'm not sure what your question is. What you proposed in your last comment sounds sensible to me. Feb 12 '20 at 22:14
  • I guess, my question is more about someone else's experience of implementing such a project with common code for other company's projects. Even examples maybe. What problems can I face implementing it one way or another? How can I make those modules configurable? I think, I just don't even know where to start, so the question itself is such vague.
    – kuzkokov
    Feb 12 '20 at 22:54
  • here is the blog, which might help you:blog.bitsrc.io/…
    – Ishan Shah
    Oct 27 '20 at 5:28

Yes, I actually did something similar for my work. The context for me was that there was a particular set of utility functions (parsers, generators, readers) that dealt with a particular data structure. It did not have components or the react native logic you mentioned, but I'm sure it could handle these.

My use case:

  1. Multiple repos used a subset of this code in some utils/*.js file
  2. There are some initialising values that should be set at the start before other functions are called.
  3. Code involved business logic that could not be shared publicly

First step was to move all the code into its own folder, and start a npm package with yarn init or npm init. Reorganise the functions and exports as necessary, and expose the exports in index.js or whatever file you have set as main in package.json.

Then depending on your security requirement and organisation, you can keep this in NPM, public github, etc. In my case I saved it to a private github repo and use yarn add <githubrepolink#tag> and import in all the repos you need it.

This method however puts a single package for all the modules, and requires the end user imports what is required from the module later on correctly.


In my experience there are two problems you have to face.
The relativly easy one is the technical solution. HOW to provide the shared data. By providing the final artefacts (per component) as a JS file that could be included. Or as NPM /YARN / Whatever packages from your private repository. Or, or, or.

The interesting problem is, how to handle updates in your shared components. And that has a huge impact which technical solution is applicable.
For example if you know that you will never (really NEVER) change the API of your shared components, then each application can load the artefact at runtime from a central server. That way each application will always use the most up to date version. Still, if any application depends used knowledge about the inner implementation of a shared component and depends on it, a change in that componentn may still break the application.

Or each application uses a defined version of a shared component. That means that each project has to update their dependency to that component on their own. A new release of a shared component then means the need for a new release of that application (if they want to take advantage of the updated component).

Or you could use semantic versioning. And provide artefacts for each major release (which may contain breaking changes). Each minor or bugfix release of a component will replace the old artefact for that mayor release. That way each application will download the most current version, without breaking changes.

BUT there is a big caveat.
Those who change a shared component, do not know how it is used. That means they have to be much more carefully with changes. Also the testing of a shared component may work fine in application A but will totaly fail for application B. That means that developers of a shared component must apply a much stricter quality assurance then if every project just copies the data and therefore is responsible for that code on their own.
This includes not only API and code quality but also the quality of the documentation.

Also if the components are not cleanly encapsulated (regarding JavaScript but also regarding HTML/CSS) it could happen that a global variable or a style of a shared component is also existing in the application (with the same name, but a different content). That could totaly make the day much more interesting.

Long Story Short: The technical solution is not really the problem. There are many possible solutions to it, not all easy, but still doable.
The real problem lurks behind the danger of changing a shared component.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.