Weex Practices (front-end perspective)

Function is introduced

As shown in the figure above, this WEEX practice weex the order display page. This interface is simple and can be implemented with WEEX, but also uses most of the basic capabilities provided by WEEX. It includes three-end common implementation of Component, moduleshopBase, extraction of WE file component, A link jump, list component use, development and three-end debugging, etc.

Source code management and Web expansion

In WEEx, we talked about components and the module Module, which is not the same as a typical front-end framework talking about components. For example, in VUE, we separate out some of the more generic UI objects and refer to them separately. We call these separate logical UI objects components. However, WEEX needs to ensure that the three ends are consistent, and the common logical UI implemented by the three ends is called a component. To ensure the consistency of the three terminals, you need to implement one version on each of the three terminals, and register each component in its SDK using the weeX capability. I’ll just call this type of component a low-level component (homegrown)

After the three ends are implemented together and the lower level components are registered, the upper level. We can separate different lower level components and combine them into new components for reuse, let’s call this type of component the upper level components. Officially provided upper-layer components.

Weex has encapsulated and implemented most of the practical lower-level components, such as image, input, and text. However, in business, we need to customize some components and modules. In this practice, We work with Webpack to manage weeX source code WEEX-HTML5 as well as custom Components and Modules.

Weex – the extend directory

[weex-extend] | -- .babelrc | -- .eslintrc | -- .gitignore | -- LICENSE | -- README.md | -- [bin] | | -- dist-browser.sh  | -- [demo] | | -- [build] | | | -- index.js | | | -- test.js | | -- demo.png | | -- index.we | -- [dist] | | -- weex.js | | -- weex.min.js | -- index.html | -- package.json | -- postcss.config.js | -- [src] | | -- [components] | | |  -- [a] | | | | -- a.js | | -- main.js | | -- [modules] | | | -- [shop-base] | | | | -- README.md | | | | -- index.js | | | | -- package.json | | | | -- style.less | | | -- [shop-modal] | | | | -- index.js | | | | -- style.less | -- webpack.config.js | -- webpack.transform.config.jsCopy the code

Where main.js is the main entry file used to register components and modules.

// import the original weex-html5.
import weex from 'weex-html5'

import shopBase from './modules/shop-base/index.js';
import a from './components/a/a.js';
import shopModal from './modules/shop-modal/index.js';
// install the component.

// base module

weex.install(shopBase)

weex.install(a)

weex.install(shopModal)Copy the code

[demo] is used here to test the component and Module you wrote

In this project, you can update the weeX-HTML5 and custom Components provided by the administration. Weex. js and weex.min.js in the [dist] folder generated by webPack are used in the test environment and production environment respectively.

Note the 0.4.1 versionweex-html5Does not containComponent, need to register manually.

three-terminalComponent jump convention

In the officially provided playground-demo, a new page is opened and the push method of navigation module is provided. However, many judgments have been made on the URL of the opened page, aiming to set different values for THE URL according to different platforms. The URL at the H5 end corresponds to the page address. On the native end, jsBundle files corresponding to weeX pages are available.

If this is not appropriate in the real business, our solution is to use all components in the. We file, and the href value of the component is uniformly written as the page address familiar to the front-end. Such as http://m.showjoy.com. For the front end, the logic of the component is to generate an A link in the page and click to jump to the corresponding page. On the Native terminal, jsbundle files need to be executed to run weex. Therefore, a configuration file needs to be maintained through online parameters on the Native terminal.

[{" page ":" order ", "url" : "https://xxx/order.js", "md5" : "323827382 huwhdjshdjs", "h5" : "http://order.html" "v" : "1.5.0"}, { "page":"detail", "url":"https://xxx/detail.js", "md5":"323827382huwhdjshdjs", "The h5" : "http://detail.html" "v" : "1.5.0}]"Copy the code

When requesting the ord. HTML page from Native’s page, Native will check whether there is a corresponding Jsbundle file locally. If there is, native will use it. Otherwise, native will download it from the corresponding online address in JSON and render it.

The benefits of this approach are obvious. When writing business code, the new page requested is written in the same way as traditional front-end development. In addition, maintaining such data in native can be used for jSBundle hot update and pre-download.

The test environment is different from the online environment

In the traditional front-end H5 environment, regardless of a link jump or API asynchronous request, we usually use the relative address, and the browser will automatically add the main domain name information, for example, The access path will be http://xxx.com/shop/commission or http://xxx.net/shop/commission test environment. But there is no such ability in native. So you need to write the full address when writing the business.

At the beginning, our tentative plan is to realize an isOnline Module method in the three ends together. The front end dynamically sets COM or NET according to the value returned by this method when writing the code, so as to distinguish the test environment from the production environment.

created: function () { let self = this; IsOnline (function (json) {if (json.result) {self.suffix = '.com'}})} //templateCopy the code

Such is to be able to complete the demand, but in the callback want value will always meet bad place, and this is not good maintenance, each page should have such logic, then through the native side, on the native side also implements the relative address can access the corresponding address of ability, the perfect solved the problem.

Customize the pop-up frame

In the early stage of the project, we extracted the upper-layer components according to the way recommended on the weeX official website to realize a modal frame. However, the performance of native frame on some low-end Android phones is poor, and it takes about 0.7s for the frame to appear after clicking the button, which makes the user wait too long for perception. That’s one, and the other is that it’s too much trouble to introduce a Component in a page for high-frequency use like Modal.

// template

Copy the code

Therefore, we try to use Module to write the bullet frame, and each of the three ends realizes the bullet frame. Add a shop-Modal project to the source management project mentioned earlier, write the popbox logic according to the Module tutorial, and finally register it in WEEX-HTML5.

'use strict' import modal from 'modals' // Since webpack is involved in the build, any resource including CSS can reference require('./style.less') here; const shopModal = { confirm: Function (options, callbackId) {const sender = this. Sender let cancelTitle = options. CancelTitle | | 'cancel'. Let okTitle = options. OkTitle | | 'sure'; Let the message = options. Message | | 'title'; // test }, toast: function (options) { modal.toast(options.message, options.duration) } } const meta = { shopModal: [{ name: 'confirm', args: ['object', 'function'] }, { name: 'toast', args: ['object'] }] } export default { init: function (Weex) { Weex.registerApiModule('shopModal', shopModal, meta) } }Copy the code

The TAB to switch

Wxc-tabbar is a tab-switching component, but the form of this component does not meet the requirements on H5. Wxc-tabbar does not refresh the page when clicking a different TAB, but instantiates a WEEX object in the current page. For our business scenario, If you click on the second TAB and click on a link in the second TAB, you will return to the interface of the first TAB.

What we want is to click two tabs, which on the H5 end will look like clicking two A links to jump to, while clicking two tabs back and forth on the Native end will not repeat the rendering of the page. For such a business scenario, the three-terminal protocol implements a loadUrl method in the basic Module, and the implementation method of H5 is to jump to a urlwindow.location.href = XXX. The logic of the native end is self-implemented at the native end.

H5 gets the data rendered synchronously by the server

Because of historical reasons, the order management page needs to use a data field that is rendered synchronously on the server, but the real DOM cannot be retrieved in WEEX, and the Document. querySelector method cannot be retrieved even by manually judging the Web environment in WEEX.

console.log(document.querySelector)  // undefinedCopy the code

window.weex.init({
    jsonpCallback: JSONP_CALLBACK_NAME,
    appId: location.href,
    loader: loader,
    source: page,
    rootId: 'weex',
    // downgrade: ['root']  // 'root', 'list', 'scroller'
  })Copy the code

There is also no entry to manually pass in data in the initialization weeX instance, so the temporary solution here is to implement a getElement method in the three-terminal protocol base moduleshopBase, which can fetch the real DOM from the Web environment in the WE file.

getElement: function (hook, callbackId) {
    const sender = this.sender;
    var el = document.querySelector(hook);
    sender.performCallback(callbackId, {
      el: el
    })
},Copy the code

In the WE file

shopBase.getElement('.j_IsOpenShop', function (json) {
    if (json.el.value === 'true') {
      self.isVisitor = false;
    }
    cb();
  })Copy the code

Synchronizing data in HTML

Copy the code

Native debugging

Weex bebug xx.we command weex bebug xx.we command weex bebug xx.we command weex bebug xx.we command weex bebug xx. So you can debug directly using the compiled bundle. Weex debug xx. Js. If you want to debug the WEEX page in your own app, you need to write relevant codes in the ios and Android app to provide debugging support. Ios Integration Debugging

The code in this article is not posted completely. If you are interested in the native part of the implementation code, please contact me on WeiboDada’s Siamese cat