Mastering Weex Build: Dual Configurations for Web and Native

Story 1: Build

Although Weex’s slogan is "write once, run everywhere," the build step differs: native builds require weex-loader while web builds use vue-loader, so two separate webpack configurations are needed.

Best Practice

Generate two bundles with webpack: a web SPA based on vue-router and a native multi‑entry bundle.js.

Assume a set of pages under src/views.

Build Web Configuration

The web entry file is render.js. (Images of the config are shown below.)

main.js

App.vue

webpack.prod.conf.js

entry configuration.

Build Native Configuration

Native packaging exports each .vue under src/views as an individual Vue instance via a Node script.

webpack.build.conf.js

generates and bundles multiple entries.

Final native output:

Story 2: Using Preprocessors

In Vue single‑file components, you can configure a preprocessor via vue-loader (see image). Weex converts CSS to JSON, so the same preprocessor works on web but not on native.

Using vue-loader configured preprocessors works on web but is ineffective on native.

Native has no global styles; importing a CSS file in JS is also ineffective.

Solution 1

After studying weex-loader, you only need to specify <style lang="stylus"> and install stylus stylus-loader. The loader is chosen automatically. For SCSS, set lang="sass" (IDE may lose syntax highlighting).

Syntax highlighting restored – perfect!

Solution 2

Although there is no global style concept, you can import individual style files.

Story 3: Style Differences

Shorthand

Weex does not support CSS shorthand (e.g., margin: 0 0 10px 10px is unsupported).

Background Color

Android views have a default white background; iOS views have no default color unless set.

Floating‑Point Errors

Weex uses a design size of 750 × 1334 px; rendering may have a few pixel errors due to floating‑point precision, which can be adjusted manually.

Nested Rules

Even with a preprocessor, nested CSS may cause style loss.

Story 4: Page Navigation

Weex supports three navigation patterns: native → weex: a native controller hosts the Weex page. weex → native: use a module to send events to native. weex → weex: use the navigator module; define a mixin for pages a.js and b.js.

Then you can call this.push(url) and this.pop() inside components.

Jump Configuration

iOS requires no extra configuration; Android needs an intent‑filter. Adding the Android platform via weexpack platform add android creates a pre‑configured project.

Android intercepts jumps via intent‑filter.

We create a WXPageActivity to proxy all Weex page rendering. Core code is shown below.

Story 5: Data Transfer Between Pages

native → weex

: pass custom fields in the option object when calling render; access via weex.config.params. weex → weex: use storage. weex → native: use a custom module.

Story 6: Image Loading

Network image loading is documented, but local image handling differs across the three platforms. Solution:

Step 1: Configure webpack to bundle image assets separately, so the bundle accesses images via /images/….

Step 2: Place the js and images folders alongside the native project (iOS mainBundle, Android src/main/assets) and extend imgloader to replace local paths.

iOS implementation:

Android implementation:

Story 7: Production Practices

Incremental Updates

Solution 1: Use google-diff-match-patch to generate diffs on the server and apply patches on the native side.

Solution 2: Follow mature React‑Native hot‑update approaches.

Downgrade Handling

Deploy a web version as a fallback; when a Weex page crashes, load the web page via a WebView, switching based on a server‑controlled flag.

Summary

Weex

leverages Vue, making it easy to adopt for companies that use Vue as their primary technology. It suits simple, low‑interaction, hot‑update‑friendly native pages.

However, native style adjustments are painful, the ecosystem is fragmented, documentation contains errors, and the maintainer team provides limited support.