Weex Practices based on VUe2.0 (Front-end Perspective)

19 year goal: Kill English! I opened a new public account to record a programmer learning English experience

If you want to improve your English, you can follow the public account: CSEnglish programmer learning English, spend 10 minutes every day to hand in homework, learn English with me

---

Premise: During this period of time, several weeX pages written by we of the company have been reconstructed with VUe2.0, and weexSDK of the client has also been updated to version 0.10.0. This article will cover some of the differences between the old and new versions in the front view. A practical article from the old version of we

Weex – vue – 0.10.0 render v

Ios weexSDK 0.10.0

Android weexSDK 0.10.0

Compile the Vue file

In the era of we, we can easily compile the business code text.we file with the help of Weex-Loader and Webpack to get the js required at last. However, in the era of VUE, we need two loaders, Weex-Loader and VUe-Loader. For company access, we are not likely to use the scaffolding tools provided by the official, and generally implement them by ourselves. There is also a loader called Weex-vue-loader, which generally does not need to be manually invoked by developers.

Weex-loader and VUe-loader are used during build or dev phases.

/ / native end use js weexWebpackConfig module. Loaders. Push ({test: /\.vue(\? / ^? +)? $/, loader: require.resolve('weex-loader')
})
weexWebpackConfig.output.filename = '[name].weex.min.js'
Copy the code

/ / h5 end use js vueWebpackConfig module. Loaders. Push ({test: /\.vue(\? / ^? +)? $/, loader: require.resolve('vue-loader')
})
vueWebpackConfig.output.filename = '[name].min.js'
Copy the code

For the native end, we use weex-Loader to compile the VUE file. In weex-Loader, if the file is detected to be a VUE, weex-VUe-loader is called. For H5 end, we use the vue-loader officially provided by VUE to compile VUE, and we distinguish the compiled file name for easy identification.

One of the things that can cause problems for people implementing scaffolding themselves is that we need to add a comment that weexSDK recognizes as vUE.

var bannerPlugin = new webpackG.BannerPlugin(
    '// { "framework": "Vue" }\n',
    { raw: true }
  )
webpackConfig.plugins.push(bannerPlugin);
Copy the code

Source: Official documentation

Source dependency management

Our business is multi-page format, so it is very easy to access WEEx. In each page, the js file is introduced after the page is compiled by VUE. Vue and WEEx-VUe-render are introduced as common resources. Because we need to customize some modules such as error collection with native side, we choose Vue, WEEx-VUe-render and customized modules and Components as source management. Unified package into a common file in H5 side reference.

This is what we did in the time of we. The vUE era remains the same in general direction, with minor adjustments made to the entry file.

import Vue from 'vue'Window. Vue = Vue /** * register Component ** // import TestComponent from'./components/test/test.vue'
// Vue.component('test-component', TestComponent) /** * module ** / require('weex-vue-render')

// shopBase
import shopBase from './modules/shop-base'
window.weex.registerModule('shopBase', shopBase)

// shopModal
import shopModal from './modules/shop-modal'
window.weex.registerModule('shopModal', shopModal)
Copy the code

We can see that component and Module are registered by WEEX, but in the vUE era, our Component will be registered by Vue. Note that HERE I have mounted the VUE under the Window object, because in the business code of the respective page, We need to instantiate Vue in our entry JS, using Vue objects.

Require (‘weex-vue-render’) the weex is mounted under the window object.

The specific component writing has now been completed into the writing of vUE files, students with VUE experience will get started in one second.

The specific module writing is also much simpler than before, export an object containing module methods, and then call weex.registerModule to register. It should be noted that the new html5 extension does not cover how to write callbacks. The rules for callbacks are the same as in the old version

const shopBase = {
  isOnline: function (callbackId) {
    const sender = this.sender;
    let hostname = window.location.hostname;
    let result = false;
    if (hostname.indexOf('showjoy.com') !== -1) {
      result = true;
    }
    sender.performCallback(callbackId, {
      data: result
    })
  }

}
export default shopBase


// another js

window.weex.registerModule('shopBase', shopBase)
Copy the code

The transition of the viewport

This part of the content of the principle of the explanation is a bit convoluted, students who do not know about viewport adaptation can first read some of my previous article viewport-and-flexibleJS

For those of you who have developed the we page, weeX-HMTL5 weeX does not deal with multi-screen viewport adaptation, and the framework leaves the job of viewport adaptation to the flexible. Js for rem viewport adaptation. We need to introduce a flexible. Js script when writing pages on the H5 side.

The flexible. Jsrem adaptation is replaced with a 750px fixed viewport for the weex based on the vue2.0 version. The layout ViewPort is 750px on any screen size, so I’m writing CSS with a width of 750. The only difference is that we don’t need to write px now.

I went through two iterations of Weex-Vue-Render while refactoring the WE page, one v-0.2.0 and one V-0.10.0.

The handling of the viewport has also been changed in both releases, and we have experienced some of the effects of iteration on business code.

In WEEx-vue-render V-0.2.0 version and WEEX-HTML5 old WEEX version we can in HTML file is not need to write meta[name=viewport], framework will automatically help us to calculate the page need viewport information.

Weex-html5 uses flexible to accommodate multiple screens, which goes without saying.

Weex-vue-render V-0.2.0 adaption is shown in the following code:

Const DEFAULT_VIEWPORT_WIDTH = process.env.viewport_width is injected at build timefunction parseViewportWidth (config) {
  let width = DEFAULT_VIEWPORT_WIDTH
  if (config && config.width) {
    width = Number(config.width) || config.width
  }
  return width
}

export function setViewport (config = {}) {
  const doc = window.document

  if (doc) {
    const viewportWidth = parseViewportWidth(config)

    // set root font-size
    doc.documentElement.style.fontSize = viewportWidth / 10 + 'px'ScreenWidth = window.screen.width const scale = screenWidth/viewportWidth const contents = [ `width=${viewportWidth}`,
      `initial-scale=${scale}`,
      `maximum-scale=${scale}`,
      `minimum-scale=${scale}`,
      `user-scalable=no`
    ]

    let meta = doc.querySelector('meta[name="viewport"]')
    if(! meta) { meta = doc.createElement('meta')
      meta.setAttribute('name'.'viewport')
      document.querySelector('head').appendChild(meta)
    }

    meta.setAttribute('content', contents.join(', '))}}Copy the code

    const screenWidth = window.screen.width 
Copy the code

This statement is one of the key points of this adaptation script. It is intended to get the Ideal Viewport of the current phone screen. In most cases, window.screen.width can get the Ideal viewport of the screen, but a few android native browsers get the wrong value. Under normal iphone6 conditions, this script would get the value:

'width=750', 'initial-scale=0.5', 'maximum-scale=0.5', 'minimum-scale=0.5', 'user-scalable=no'Copy the code

However, on some Android phones, the browser will get the wrong screenWidth and get the wrong initial-scale, which will cause problems with the screen display. So weex-vue-render V-0.10.0 changes the implementation of this script, but at the cost of adding a meta[name=viewport] tag to the HTML file.

The need to add this tag is not reflected in the update log, but only in the example of the official website to modify the demo implementation, which is blocked by this trap…

Now let’s take a look at how the Ideal Viewport of the device is obtained in Weex-Vue-render V-0.10.0, which explains why we added this tag in HTML.

We see the source code directly modify part, here. Will the window screen. The width change into the document. The documentElement. GetBoundingClientRect (). The width

In plain English, get the width of the HTML on the current screen,
tag width=device-width together this tag sets the HTML width to device-width, which is the ideal Viewport width of the device. And this value is always true. The resulting viewPort will be 750px wide on all devices.

There is also a bug in version 0.10.0 that causes us to get viewport values of undefined if we manage Weex-vue-render in source-dependent mode instead of script mode.

The reason is that the main field of package.json in the Weex-vue-rendernpm package points to “main”: Let viewportWidth = process.env.viewport_width SRC /render/vue/index.js There is no documentation stating that we need to set the environment variable process.env.viewport_width to 750 when compiling with weex-vue-render. So the compiled viewportWidth variable must be undefined.

Check it out at NPM I [email protected].

One solution is to point the main entry to a file compiled by Weex-vue-render. The second option is to add this environment variable while we manage the source code ourselves.

The 0.10.0 SDK supports relative addresses and auto-completion

Relative address auto-completion is not supported in 0.4.0 version SDK, and our front-end students write jump routes or API interfaces in the way of relative address when writing business logic.

For example, an API request

stream.fetch({
    method: 'GET',
    url: "/api/shop, type: 'json' }, function (response) {})Copy the code

The H5 browser will automatically concatenate the host of the current domain name, while the Native end will only get the relative address request. The approach of our native party is to manually join the host domain name required before the network request to complete the network request.

However, the native WEEXSDK supports incomplete relative addresses starting from version 0.9.4.

Support relative URL, which will resolve real URL by bundle’s URL.

But the pit is not in line with our business scenarios. Because the SDK auto-complete host is based on the URL of the JS bundle.

Such as our js bundle addresses cdn1.xxx.com/js/weex.js, but need to request the address of the interface in the business is shop.m.xxx.com/api/getContent

Problem is that we are in. Vue page write interface is a relative address/API/getContent, so weexSDK will be transformed according to bundle the host relative address, became cdn1.xxx.com/api/getContent, interface request 404.

Therefore, at this time, Native side needs to write their respective handler and adapter, rewrite their network request, and then register in weexSDK. This means that Native side needs to complete the URL before the SDK is incomplete, without leaving the opportunity for SDK to deal with.

The issue of this problem

summary

This is just an initial attempt to migrate to the VUE era, but the groundwork has been laid and more services are now available. There are a lot of things that have been considered in H5 that need to be reconsidered from a WEEx perspective in the future.

This article is from Nanyang, if you need to discuss anything, feel free to contact me, especially viewport related content.