Last year, several React Native related projects of the company were upgraded. It has been a while. Here is a systematic review of the whole process before.

background

When I came to the company before, I found that the company still used the 0.40 version. As far as WE know, the project was done early at that time, the navigation used the own routing library, and the state management used MOBx. Although I had experience with React Native before I came to the company, the official recommended to use React navigation instead of the original navigation library. The previous project was relatively small, and state management was not used. React-native code-push was also not used, but I only knew something about it.

At the beginning, it was painful to take over the project. The business logic was much more complicated than before, and some codes did not fully know what the meaning was and did not dare to move. However, after a period of time, I got familiar with the surrounding ecology of React Native. After a couple of sessions of requirements, I figured it out. Fortunately, it wasn’t the old createClass code, or it would have been more difficult to modify.

Because the version used is earlier, and the higher version of Android has some restrictions, it is sometimes difficult to debug. My old mobile phone became the only test machine due to the lower version of the system (Android 6.0) (the higher version cannot be shaken for debugging).

I love and hate this phone. I love it because I can debug it, and I don’t have to pack it when THE IP address changes like iOS does. I hate it because debugging takes a lot of time, and you can see the transitions sometimes. If you’ve seen Zootopia, you remember the sloth. React Native lists have poor performance, and the project uses lists in many places. Complex business requirements make the navigation library difficult to use, and personal debugging is also very difficult.

Technology research

Because there are many projects involved, and the version span is relatively large, so the research must be more serious and comprehensive.

I read all the blog articles about React Native on the Internet over the past year (Google + Baidu +GitHub + technical QQ group), collected targeted blog posts about upgrading the pit, and read all the relevant technical blogs I have collected since I was rn. As far as possible to achieve full coverage of all aspects of the current online all relevant content.

Then I summarized a react-Native upgrade research document, including API changes, logs of several major updates, important points related to the upgrade, several libraries involved, some issues that may need to be considered, and reference links (more than 40).

Version update

Version upgrade is the first issue to consider, if this is not possible, other work will not be carried out, and version upgrade needs to consider multiple aspects:

  • androidand
    iOSWhat is the ratio of users to each system? There may also be resistance to upgrading to RN if there are too many users of the lower Versions of Android and Apple.
  • react nativeHow does the version itself change? What is the status of its own refactoring plan?
  • Third-party library pair
    react nativeDoes the version have special requirements?
  • androidand
    iOSAre there special requirements for build tools, ides, and so on for the aspect? native
    xcode/
    Android SDKVersion, Android and
    iOSThe corresponding version number
    APIThese are all things to consider

After actual research and communication with native developers, the final version to be updated was determined. Because the latest version of React Native is so new, many third-party libraries haven’t been updated yet,

Third Party library:

Because each project is different, use of third-party libraries is different also, but in original package. The json is most comprehensive, third-party libraries in each analysis when I found some libraries may initially used, since the business change, then no use, will be those who don’t use the library all deleted, so can reduce search range, reduce the workload. React-native Project Configuration

The next step is to make a situation statement table of the latest version of the package used by the current involved project that needs to be changed, including the name, version, address (for the convenience of others and subsequent view), major updates and other contents. Most of them are fine, with only a few libraries stopped being maintained, some of them being converted from the original API to a separate third-party library, but usage is largely unchanged.

The project is familiar with

Because I have been in contact with a lot of the project that is often changed, I am basically familiar with the code. For several other projects, I need to find relevant accounts for testing, and ask the product owner to understand the product requirements. After running roughly, I am also familiar with the code logic.

Due to various reasons, there were some repetitions in the early code and some areas that could be improved. I started to optimize the code when I knew react Native needed to be upgraded. Remove extraneous code, add comments, extract common style components, and so on, as a way to familiarize yourself with the project’s code. The advantage of this is that you don’t need to change as much code for later upgrades, and it also simplifies the code.

The demo first try

To be safe, after determining the React Native version, I first wrote a minimal demo containing all third-party libraries. Every time a library was installed, I wrote codes that used the same functions in the project to ensure the practical feasibility of basic functions, and submitted the codes to the warehouse after each function was completed.

This way, if the newly installed library fails to run the APP due to a code change error, you can go back in time. This is especially true when changing the Android folder code. After all, you spend most of your time changing JavaScript code, and you’ve forgotten all the familiar things you learned when you first learned React Native.

After the function is basically feasible, android and apple phones have been running for the most part, and there are no major problems, we started to formally change the code.

The code

Before the upgrade, a new branch is established. During the upgrade, new requirements are not updated at the same time (the old and new functions are done at the same time). After the upgrade, they are updated together.

Write special code replacement document, convenient for other development reference, reduce workload. In the document to write the old and new code comparison, such as navigation jump parameter transfer, introduction of changes, you can directly delete the source code, copy and paste the new code.

There are several common substitutions, as well as a few possible bugs, such as the @2x or @3x image name error in React Native when the image component loads static resources.

Information synchronization

This update is closely related to the native end, and synchronization of information is very important.

After going through all the updates from 0.40 to 0.59, document them and mark the key parts so that the native side can see if there is anything relevant to them. Some places are not very understand, need the other party to do a general judgment.

Update documentation during the upgrade to provide all documents that may be needed. All relevant documents in the whole survey will be updated to the company’s knowledge management platform.

test

List the changes in several projects to make it easier to focus on testing related functions. After important functions are correct, test various models, and then fix bugs. We had some problems, but fortunately, we had a lot of problems, and you can see what happened.

conclusion

I was worried at the beginning. After all, there were many projects involved, and the version span was so large that what I saw on the Internet was basically a small version upgrade.

This time, due to sufficient upgrade time and sufficient preliminary research preparation, there was no serious delay in progress. It is that there is a lot of business logic in the project, some small places are omitted after the change, and these hidden bugs were found in the later stage.

Generally speaking, the amount of code changed is not very much, mainly in the react-navigation route summary, jump parameter passing, Flatlist and other places. It also takes a lot of time to coordinate with iOS and Android.

Due to the epidemic, I had to work at home, but the APP was updated as usual, which made the code that had not planned to update and upgrade had to be updated along with it. During this period, some bugs were found temporarily because of different environments, and it was troublesome to debug.

Before on the Internet to find a lot of documents, thank you for sharing, here also summarizes their own situation, I hope to help you.