Background confessed

At the beginning of the NJ project, the team’s technology stack was mainly based on Vue, and the Vue-like WEPY was chosen as the technology choice. After iterating several versions, mpvue came out. After a simple investigation, I planned to develop some pages based on mpvue-simple. If it is feasible, I will slowly switch to other pages.

The first appearance of Taro

After a while, TARO came along and made a brief comparison between Weby, MPVue, TARO, and native component development based on the team. LB at the early stage of the project is part of the wepy precipitation, but the basic can get rid of the historical burden, restart the new business projects, for the project itself is just a small application project activities, do not consider the situation of the diverse in terms of choice of technology for various technical scheme is basically solve the problem of development and in the comfort of the development process of ascension. As far as the current situation of the team is concerned, after discussion with several partners, the development is still based on WEPY scheme.

How do I migrate Taro to Wepy

NJ project itself is still based on WEPY. When iterating the function, the product proposes to build an activity page, which may also be used in the mall mini-program. Then NJ continues to iterate the function, and what needs to be considered is how to reuse the activity page developed by the project team of the mall (the mall project is based on TARO).

  • Jump to the mall small program to participate in the activities [pass]
  • Copy the compiled files of the active page into Weby for direct use [cool]

As shown in the figure, the above files and unnecessary pages can be deleted directly, and then configured to route to the app.json of the WEPY Project. In fact, there may also be some parent logic placed in app.js, which depends on your own business situation. Our project also introduces DVA, and adds a file to process DVA in WEPY app.js. This migration process is generally much simpler and easier, so I won’t describe it too much for the moment.

How do I migrate Weby to Taro

For a simpler migration, a plug-in is written to handle the common business, and the business logic can be handled separately in callbacks, as shown in the wepy-plugin-migratetotaro

The NJ project runs stably online after a long iteration. At the same time, another line of business is TARO based development, which is also in frantic iteration. Due to an activity, XX project development activity content, NJ project normal demand development, but the development online need to reuse the activity page developed by XX project.

Since Wepy2 is still in alpha, 1.7.x is also experiencing a number of issues in development. Although the problem can be solved in the end, and the author is very good at communication. After consulting several times, the problem can also be patiently guided and answered. Thank you. In addition to the actual situation of the project, after the migration, it is necessary to ensure that the independent compilation of WEPY from TARO related projects can run normally.

Directory structure convention

- Taro
    - src
    - Wepy
        - src

Code Management manages the WEPY Project in the form of submodules in the Taro Project

git submodules

> git submodule add <taro project url> # initialize local. GitModules file > git submodule init # synchronize the source of the submodule > git submodule update

. Gitmodules sample

[submodule <submodule_name>]
    path = <local_directory>
    url = <remote_url>
    branch = <remote_update_branch_name>

The migration process

By default, configure the compiled directory for wepy (it is recommended that you configure it to a subdirectory at the same level as the compiled directory for taro). Taro compilation directory dist is used as an example, and wepy is compiled into the dist/wepy directory.)

  • Compile the target path to configure weby.config.js target

  • Install plugin wepy-plugin-migratetotaro (to be developed and released)

    • Load mechanism require(‘app.js’) $ The instance (BASE)
    • Pages automatically configure all, you can manually configure the need to introduce the Pages, but the compilation will compile all, the compilation process is not controllable. There are some problems with the introduction of temporary control of some pages. It is suggested to manage page resources by taking page as the dimension in the development process. Pages that are not needed after compilation can be deleted manually.
    • The page path configuration automatically updates the jump path (BASE) of the pages in the incoming path according to the last folder in the compilation path.
    • All routes are added to the sub-module route or the route in the main module is configured in two modes, the Pages mode and the SubPackages/Pages mode. The corresponding configuration location is inconsistent, which is handled by plug-in compilation.
    • The Taro component is used in Weby, and the new NeedComponents configuration in the configuration requires the use of the component’s components and pages.

Problem analysis during migration

① annot read property ‘$ pages’ of undefined

$instance {this.$instance.$pages["/" + pagePath] = if (typeof pagePath === "string") {this.$instance  page; } // this. instance from $createApp let app = new AppClass (); if (! this.$instance) { app.$init(this, appConfig); this.$instance = app; this.$appConfig = appConfig; } // appClass is derived from the corresponding app.wpy // If the page is to be executed separately, you must load app.wpy.

② Resource reference. It is recommended to use relative path reference for resources such as pictures and videos. If the project has an absolute resource path, it can be manually replaced by plugin callbacks

Taro component sharing, see the following Taro component sharing method

How do I use Taro written components in Weby

This feeling of waiting for code to intrude can be handled using environment variables, only with the introduction of plug-ins that take effect at migration compile time. We use the plug-in to introduce this when we need a page after customizing the bottom tabbar.

  • The demo component from the TARO project is introduced in WEPY Page

    config = {
    ...

    usingComponents: {
        'demo': '/components/demo/index'
    }

    ...
}

  • A component is used in the template

    . <demo compid="demo"></demo> ...

  • The parent page passes parameters to child components (used in conjunction with plug-in configuration NeedComponents, similar if native applets or other frameworks need to use Taro components)

    // Change props and compId taro. PropsManager. set({... props }, compId );

Thinking about

What is the problem that Wepy Taro solves? For me. One part is pursuing similar solutions that fit into the team’s current technology stack. Part multiterminal demand (the latest data integration, this small program is multiple products including before a product is H5 foreign may WeChat applet is not the right choice, one is a small program, if together, subsequent applet partial page may also go directly to the H5, follow-up may also data to be integrated into existing APP, Such a turn to RN is also the future demand), this part is for the future to do consideration, or else it is native to the natural. More should be thinking among this, is just for the current products we choose a suitable technical solution, don’t hold a certain plan all the, also not resistant technology updates, more is needed in this business continuously precipitate out something in the process of accumulation, and constantly update their knowledge warehouse, this is the next part of the stick to perfect.

The resources

Wepy-plugin-migratetotaro This is an unrelated reference that you can scan for WeChat