This article is by IMWeb IMWeb team
This analysis, perhaps wechat students to write will be more appropriate. Here is just an experience, recording the problems encountered in the experience and some ideas.
Introduction to the
Kbone mainly provides the ability to write Web side code and compile it into small programs. The framework used on the Web side is VUE, and then provides an adaptation layer on the applet side to adapt the Web side code. For details, please refer to github.com/wechat-mini…
The principle of
The build phase
Kbone provides a webpack plug-in that continues processing chunk after the vueLoaderPlugin, adding encapsulation of applets specific methods, as well as injection of window and Document, and injection of applets configuration.
The runtime phase
When the code runs, we use DOM and BOM in the Web. Kbone provides miniProgram – Render this adaptation layer to be compatible, including cookie, history, storage, etc. Most of these API implementations are based on the event mechanism. So on the applets side, how does the code access the adaptation layer? Kbone implements the custom wX-Component, which is implemented in the miniprogram-render package. On the Web side, this component is rendered as a Web Component, and the applet side is a custom component element. The components in the node rendering logic reference https://github.com/wechat-miniprogram/kbone/blob/develop/packages/miniprogram-element/src/util/tool.js#L33
Compare other frameworks
There is no detailed comparison here, taro, MPvue, WEpy and other framework comparison, many online articles can refer to. Compared with these multi-terminal frameworks, the starting point of KBone is different, probably due to historical reasons. The multi-terminal of KBone tries to use VUE instead of React, and then provides an adaptation layer to support DOM and BOM, so that the small program side can use the capabilities of the Web side as much as possible. The target is only two ends. Other frameworks start from multi-terminal, compile to different code on each end according to the agreed development pattern, and each end provides a runtime to ensure that the code runs correctly. The main limitation of these multi-terminal frameworks is the framework itself.
Component adaptation
Most of the components mentioned above are compatible via wX-Component, and direct mapping of some DOM components to applets has recently been supported by KBone
div -> view
input -> input
ttextarea -> textarea
video -> video
If we write some DOM tags on the Web side that are not supported by the applet, kBone will directly convert them to a View, such as the text tag on the applet side. The test found that the WX-Component does not support this tag.
After moving from the Web to applets, the main use is still web side capabilities. Some attributes specific to applets will be lost after kBone transforms. For example, the image tag, the mode attribute is used on the applet side, and the image must be set to the height to behave properly on the applet side. After setting the width on the Web side, the height can be adaptive.
The style is compatible with
Dealing with slightly different aspects of a particular component’s presentation, another problem is style overwriting. After kBone conversion, there will be a set of built-in H5-XXX styles for his custom components, but after compilation, these styles have a little higher priority and will overwrite the styles in our business, which should be dealt with by the Webpack plug-in he provides. Keep this in mind when developing with KBone.
Actual combat experience
The previous small program activity page using KBONE simple implementation, the style of direct reuse before the small program style, the effect is as follows
H5
Small program
A few problems in the experience process
< wX-Component behavior=”image” SRC =” /> < WX-component behavior=”image” SRC =”” /> However, mode and other image component specific attributes will not be compiled, the image must be set to the height, otherwise the small program side performance is a little abnormal, you can see the figure above. Style overlay problem, see gap in course block above. Here is just a simple activity page, there may be other pits have not stepped, stepped students can communicate.
Development experience
How do I access kbone? For existing applets, direct access is not recommended. The compilation of KBone into the applet side will bring vue-Runtime, which increases the package size imperceptible. WXS files cannot be used on the Web side, and the public methods of the applet side that were encapsulated before need to be implemented again. Both the existing applets side state and how to share communication with the converted state need to be considered.
If it is a new project or activity page, we can still try using Kbone. After all, Kbone has officially started to invest, and it will definitely be promoted in the future. In addition to the potholes mentioned above, we also need to consider the user experience. Using the way of Kbone, on the Web side, vue-Router is used for routing. After compiling to the small program side, it will be found that the jump between pages is the same as the Web side, because we only have one page, hop route is just a view switch, there will be no native effect of the small program end cutting route. What if we also wanted to have native effects on the applet side? It can also be done. On the Web side, entry of webpack is added to multiple packaging intersections, multi-page routing is adopted instead of single-page routing, and location API is used when jumping. This API is compatible with tabBar jump and other page jumps in the small program side, and webView jump is also compatible. After using this scheme for routing, it can be imagined that the global state of our application on the Web side cannot be managed by a state management tool like VUEX, and may use storage or other methods, which I haven’t thought of yet.
So how do you start development? Several official demos have been provided for our reference. However, these demos are not out of the box. We need to add some development configuration, such as devServer, into the official webPack configuration file. Later, we can organize a set of development configuration based on the official configuration. There is a vuE-CLI-plugin-kbone package under the KBone warehouse. After the official launch, vue CLI will be used directly in the future, and the development experience may be better.
conclusion
Although KBone is not perfect yet, the small program team is also continuing to push forward, with official support, I believe that Kbone will develop.
Can step on the pit, worth a try!
reference
Github.com/wechat-mini…