preface
Recently, the company launched a new (stepped on) cross-end framework Chameleon in the community. At that time, the demand was to implement fast application terminal first, and then to support H5, WeChat applet, byte applet, etc. Because the technology stack used by the company is based on Vue.js, after doing some technology selection, the final choice of Chameleon (start crazy pit 😳)
At this point, some might ask: Why not UniApp? Let’s just say the Uniapp-> app is not a pit, it’s a bomb 💣. Later, I’ll explain why you didn’t choose Uniapp 😲
However, in a rational assessment, Chameleon is indeed an excellent cross-end framework. What’s so good about it? (Read more at 😶.)
This article will be divided into the following three parts. By introducing and comparing the existing front-end cross-end framework, the excellent points of Chameleon will be described point by point 😍 :
- Why do we need straddle?
- Explosive development of the front end of the straddle frame
- Future cross-end solutions for Chameleon
1. 😷 Why do we need straddle?
Of course, those of you who know why can skip this section
This problem can be explained in two dimensions:
Variability of demand
There are so many small programs these days… And, for the needs of different changes, and you may say today is WeChat small program, after a period of time, may say the same product with you, you write a fast application version of 😲. For the demand side, they don’t look at the different ends of how you’re doing it, and they might say, well, you can do the same thing on a different platform. Isn’t that faster?
Maintainability of technology
From the perspective of technical maintenance, this is for us to better maintain the code, try to maintain a set of code to achieve different end of the product, such as WeChat applet, byte applet, fast application, H5 and so on. Therefore, choosing the way of cross-side framework development brings us the following benefits:
- Ensure stability when applying new functions
- A quick touble shot when something goes wrong
- Reduce writing repetitive code
- and so on…
2. 💥 Explosive development of the front-end straddle frame
Nowadays, there are many cross-end frameworks to choose from on the front end, Taro, Uniapp, Kbone, MPVue, Chameleon, and so on. Of course, some of them are limited by technology. For example, Tencent’s Kbone can only support the web side and WeChat applet isomorphies, JD.com’s Taro supports DSL React, and Uniapp supports DSL Vue. So, although the framework is much, but still the words, suitable for their own technical team is the best 🤓.
Next, let’s take a brief look at the four cross-end frameworks that support VUE DSL: MP-Vue, Uniapp, Kbone, and Chameleon:
2.1 mpvue
Mpvue is a fork from [email protected] that retains some of the features of vue2. x, such as the use of flow for static type checking, default syntax, etc. The design idea of MPVUE is basically to modify the Vue2.x runtime and template compilation part, according to different platforms to compile the AST (Abstract Syntax Tree) to do the syntax transformation to the specified end of the syntax, so as to complete the code generation of different end.
Note: MPVue’s GitHub Commit was last committed 17 months ago
2.2 uniapp
I think many students are familiar with UniApp, and some front-end students may contact with UniApp because of this. After all, dCloud is also “well-known”. As mentioned earlier, MPVue’s last commit was 17 months ago, and Uniapp now supports converting MPVue projects to Uniapp projects (hopefully many more users 😏).
UniApp is really excellent in cross-end, and it introduces the mechanism of conditional compilation to support the performance of different ends. For example, we need to display user’s avatar on two different ends of H5 and WeChat applet. The former can display user’s avatar through the data provided by WeChat, and the latter can be obtained directly by using the open-data component. So, with conditional compilation we could write:
<! -- #ifdef MP-WEIXIN --> <open-data class="img-avatar" type="userAvatarUrl"></open-data> <! -- #endif --> <! -- #ifdef H5 --> <img :src="avatar" class="avatar" /> <! -- #endif -->
Conditional compilation, which only writes code for a platform that meets this condition into the project code for that platform
Also, UniApp is well-established for cross-end types and supports fast apps. However, unlike other applets, QuickApp is a self-drawing rendering engine rather than WebView rendering. Therefore, at present UNIAPP only supports Vivo, OPPO and Huawei for fast application.
So that’s why I abandoned UniApp in the first place when I was doing technology selection. However, Uniapp also supports the WebView version of the fast app, but the WebView version of the fast app is not supported by all vendors…
2.3 kbone
Kbone is a set of cross-end framework that supports isomorphism between Web end and WeChat applet end launched by Tencent team. However, it is clear that Kbone is used in slightly fewer scenarios than the previous two, as it is limited to supporting only the Web side and the WeChat applet side. However, if the demand is just H5 and WeChat applet, obviously Kbone is a good choice, after all, the original original (Tencent) technical support.
So, it’s Chameleon’s turn, and the main character is about to appear 😎 ~
3. 🐲 Future cross-end solutions for Chameleon
Chameleon, an emerging force in cross-end frameworks, also has its own DSL (Domain of Characteristic Language), otherwise known as CML. However, unlike the cross-end framework we described above, Chameleon extends multiendpoints in the form of a polymorphic protocol. Here’s the official description:
By defining a unified language framework + a unified polymorphism protocol, Chamleon has extracted the “front-end and mid-platform services” with strong continuity and maintainability from the multi-terminal (corresponding to multiple independent services) business.
3.1 Polymorphic Protocol
In the official introduction, there is a noun polymorphic protocol that you may not have touched. So, what is Chameleon’s polymorphic protocol?
First, let’s take a theoretical look at what a polymorphic protocol is. Chameleon’s idea for a polymorphic protocol design 💡 came from Apache Thrift – a scalable cross-language service development framework. So, what is Apache Thrift?
Apache Thrift is an adoption
interfaceDescription languages define and create services, supporting a framework for extensible cross-language service development.
Put it in plain EnglishApache Thrift makes it possible for services created by different languages (Java, C, PHP) to be called from one another.
The polymorphic protocol, one of the core mechanisms of Chameleon framework, uses this design for reference and provides polymorphic interfaces and polymorphic components to extend the third-party terminal (WeChat applet, fast application, byte applet, etc.). For example, we could define a polymorphic interface to implement a specific API on a different side, and then directly use the defined polymorphic interface at the business code level to implement a method call on a specific API on a different side, which would look like this:
Moreover, for the cross-terminal platform that Chameleon supports by default, the compiled code only supports the basic components and APIs that Chameleon officially provides, such as List, Text, which are commonly used in WeChat and fast applications. API setStorage, getStorage and so on.
So, how do these different sides extend the implementation based on the underlying components and APIs specified by Chameleon? Next, I will take the implementation of the Chameleon extension fast application as an example to explain why 😲 ~
3.2 How do I extend a new end
First of all, I have to say that Chameleon is perfectly capable of supporting cross-app development, but the process is a bit cramped, so just skip it
So, here’s a look at what it takes to extend fast apps based on Chameleon. This process is mainly accomplished by 6 packages:
| - CML quickapp - API # # realize CML provide API | - CML quickapp - plugin # # compile related processing, For example generated. Ux documents, the manifest. Json file | - CML quickapp - runtime # # App, Page and Component Component instance | - CML quickapp - store # # CML State management | - CML quickapp - UI # # realize CML common component | - CML - quickapp - UI - builtin # # realize CML Native components
Fast apps are actually seven packages, plus one CML-QuickApp-mixins, which do some compatibility handling for directives and events (such as c-model, touchstart).
As you can see, we need at least 6 packages to extend an end, and these 6 packages accomplish the 4 points:
The details of each point need to be realized, the official documents have been explained in detail, here will not be repeated. This section is just a brief introduction to each Packages responsibility, so that students can have a little idea of the source code of the debugger, interested students can understand the code details.
Next, let’s look at how you can extend a particular API on one side of the business, the polymorphic interface.
3.3 How to extend the API of one side (polymorphic interface)
Let’s say we’re in a fast app development scenario where we need to add a desktop to our application. The API for adding desktop to fast app is not in the official document of Chameleon, so we need to implement the polymorphic interface at this time, that is, we need to customize the API for adding desktop to fast app.
First, create a Shortcut. Interface file and define the type of the API in the file:
<script cml-type="interface">
type successCallBack = (res: boolean) => void
type failCallBack = (res: boolean) => void
type obj = {
success: successCallBack,
fail: failCallBack
}
interface UtilsInterface {
installShortCut(obj): void;
hasInstalled(obj): void;
}
</script>
As you can see, interface type definitions are pretty much the same as TypeScript type definitions.
Then, in the Shortcut. Interface file, define the class to add the desktop, which contains two methods installShortcut () and hasInstalted (). Inside the method, you can use the QuickApp native API directly:
<script cml-type="quickapp"> class Method implements UtilsInterface { installShortCut(obj) { quickapp.shortcut.install(obj) } hasInstalled(obj) { quickapp.shortcut.hasInstalled(obj) } } export default new Method() </script> <script cml-type="web"> class Method implements UtilsInterface { installShortCut(obj) { } hasInstalled(obj) { } } export default new Method(); </script> ...
And, here needs to pay attention to ⚠️ 2 points:
- In order to keep the other side running properly, the Shortcut. Interface file also needs to declare the corresponding method of the other side. Here we can make it an empty function
- You cannot use the Shortcut API directly inside a method. Well, in Quick Application Shortcut is bound to System, and System is injected into the code as QuickApp at compile time, so we have to go through it
quickapp.shortcut
Call by way of
Finally, we can use the Add Desktop API in our business code, and it will only work for fast applications:
<template> <page title="index"> <text @click="addShortCut"></text> </page> </template> <script> import shortCut from ".. /.. /components/utils/shortcut.interface"; class Index { methods = { addShortCut() { shortCut.installShortCut({ success: (res) => { console.log(res) }, fail: (err) => { console.log(err) } }) } } } </script>
While extending a component on one side (
Polymorphic components) and the extension API. Chameleon-Tool also provides commands
cml init component
To initialize a polymorphic component template, this section of the official documentation is also detailed, but will not be discussed here.
3.4 summary
Polymorphic components and interfaces are part of the polymorphic protocol, which also supports polymorphic templates, which are similar to UniApp’s conditional compilation in that you can specify the end to which the component shown in the template belongs (only on the root element). Also, I figured that having learned how to use polymorphic components, polymorphic interfaces, and polymorphic templates, developing with Chameleon was almost as free as I wanted to be.
The most convenient is the last resort we can change a little source haha 😄
conclusion
Chameleon this framework gives me the feeling, is really love and ruthless 😷. Because, at that time in the process of project development, the fast application team wrote the extension has several problems, in order to ensure the normal online project, so I can only resolutely scalps the devil to change the source code to resist the project to go forward 😳, the final project also successfully online. Then, over the weekend, I also cleaned up some understanding of the Chameleon framework and fixed a couple of issues with the Fast App Extension (PR, incidentally).
Finally, welcome 👏 students who plan to try Chameleon in business to exchange their experience (add my WeChat or official account). If you encounter a hole in the implementation of fast application, I think I should be able to help one or two, and if there is improper expression or wrong place in the article, welcome to Issue ~
reference
The mainstream of a few small programs cross – end framework principle
Chameleon Unified Language Framework + Polymorphic Protocol
Apache Thrift – A scalable cross-language service development framework
Chameleon extends new side standards
❤️ Love triple hit
Writing is not easy, if possible, please click “like”, it will become the motivation for me to keep writing!!
I am Wu Liu, like innovation, tamper with source code, focus on VUE3 source code, VET source code, front-end engineering and other technology sharing, welcome to pay attention to my
WeChat official account: Code Center.