preface

Some time ago, the company proposed a small project, involving several page switching and search list display. Due to my relatively small learning and project of WebComponents, I chose Tencent’s open source OMI as the framework of this development. As a guinea pig, I wanted to take a closer look at user – defined components. All things are difficult before they are easy, and so are JS frameworks. Omi is indeed small and has been developed across multiple ends, but there are many problems in the development. I hope it gets better and better.

About the ecological

Omi’s ecology is relatively complete, including scaffolding, internationalization, routing, UI library, chart library and so on. Less demanding development is still fully satisfied. After all, in the early days of open source, there are still many resources lacking, such as routing, UI library and other support for TS. Although OMI already supports TS, I need to write my own declaration file to use their various libraries when writing TS, which means I have to read their source code and then create a declaration myself. I am lazy and did not use TS. Hash and history are two separate libraries on the route and are used differently. Fortunately, there are a lot of young people updating their ecology. Within two weeks, I saw the addition of swiper and omi plug-in of vscode. So I’m confident about omi’s ecology.

About omi

It should take a minute to learn react front-end omi. There are very few differences between React and OMI. The same JSX syntax is used. React has the same life cycle as React but is written differently. Import ‘./ omicomponents.js ‘; import ‘./omiComponents.

1. Style references

Omi has a CSS method that returns a string of CSS. We can import CSS/SCSS files as import, but note that if the referenced CSS/SCSS file name does not start with ‘_’, then no matter where you refer to the CSS/SCSS file, these are defined global styles, meaning that all components will have an effect. This obviously goes against the concept of modular components, so omi authors in the webpack configuration have CSS/SCSS file names that need to start with a line below and then return in the CSS method to define the local. There is also the statically defined local style, i.e

import css from './_index.css';
import 'components.css';
define('my-components',class extends weElement{
static css = '*{margin:0}'
css(){trturn CSS}}) //_index.css styles apply only to this component, components. CSS styles apply globallyCopy the code

The CSS/SCSS defined by static has much higher weight than the CSS/SCSS introduced. The style of an element defined is completely replaced by the style of the element defined in static, including non-repeating styles.

2.omi/omio

We found omi’s package.json and found an interesting configuration:

 "alias": {
    "omi": "omio"
  }
Copy the code

The configuration of OMI can be EITHER OMI or OMI, corresponding to two modes. Omi is packaged in the form of virtual DOM compiled like React. The advantage is good compatibility. When the page is updated, the virtual DO element can be compared in memory, and then combined with the transaction mechanism of the framework, the results of multiple comparisons can be combined and updated to the page in one time, thus effectively reducing The Times of page rendering and improving the rendering efficiency. Also can realize the server rendering, browser rendering and mobile terminal rendering and other functions. Therefore, omi framework is omi mode by default. But this contradicts our attitude towards webcomponents, and hence the omio pattern. This pattern is to completely package components as WebComponents. But after we switch modes, we find that the style is very confusing! None of the global styles we defined can affect the internal styles of the component; the styles are isolated. Of course, the local styles we defined are still there. There is always a way, so we define our own inheritance class.

import css from '_index.css'; // Global styleexport default class extends weElement{
css() {returncss; }}Copy the code

Then integrate the class we defined into the other components.

Unit testing

This was the biggest difficulty I encountered with OMI. Omi does not have a supporting unit test framework, and components cannot be fully tested using JEST and JSDOM simulation environment. Currently, WE are trying to use AVAJS for testing, and whether the test results reach the target can be supplemented later.

feeling

The omi project’s packaged code file is very small, which surprised me. Different from vue’s packaging, CSS seems to be embedded into the packaged JS in the form of code, and the file quantity is also very small, which makes me feel very comfortable. Overall, OMI was fast, small, and flexible, except for the ecology, which was a bit weak, and the unit testing was mind-boggling.

Original link: tech.gtxlab.com/omi.html

About the author: Zhang Shuan, Renhe future big data front-end engineer, focusing on HTML/CSS/JS learning and development.