Writing in the front

Many things in life do more skilled later can often bear some routines, using routines can make things easier to deal with. A design pattern is a routine for writing code, like a swordsman’s sword score, which is a template for code.

Even those of you who have never seen design patterns must have been exposed to or inadvertently used some design patterns in your work. Because the principle of the code is the same, the implementation of a requirement may naturally follow the best pattern.

These patterns have been summarized by others, and can be used directly. When you read the source code of open source libraries, you will find that these libraries make extensive use of design patterns.

series

No depth – javaScript Design Pattern (I) : Creation design pattern no depth – javaScript design Pattern (II) : Structural design pattern no depth – javaScript design pattern (III) : Behavior design pattern can not be in-depth – javaScript design pattern (4) : skill design pattern can not be in-depth – javaScript design pattern (5) : architectural design pattern

This series of content is mainly based on the understanding and summary of the book JavaScript Design Pattern by Zhang Rongming (a total of 5 chapters). Because I have my own code implementation in this book, and use part of the new syntax, I have abandoned some tedious content, and even have to correct the “wrong” code in the book. So if I find that I understand wrong, code write wrong place trouble be sure to point out! Thank you very much!

Front knowledge

Master basic javaScript syntax, and have a deep understanding of JS principles (especially prototype chain).

Architectural design patterns

The architectural design pattern is a type of framework structure that provides subsystems, assigns their responsibilities, and organizes them coherently together.

As JS in ES6, from the level of language standards to achieve module functions.

And now the front end forms a mainstream development mode of engineering by using single-page application frameworks such as VUE/React (component-view development) and tools such as NPM/YARN (module management) and Webpack/Vite (package construction).

The modular pattern and Widget pattern (componentized view) described in this chapter are irrelevant. It is recommended to use standard ESModule modular development and learn componentized view development through frameworks such as VUE.

Front-end MVC, MVP, MVVM

As for the meanings and differences of these three architectural modes in front-end application, I made a personal summary and understanding based on books and data reference as follows.

First of all, THE MVC pattern is the basis of the three patterns, that is to say, MVP and MVVM are derived from the MVC pattern, and both MVP and MVVM can be regarded as models with partial changes in the application of MVC thought.

MVC

MVC divides software into three parts:

  • Model: Data is saved
  • View: User interface
  • Controller: service logic

Communication between the three parts is one-way.

For example, the page displays a number and two buttons (plus/minus), corresponding to the three parts of the MVC:

  1. The user clicks the page (View).
  2. ViewTo convey instructions toController.
  3. ControllerCommand numbers (based on business logic)Model) plus one.
  4. ModelSend the new number toViewOn the page the user sees a number plus one.
<div>The Numbers:<span id="num">0</span></div>

<input id="add" type="button" value="Add">
<input id="subtract" type="button" value="Cut">
Copy the code
const App = {
  Model: function() {
    this.num = 0

    this.changeNum = function(num) {
      this.num = num
      // Notification view
      this.noticeObserves()
    }
    
    // Notify the View when the observer mode data changes
    this.Observes = []
  
    this.addObserve = function(observe) {
      this.Observes.push(observe)
    }

    this.noticeObserves = function() {
      this.Observes.forEach(ob= > {
        ob.renderView()
      })
    }
  },

  View: function(controller, model) {
    const numDom = document.getElementById('num')

    const addBtn = document.getElementById('add')
    const subtractBtn = document.getElementById('subtract')

    // Bind events (View communicates instructions to Controller)
    addBtn.addEventListener('click', controller.handleAdd)
    subtractBtn.addEventListener('click', controller.handleSubtract)

    // Observer mode responds to receiving data changes
    this.model = model
    model.addObserve(this)
    this.renderView = function() {
      numDom.innerHTML = this.model.num
    }
  },

  Controller: function() {
    this.model = null
    this.view = null

    / / initialization
    this.init = function() {
      this.model = new App.Model()
      this.view = new App.View(this.this.model)
    }

    // Process the business logic
    this.handleAdd = () = > {
      const num = this.model.num + 1
      this.model.changeNum(num)
    }

    this.handleSubtract = () = > {
      const num = this.model.num - 1
      this.model.changeNum(num)
    }
  }
}
Copy the code
const c = new App.Controller()
c.init()
Copy the code
MVP

MVP mode starts by changing the name of Controller to Presenter.

  • Model: Data is saved
  • View: User interface
  • Presenter: Business logic

The biggest difference between MVP and MVC is that the Model layer is decoupled from the View layer, and all communication is done by Presenter.

You can see from the code above that the observer mode response is used between the View and Model. As for the difference between MVC and MVP, it is easy to think that it is similar to the difference between the observer model and the publish and subscribe model, that is, the communication is completed through an intermediary, and the two sides of the communication do not need to perceive the existence of the other side.

const App = {
  Model: function(presenter) {
    this.num = 0

    this.changeNum = function(num) {
      this.num = num
      / / release
      presenter.emmit('numChange', num)
    }
  },

  View: function(presenter, model) {
    const numDom = document.getElementById('num')

    const addBtn = document.getElementById('add')
    const subtractBtn = document.getElementById('subtract')

    // Bind events (View communicates instructions to Presenter)
    addBtn.addEventListener('click', presenter.handleAdd)
    subtractBtn.addEventListener('click', presenter.handleSubtract)

    / / subscribe
    presenter.on('numChange'.function(num) {
      numDom.innerHTML = num
    })
  },

  // The business logic is still handled by presenter, but the communication between View and Model is also added
  Presenter: function() {
    this.model = null
    this.view = null

    // Set up a subscription mode dispatch center
    this.list = {} // Message queue

    // Subscribe method
    this.on = function(event, fn) {
      if(!this.list[event]) {
        this.list[event] = []
      }

      this.list[event].push(fn)
    }

    // Publish method
    this.emmit = function(event, ... arg) {
      if(this.list[event]) {
        this.list[event].forEach(fn= > {
          return fn.apply(this, arg)
        })
      }
    }

    / / initialization
    this.init = function() {
      this.model = new App.Model(this)
      this.view = new App.View(this.this.model)
    }

    // Process the business logic
    this.handleAdd = () = > {
      const num = this.model.num + 1
      this.model.changeNum(num)
    }

        // Process the business logic
    this.handleSubtract = () = > {
      const num = this.model.num - 1
      this.model.changeNum(num)
    }
  }
}
Copy the code
MVVM

The MVP model starts by changing the name of Presenter to ViewModel

  • Model: Data is saved
  • View: User interface
  • ViewModel: Business logic

The difference between it and MVP is that the developer no longer has to worry about the communication between the View and the Model through two-way binding. Changes to the View are automatically reflected in the ViewModel, and changes to the ViewModel are automatically reflected in the View.

In VUE, for example, the above example might write code like this:

<div id="myapp">
  <div>
      <span>Numeral: {{num}}</span>
  </div>
  <div>
      <button v-on:click="handleAdd">-</button>
      <button v-on:click="handleSubtract">+</button>
  </div>
</div>
Copy the code
{
  data() {
    return {
      num: 0}},methods: {
    handleAdd() {
      this.num = this.num + 1
    },
    handleSubtract() {
      this.num = this.num - 1}}}Copy the code

Whenever you change the data in the ViewModel, the view updates automatically.

conclusion

The MV (X) pattern’s fundamental purpose is to decouple the application’s data, interface, and business logic. The difference lies in the size and implementation of the (X) layer. Both MVP and MVVM are derived from layers based on the MVC pattern.

In addition to this chapter, other references are as follows:

An overview of the MVC/MVP/MVVM pattern in front-end development