San – A traditional MVVM component framework

Pre-announcement: this framework is developed by @Dong Rui Dashen, I just forward the article.


—— split line ——

In the past year or so, I have received many questions, such as “Oh, you are inventing the wheel again?” . I can only chuckle when this happens. After all, your stuff looks like crap, and there are so many mature things to choose from: Vue, React, Angular, Polymer, etc. Today, we feel that the San has gone through some project validation (stomping on potholes) and evolution (filling in potholes), and we are going to come out and talk about why and what kind of wheel it is.

Why do San

MVVM is nothing new, and we are far from pioneers on the Web. From a few years ago, some of our teams started working on Angular1 and some of our teams got involved with React, but what impressed me most was Vue, not because of the technology, but because it really “worked”. We practice some popular technologies and enjoy some convenience in less demanding applications (compatibility, performance, etc.). Nearly two years ago, we summarized some of the things we’ve done in practice, some of which are fairly common sense:

  • componentization
  • Declarative view
  • view=f(data)
  • Data to view’s rendering engine
  • Asynchronous rendering
  • …

However, due to IE8- still considerable occupancy, in the application of TO C, we can only be honest JQuery, one DOM by one operation. Compatibility is the biggest issue facing us. There will come a time when compatibility won’t be an issue, but do you really have to wait a few years for all the backwardness to go away? At any given moment we will find that something is going to be eliminated, something is coming, but if you stand still, you might as well be a barbecued pork.

To put it plainly, the do-it-or-die spirit has led us to open new pits for the seemingly trivial and ridiculous reason of compatibility. But it doesn’t get around, and it can cause other problems, such as mobile and PC not using the same component architecture.

Why San

Around 2010, we wrote an MVC framework called ER (Enterprise RIA) for various spA-type business systems, which looks like a 2. President Justineo said that since the new pit is more advanced than the old pit, it should be called 3. A group of people with dysphoria thought it made sense, so they settled on it.

So San is not an acronym for anything, it’s just three… The name is arbitrary, but the process of building the wheel is serious

What do you make of the San

Now that we’re doing it ourselves, we want to fully express our ideas and principles, not just follow them.

Either way

How do you want to reference a Library?

  • Straight down
  • npm install
  • CDN

What is the product development environment?

  • Nothing, naked, how to develop how online
  • There are simple bundles and compresses
  • Modular management, old AMD
  • Mainstream representative, WebPack + Babel

We don’t care where you’re from or where you’re going, we just want to provide you with a comfortable harbor. Is the slogan disgusting to everyone… Providing CDN, supporting AMD and Global Object, and NPM publish are easy things to do, but the harder one is “how do you solve the compatibility problem”.

This section describes how to manipulate component data to resolve compatibility

In San components, changes to data are made through methods such as set or splice. The data manipulation documentation describes this in detail. This means:

  • Solve the compatibility problem in its simplest form
  • The San development experience couldn’t have done better than Vue
  • The process of data manipulation is controllable. In fact, since 3.1.0, data changes are internally Immutable
  • Change tracking is easy to do. We don’t think v-DOM is a cure-all, and San is designed for the Web, so we don’t expect it to be cross-platform. So removing the V-DOM layer is a good thing

We also considered allowing users to manipulate data Immutable and then rehash it, but this would be costly to users and they wouldn’t necessarily understand why, so we blocked it.

this.data.set('user'. userName);

// vs

setData(Object.assign({}, data. {user: userName}));
Copy the code

However, locking up data also means that it becomes more expensive to retrieve data, especially if you want to retrieve more than one data at a time. So we’ve implemented the get method to get data, which returns the entire data object without arguments, which is easy to deconstruct if you’re developing with ESNext. However, data is manipulated through methods such as set or splice.

let {name, email} = this.data.get();
Copy the code

Component form

While we appreciate Vue, we disagree with Component = data. In Vue, data is placed directly under components, and methods are specified.

new Vue({
   el: '#example-3'.

   // Methods are specified
   methods: {
       reverseMessage: function (a) {
           this.message = this.message.split(' ').reverse().join(' ')
       }
   }
})
Copy the code

We prefer methods to be placed directly under components, and the data to be specified (and actually encapsulated).

san.defineComponent({
   template: '
        

         ... 
         
        
'.

   // Method is placed directly under the component
   submit: function (a) {
       var title = this.data.get('title');
       if (!title) {
           return;
       }
       sendData({title: title});
   }
});
Copy the code

However, this is a matter of philosophy, not one good or the other bad.

Component declarations

We think of the component as a class (not to be taken seriously, function). In ESNext, we can use extends to construct inheritance relationships between components. It looks more natural.

import {Component} from 'san';

class HelloComponent extends Component {
   static template = '
Hello {{name}}! 
';

   initData(a) { 
       return {name: 'San'} 
   }
}
Copy the code

ESNext cannot declare a Prototype property. So, the San provides static property support for properties like template/filters/Components.

For products that don’t want to use ESNext, we provide defineComponent, which makes it easy and quick to declare components.

var HelloComponent = san.defineComponent({
   template: '
Hello {{name}}! 
'.

   initData: function (a) { 
       return {name: 'San'} 
   }
});
Copy the code

Components in the solution

We want the San to be able to parse out the component structure from HTML with specific tags, and use the components to respond to and manage subsequent user interactions, something we call component unsolvation. (What, you call deserialization? Ok, just happy)

  • Back-end straight OUT HTML has advantages in first screen time, especially in content-oriented applications
  • Using NodeJS to provide online Web services may not work everywhere, at least not in many parts of our factory. NodeJS is not a cure-all

Therefore, we first develop the protocol of specific tags, based on which we realize the function of component inverse solution. The later NodeJS server rendering function is also based on component inverse, and outputs protocol-compliant HTML.

Also, for server-side rendering, I’m afraid the biggest concern is performance. San server rendering has been tested to be 30-40% slower than art-Template, the fastest JS template engine, mainly because of the extra markup generated on the front end that can be recognized and inverted. This is already the performance level of the String-based template engine.

10k

In a world where libraries don’t care about volume, there are not many side effects of large volume. In addition to network transfer, the time of MOBILE JS Parse is not negligible. So I set a goal of no more than 10K after GZip, not including development and debugging versions. Why 10K? It’s just a slap on the head. It could be Mission Impossible.

The original crude version was not very large, but we exceeded 10K size more than once due to increased compatibility handling, new features, and code splitting. Every time I went back to find out what could be optimized in the code, there were fewer and fewer places that could be optimized later, and I was almost sent to the hospital as a patient with obsessive-compulsive disorder. But in the end it actually worked.

This wasn’t a very technical thing to do, and for this reason we wrote ES5 code by hand instead of ESNext + Babel, which was considered low B by many. It doesn’t matter if it’s 10K, it’s just attitude. We want San users to be free from volume problems, and we want volume obsessives to have more options.

performance

When we first started San, many of the popular solutions had some performance issues (Angular updates, initial Vue rendering, etc.). But the world changes so fast, more than a year has passed, now everyone’s performance is actually good, who is more stupid than who? San performance is fine, but it’s not a one-size-fits-all thing. Everyone is similar, and different scenarios have their own advantages. If you’re interested, take your own test.

What else?

Application Status Management

These days, if you don’t use state management in a solution, you look like a cripple. So we have a SAN-store. It has its own characteristics:

  • The name has character. When we call it NNNX, we want to convey the idea that store is a globally unique source of app state
  • There are different abstractions. We still want to make it as easy as possible to understand. Redux’s model is too cumbersome for us to pretend to be honest without copying Vuex, so we provide a simpler abstraction, just Action.
  • The operation of applying status data is done via SAN-update

router

This is also a disability without things, but think also have no what to say, there is a need to see their own. san-router

Component library

Component library is the foundation to reduce the workload of actual business development and liberate productivity.

  • Material Design is a highly recognized set of visual system, based on which we developed a MUI component library.
  • WeUI is a set of visual system output by wechat and Mobile friendly, but there is no REALIZATION of San at present. Welcome students who are interested in a set. If the quality is good, we will recommend it on the official website.
  • AntDesign is a set of visual system output by ants and suitable for various management systems. However, there is no IMPLEMENTATION of San at present. Students who are interested in AntDesign are also welcome to have a set.
  • If your application has its own visual architecture, developing your own component library is inevitable

I’ve been told that you should build your own component library, but you don’t really care what an application is, as long as it looks good and works. But my factory does not have its own visual interaction system, what can I do, I am also very desperate ah.

DevTool

DevTool wasn’t ready when they wrote this AD, soon, in a week. Check out the San WebSite

The last

At this point, it shouldn’t be hard to see that San has some traditions:

  • Still compatible with Old IE
  • Also considering business development scenarios without Babel Transform
  • Still struggling with volume
  • Also want to keep the back end independent rather than pushing NodeJS

If you think about a car, we want to build a land patrol. It’s not as easy to drive as sedans or even most SUVs, and you don’t see many 2.0T taillights; He is also less capable and passable off-road than the Wrangler or Benz G. But it’s reliable and will take you wherever you want to go with stability and comfort.

Since you’ve been patient enough to see this, would you mind paying attention? ^_^

ecomfe/san