DEV Community: 当耐特

OMI - Signal responsive WebComponents and Tailwind CSS Components are coming

当耐特 — Wed, 08 Nov 2023 02:24:36 +0000

It's almost 2024, major frameworks have abandoned compatibility with IE11. If we don't consider IE11, we can fully utilize the latest features of modern browsers. So, what should the front-end framework look like?

After OMI joined Signal, the current API design has become the ideal frontend framework in my mind. The OmiElements, based on Tailwind CSS atomic CSS, represent the perfect form of a frontend element library. In the future, we will introduce the component library built on top of the element library, as well as the OMI low-code platform based on the component library. Please look forward to these developments. Additionally, we have completely upgraded and redesigned the main site and its various sub-sites.

Home: http://omijs.org/
Github: https://github.com/Tencent/omi

Now let's take a glimpse at the design ideas and some trade-offs of OMI from these keywords:

Signal
Proxy
Web Components
JSX
Tailwind CSS
Constructable Stylesheets
OMI Router
OMI Suspense
OOP & DOP
OMI SPA
OMI Low-Code

OMI Elements and OMI Tutorial are built using most of the capabilities from the above technologies:

Two projects can be found at https://github.com/Tencent/omi.

Signal-driven reactive programming

In Liu Cixin's science fiction novel "The Three-Body Problem," after receiving a signal from the Trisolaran world, Ye Wenjie also received another warning signal.

Don't answer!

Ye Wenjie received a signal, and the value of the signal was "Don't answer! " A signal is a signal, and the value of the signal is represented by signal.value. It's important to understand that the signal itself is not equal to its value; rather, the value of the signal is equal to signal.value. Understanding this concept is crucial to grasping the core idea of a signal. Here's an example to illustrate this:

import { render, signal, tag, Component, h } from 'omi'

const count = signal(0)

function add() {
  count.value++
}

function sub() {
  count.value--
}

@tag('counter-demo')
class CounterDemo extends Component {
  render() {
    return (
      <>
        <button onClick={sub}>-</button>
        <span>{count.value}</span>
        <button onClick={add}>+</button>
      </>
    )
  }
}

render(<counter-demo />, document.body)

In the above code, count is a signal. In the render method, the signal value is read as count.value. At this point, the signal is collected as a dependency for the current component. When the signal value changes, the components that depend on this signal will be automatically updated, achieving reactivity. To emphasize once again, when the value of the signal is read (i.e., .value), the component reading the signal will be collected as a dependency. In the future, when the signal value changes, the components dependent on the signal will be automatically updated.

How is it achieved? Below is an introduction to the implementation principle of OMI Signal.

Proxy: Powerful Proxy API in JavaScript

In JavaScript, Proxy provides a powerful metaprogramming capability that allows developers to intercept and handle access and modification of object properties. The introduction of Proxy greatly expands the possibilities of JavaScript programming, providing developers with more flexibility and control.

The essence of Proxy is an object that accepts two parameters: the target object and the handler object. The target object is the object to be proxied, while the handler object contains a series of methods for intercepting and handling operations on the target object.

const target = { foo: 'bar' };

const proxy = new Proxy(target, {
  get(target, property) {
    console.log(`Getting ${property}`);
    return target[property];
  }
};);
console.log(proxy.foo); // output: "Getting foo" 和 "bar"

In this example, we created a simple Proxy object that logs a message when accessing the properties of the target object. When we access the foo property through the proxy object, the get method of the handler object is triggered, logging the message and returning the property value.

Proxy supports various interception methods that can intercept and handle various operations on the target object. Here are some commonly used interception methods:

get(target, property, receiver): Triggered when accessing a property of the proxy object.
set(target, property, value, receiver): Triggered when setting a property value of the proxy object.
has(target, property): Triggered when using the in operator to check for a property in the proxy object.
deleteProperty(target, property): Triggered when deleting a property of the proxy object.

These interception methods can be freely combined to implement complex logic control as needed. It's important to note that not all interception methods need to be implemented, and unimplemented interception methods will directly access or operate on the target object.

Proxy has many practical use cases in real-world development, with data binding and reactive updates being the most common ones. The Signal feature in the OMI framework is based on Proxy: by intercepting access to object properties (collecting dependencies) and modification operations (updating dependencies), it achieves synchronization between data and views. This is not a new technology, as MobX has long been using observable states, computed values, dependency tracking, reactive updates, and actions to help manage and update application states more easily. As a standalone state management library, OMI directly integrates these capabilities out of the box.

Web Components

Web Components is a set of browser-native technologies that enable the creation of reusable and well-encapsulated custom HTML elements. It has revolutionized frontend development, allowing developers to efficiently build complex web applications. Some examples of big companies using Web Components include:

Adobe Photoshop Online, which is entirely built using Web Components.
Microsoft's new web version of the Windows Store utilizes web components.
Twitter embedded tweets, YouTube, Electronic Arts, Adobe Spectrum, and others are also built using Web Components.

Web Components consist of three main technologies:

Custom Elements: It allows developers to create custom HTML elements and define their behavior.
Shadow DOM: It provides encapsulated DOM structures for custom elements, isolating them from the main document to avoid style and script conflicts.
HTML Templates: It offers a way to create HTML templates that can be cloned and populated at runtime, improving rendering performance.

For example, here's how you can implement a custom element without using any framework:

class MyElement extends HTMLElement {
  constructor() {
    super();
    const shadowRoot = this.attachShadow({ mode: 'open' });
    const div = document.createElement('div');
    div.textContent = 'Hello, Shadow DOM!';
    shadowRoot.appendChild(div);
  }
}

customElements.define('my-element', MyElement);

In this example, we create a custom element called my-element and create a Shadow DOM inside it. When the browser encounters the <my-element> tag, it automatically creates an instance of MyElement and attaches it to the document. <my-element> is framework-agnostic, meaning any framework can use this element.

OMI framework utilizes two features mentioned above: Custom Elements and Shadow DOM. HTML Templates are replaced by a more programmer-friendly syntax called JSX to achieve better programming experience. For example, in the above example, OMI implements it as follows:

import { tag, Component, h } from 'omi'

@tag('my-element')
class MyElement extends Component {
  render() {
    return <div>Hello, Shadow DOM!</div>
  }
}

JSX programming experience is better and shorter. Template strings are enclosed in backticks within tag functions, and interpolation requires the use of $ symbols.

For the foreseeable future, we won't be using HTML Templates or tag functions with real DOM. Instead, we'll be using JSX + virtual DOM syntax because it provides a better programming experience. I can't guarantee whether tag functions with real DOM will be supported in the future alongside JSX. However, what I can say is that unless there are obvious performance bottlenecks, we will continue to use JSX/TSX + virtual DOM for a long time.

Tailwind CSS

Naming variables is indeed a time-consuming task in programming, especially when it comes to assigning precise class names to HTML tags. Tailwind CSS serves as a solution by eliminating the need to worry about naming conventions, CSS conflicts, file size inflation, or the rapid decay of large style files. Its benefits far outweigh its drawbacks, as once you embrace the concept of atomic CSS, there's no turning back.

Tailwind CSS is a utility-first CSS framework designed for building user interfaces. It aims to assist developers in rapidly creating responsive designs by providing a set of composable preset classes. Following a mobile-first design approach, Tailwind CSS allows for easy creation of responsive designs for different devices and screen sizes. When building for production, Tailwind CSS automatically removes unused CSS, resulting in smaller final file sizes.

A couple of years ago, I asked the OMI team if it was feasible to build a component library using atomic CSS, and initially, the consensus was that it wasn't. However, that perception changed when we came across the tw-elements project, which proved that it was indeed possible.

In the context of using Tailwind CSS with OMI WebComponents:

import { tag, Component } from 'omi'
import { tailwind } from '@/tailwind'

@tag('my-element')
export class MyElement extends Component {
  static css = [tailwind]

  render() {
    return (
      <figure class="md:flex bg-slate-100 rounded-xl p-8 md:p-0 dark:bg-slate-800">
        <img class="w-24 h-24 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512" />
        <div class="pt-6 md:p-8 text-center md:text-left space-y-4">
          <blockquote>
            <p class="text-lg font-medium">
              “Tailwind CSS is the only framework that I've seen scale
              on large teams. It’s easy to customize, adapts to any design,
              and the build size is tiny.”
            </p>
          </blockquote>
          <figcaption class="font-medium">
            <div class="text-sky-500 dark:text-sky-400">
              Sarah Dayan
            </div>
            <div class="text-slate-700 dark:text-slate-500">
              Staff Engineer, Algolia
            </div>
          </figcaption>
        </div>
      </figure>
    )
  }
}

When each component carries Tailwind CSS, one might wonder if it results in significant memory overhead. This is where constructable stylesheets come into play.

Constructable Stylesheets

Constructable stylesheets are the perfect companion for Web Components. They provide a way to create and distribute reusable styles when using Shadow DOM, reducing size and improving performance.

Before diving into constructable stylesheets, let's first explore the traditional ways of applying styles in web development.

Inline Styles

Inline styles involve directly writing styles within the style attribute of HTML elements. This approach is simple and straightforward, but the styles cannot be reused and can be difficult to manage.

<style> Tag: The <style tag is used within the <head> of an HTML document to write styles. This method allows styles to be applied to the entire document, but the styles still cannot be reused, and if there is a large amount of style code, it may affect the readability of the HTML document.

External Stylesheets

External stylesheets are referenced using the <link rel="stylesheet" href="..."> tag to import an external CSS file. This approach allows for style reuse and separates the style code from the HTML code, making it easier to manage. However, each external stylesheet requires an HTTP request, and if there are multiple stylesheets, it may impact the page loading performance.

These approaches generally work well in most cases, but in certain scenarios, they may encounter some issues. For example, when using Web Components, it is common to apply styles within the Shadow DOM of each component. Since the Shadow DOM is isolated, we cannot directly use external stylesheets or <style> tags, and instead, we must write styles separately within each Shadow DOM. This not only makes styles difficult to reuse but also leads to a large amount of duplicated style code being loaded, which can impact performance.

To address these issues, the Constructable Stylesheets API provides a new way to create, store, and apply styles. This API consists of the following main parts:

CSSStyleSheet class: This class represents a stylesheet. We can create a new stylesheet using new CSSStyleSheet(), and then set the content of the stylesheet using sheet.replace(text) or sheet.replaceSync(text), where text is a string containing CSS code.

adoptedStyleSheets property: This property exists on the Document and ShadowRoot objects. We can apply stylesheets using document.adoptedStyleSheets = [sheet1, sheet2, ...] or shadowRoot.adoptedStyleSheets = [sheet1, sheet2, ...], where sheet1, sheet2, ... are CSSStyleSheet objects.

With Constructable Stylesheets, we can create and manage stylesheets in JavaScript and dynamically apply them where needed. This allows for style reuse and only requires loading the style code once, improving performance.

For example, we can create a stylesheet and apply it to multiple Shadow DOMs. Here's an example of using Constructable Stylesheets without the native support of the OMI framework.

const sheet = new CSSStyleSheet();
sheet.replaceSync('p { color: red; }');

customElements.define('my-element', class extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
  }
  connectedCallback() {
    this.shadowRoot.adoptedStyleSheets = [sheet];
    this.shadowRoot.innerHTML = '<p>Hello, world!</p>';
  }
});

In this example, we create a stylesheet sheet and apply it to the Shadow DOM of the my-element component. Regardless of how many my-element components we create, the code of the stylesheet only needs to be loaded once.

SPA & OMI Router & OMI Suspense

SPA (Single Page Application) is a web application development pattern characterized by dynamically updating and rendering content on a single HTML page using JavaScript, without the need to reload the entire page. Its advantages include improved user experience, faster response times, reduced network traffic, separation of front-end and back-end, offline support, and ease of debugging and maintenance.

React Router defines routes using the following approach, where each path corresponds to an element and supports nested routes.

<Routes>
  <Route path="/" element={<Layout />}>
    <Route index element={<Home />} />
    <Route path="about" element={<About />} />
    <Route path="dashboard" element={<Dashboard />} />
    <Route path="*" element={<NoMatch />} />
  </Route>
</Routes>

OMI Router uses a flat routing design to build SPAs (Single Page Applications). It combines OMI Suspense with the automatic upgrade feature of Web Components, supported natively by browsers, to progressively display the content of web areas.

export const routes = [{
    path: '/user/:id/profile',
    render(router: Router) {
      return (
        <o-suspense
          imports={[
            import('./components/user-info'),
          ]}
        >
          <div slot="pending">Loading user...</div>
          <div slot="fallback">Failed to load user</div>
          <user-info>
            <o-suspense
              imports={[
                import('./components/user-profile'),
              ]}
              data={async () => {
                return await fetchUserProfile(router?.params.id as string)
              }}
              onDataLoaded={(event: CustomEvent) => {
                userProfile.value = event.detail
              }}
            >
              <div slot="pending">Loading user profile...</div>
              <div slot="fallback">Failed to load user profile</div>
              <user-profile></user-profile>
            </o-suspense>
          </user-info>
        </o-suspense>
      )
    }
  }
]

Suspense is a mechanism used to handle asynchronous loading of components. By using Suspense, developers can provide a "placeholder" for asynchronously loaded components, which is displayed to the user until the component and its dependent data are loaded. This prevents users from seeing a blank page while waiting for the component to load, thus improving the user experience.

In OMI Router, each path corresponds to a specific interface, making it easy to understand and manage. Although the routing is flat, nested components are used in the render function of each route. This is a common pattern that allows code reuse and represents hierarchical relationships while keeping the routing flat. However, when there are repeated headers and sidebars on pages, some code duplication may occur. In the future, we can consider supporting the declaration of children to enable nested forms. But it would still be syntactic sugar for the flat structure, and the final result would be the same.

OOP & DOP

Here, let's use the example of TodoApp to explain the Signal class and signal response, which are two ways of reactive programming in OMI.

TodoApp using reactive functions

Data-driven programming

In data-driven programming, the focus is on the data itself and the operations performed on the data, rather than the object or data structure where the data resides. This programming paradigm emphasizes the changes and flow of data, as well as how to respond to these changes. TodoApp based on reactive functions is a good example of this. It utilizes the concept of reactive programming, where the UI automatically updates to reflect changes in the data (i.e., the to-do list) when they occur.

import { render, signal, computed, tag, Component, h } from 'omi'

const todos = signal([
  { text: 'Learn OMI', completed: true },
  { text: 'Learn Web Components', completed: false },
  { text: 'Learn JSX', completed: false },
  { text: 'Learn Signal', completed: false }
])

const completedCount = computed(() => {
  return todos.value.filter(todo => todo.completed).length
})

const newItem = signal('')

function addTodo() {
  // api a，不会重新创建数组
  todos.value.push({ text: newItem.value, completed: false })
  todos.update() // 非值类型的数据更新需要手动调用 update 方法

  // api b, 和上面的 api a 效果一样，但是会创建新的数组
  // todos.value = [...todos.value, { text: newItem.value, completed: false }]

  newItem.value = '' // 值类型的数据更新需会自动 update
}

function removeTodo(index: number) {
  todos.value.splice(index, 1)
  todos.update() // 非值类型的数据更新需要手动调用 update 方法
}

@tag('todo-list')
class TodoList extends Component {
  onInput = (event: Event) => {
    const target = event.target as HTMLInputElement
    newItem.value = target.value
  }

  render() {
    return (
      <>
        <input type="text" value={newItem.value} onInput={this.onInput} />
        <button onClick={addTodo}>Add</button>
        <ul>
          {todos.value.map((todo, index) => {
            return (
              <li>
                <label>
                  <input
                    type="checkbox"
                    checked={todo.completed}
                    onInput={() => {
                      todo.completed = !todo.completed
                      todos.update()
                    }}
                  />
                  {todo.completed ? <s>{todo.text}</s> : todo.text}
                </label>
                {' '}
                <button onClick={() => removeTodo(index)}>❌</button>
              </li>
            )
          })}
        </ul>
        <p>Completed count: {completedCount.value}</p>
      </>
    )
  }
}

render(<todo-list />, document.body)

TodoApp using the Signal class

Object-oriented programming

In object-oriented programming, the focus is on objects, which encapsulate both data and the methods to operate on that data. This programming paradigm emphasizes the interaction and collaboration between objects, as well as how to organize and manage code through encapsulation, inheritance, and polymorphism. TodoApp based on reactive functions can also be implemented using an object-oriented approach. For example, we can create a TodoList class that contains the data for the to-do list and the methods to manipulate that data, along with an update method to update the UI.

import { render, Signal, tag, Component, h, computed } from 'omi'

type Todo = { text: string, completed: boolean }

class TodoApp extends Signal<{ todos: Todo[], filter: string, newItem: string }> {
  completedCount: ReturnType<typeof computed>

  constructor(todos: Todo[] = []) {
    super({ todos, filter: 'all', newItem: '' })
    this.completedCount = computed(() => this.value.todos.filter(todo => todo.completed).length)
  }

  addTodo = () => {
    // api a
    this.value.todos.push({ text: this.value.newItem, completed: false })
    this.value.newItem = ''
    this.update()

    // api b, same as api a
    // this.update((value) => {
    //   value.todos.push({ text: value.newItem, completed: false })
    //   value.newItem = ''
    // })
  }

  toggleTodo = (index: number) => {
    const todo = this.value.todos[index]
    todo.completed = !todo.completed
    this.update()
  }

  removeTodo = (index: number) => {
    this.value.todos.splice(index, 1)
    this.update()
  }
}

const todoApp = new TodoApp([
  { text: 'Learn OMI', completed: true },
  { text: 'Learn Web Components', completed: false },
  { text: 'Learn JSX', completed: false },
  { text: 'Learn Signal', completed: false }
])

@tag('todo-list')
class TodoList extends Component {
  onInput = (event: Event) => {
    const target = event.target as HTMLInputElement
    todoApp.value.newItem = target.value
  }

  render() {
    const { todos } = todoApp.value
    const { completedCount, toggleTodo, addTodo, removeTodo } = todoApp
    return (
      <>
        <input type="text" value={todoApp.value.newItem} onInput={this.onInput} />
        <button onClick={addTodo}>Add</button>
        <ul>
          {todos.map((todo, index) => {
            return (
              <li>
                <label>
                  <input
                    type="checkbox"
                    checked={todo.completed}
                    onInput={() => toggleTodo(index)}
                  />
                  {todo.completed ? <s>{todo.text}</s> : todo.text}
                </label>
                {' '}
                <button onClick={() => removeTodo(index)}>❌</button>
              </li>
            )
          })}
        </ul>
        <p>Completed count: {completedCount.value}</p>
      </>
    )
  }
}

render(<todo-list />, document.body)

Here, we are not discussing the merits or drawbacks of either approach (DOP or OOP). In OMI, you have the freedom to choose either approach or even combine them using a layered architecture.

We advocate for developing front-end applications using a layered approach. The reason for using a layered architecture is simple: let UI be UI and non-UI be non-UI. Front-end frameworks can be a double-edged sword. While they enable rapid UI development, they can also lead to a chaotic mix of non-UI logic that should be carefully analyzed and designed using object-oriented principles. Forcing MVVM/MVC/MVP layers within the UI layer is a mistake. We aim to leverage the advantages of OMI's data-driven reactive views and its ability to quickly build UIs while minimizing the inclusion of all logic within the UI layer.

Additionally, we have developed the same Snake game using both a two-layer and three-layer architecture, demonstrating that OOP and DOP can coexist and be used together.

Source Code can be found here: http://omijs.org/ 或 https://github.com/Tencent/omi

Our suggestion is as follows:

Divide the front-end project into different layers, such as UI layer, middleware layer, and Model layer, each responsible for different functionalities, reducing coupling and separating concerns.
UI layer: Responsible for page layout, styling, animations, and visual presentation. Avoid handling business logic and data processing in the UI layer.
Middleware layer: Responsible for converting UI layer inputs into the format required by the Model layer and converting Model layer outputs into the format required by the UI layer.
Model layer: Contains all the actions the software needs to perform, with the UI layer only providing a human-computer interaction interface to send instructions to the Model layer.

By following these suggestions, you can effectively improve the maintainability, scalability, and readability of your front-end projects.

OMI Low-Code

Building on our extensive practical experience, we constantly generate ideas and creativity related to low-code development. These will be reflected in our low-code products in the future. Stay tuned!

Summary

In "Reminiscences of a Stock Operator," there is a concept of the Holy Grail that many investors try to find. From an objective perspective, front-end frameworks also have their own Holy Grail, and we continue to search for it, standing on the shoulders of giants.

This article provides a high-level overview of OMI's new features, related technologies, and official packages, including OMI Signal, Web Components, TailwindCSS, OMI Router, OMI Suspense, Proxy, Constructable Stylesheets, OOP & DOP, JSX, SPA, etc. The aim is to help readers better understand and apply the OMI framework, improve the efficiency and quality of web development, and embrace the trends.For more details, please visit http://omijs.org/.

Snake-Eating Game Making with Web Components of Omi and MVP Architecture

当耐特 — Fri, 30 Aug 2019 09:38:31 +0000

Actually, I used react, preact, vue and omi framework to develop this game, and I found that the development experience of Omi is the best, and the sourece code is really neat. Let me take you step by step to develop this simple game.

Touch Online Demo(Mobile)

Read this article and you can learn:

Integration of Domain Driven Design in Front End
Basic Principles of rpx unit of CSS
Using Omi to develop Snake Eating game
Understanding MVC, MVP, MVVM patterns
Use DOM to write small game (not canvas)
Game Main Frame Rate and Local Frame Rate Control
Omi store system

Domain Model Design

Extract the main entities, such as (snake, game)
Summarize the specific business attribute methods from entity
- Snake
- Contains the direction of motion, body attributes
- Contains moving and steering methods
- Game
- Contains end pause status, maps, scores, frame rates, game protagonists, food
- Contains start game, pause game, end game, produce food, reset game, etc.
Establishing links between entity attribute methods
- The only protagonist in the game is the snake.
- Snakes eat food, and game scores increase
- Food disappears. Game is responsible for producing food again.
- The snake hits the wall or hits itself, and the game is over.
Core Loop Logic
- Judge whether there is food or not and produce one without it (low frame rate)
- Collision detection between snake and itself
- Collision detection between snakes and obstacles
- Collision detection between snake and food
- Snake movement

Snake Class

class Snake {
  constructor() {
    this.body = [3, 1, 2, 1, 1, 1]
    this.dir = 'right'
  }

  move(eating) {
    const b = this.body
    if (!eating) {
      b.pop()
      b.pop()
    }

    switch (this.dir) {
      case 'up':
        b.unshift(b[0], b[1] - 1)
        break
      case 'right':
        b.unshift(b[0] + 1, b[1])
        break
      case 'down':
        b.unshift(b[0], b[1] + 1)
        break
      case 'left':
        b.unshift(b[0] - 1, b[1])
        break
    }
  }

  turnUp() {
    if (this.dir !== 'down')
      this.dir = 'up'
  }
  turnRight() {
    if (this.dir !== 'left')
      this.dir = 'right'
  }
  turnDown() {
    if (this.dir !== 'up')
      this.dir = 'down'
  }
  turnLeft() {
    if (this.dir !== 'right')
      this.dir = 'left'
  }
}

The snake's turn has a logic that it can't retreat in the opposite direction. For example, it is moving left and can't turn directly right. Therefore, there are corresponding conditional judgments in turnUp, turnRight, turnDown, turnLeft.

Game Class

import Snake from './snake'

class Game {
  constructor() {
    this.map = []
    this.size = 16
    this.loop = null
    this.interval = 500
    this.paused = false
    this._preDate = Date.now()
    this.init()
  }

  init() {

    this.snake = new Snake

    for (let i = 0; i < this.size; i++) {
      const row = []
      for (let j = 0; j < this.size; j++) {
        row.push(0)
      }
      this.map.push(row)
    }
  }

  tick() {

    this.makeFood()
    const eating = this.eat()
    this.snake.move(eating)
    this.mark()

  }

  mark() {
    const map = this.map
    for (let i = 0; i < this.size; i++) {
      for (let j = 0; j < this.size; j++) {
        map[i][j] = 0
      }
    }

    for (let k = 0, len = this.snake.body.length; k < len; k += 2) {
      this.snake.body[k + 1] %= this.size
      this.snake.body[k] %= this.size

      if (this.snake.body[k + 1] < 0) this.snake.body[k + 1] += this.size
      if (this.snake.body[k] < 0) this.snake.body[k] += this.size
      map[this.snake.body[k + 1]][this.snake.body[k]] = 1
    }
    if (this.food) {
      map[this.food[1]][this.food[0]] = 1
    }
  }

  start() {
    this.loop = setInterval(() => {
      if (Date.now() - this._preDate > this.interval) {
        this._preDate = Date.now()
        if (!this.paused) {
          this.tick()
        }
      }
    }, 16)
  }

  stop() {
    clearInterval(this.loop)
  }

  pause() {
    this.paused = true
  }

  play() {
    this.paused = false
  }

  reset() {
    this.paused = false
    this.interval = 500
    this.snake.body = [3, 1, 2, 1, 1, 1]
    this.food = null
    this.snake.dir = 'right'
  }

  toggleSpeed() {
    this.interval === 500 ? (this.interval = 150) : (this.interval = 500)
  }

  makeFood() {
    if (!this.food) {
      this.food = [this._rd(0, this.size - 1), this._rd(0, this.size - 1)]
      for (let k = 0, len = this.snake.body.length; k < len; k += 2) {
        if (this.snake.body[k + 1] === this.food[1]
          && this.snake.body[k] === this.food[0]) {
          this.food = null
          this.makeFood()
          break
        }

      }
    }
  }

  eat() {
    for (let k = 0, len = this.snake.body.length; k < len; k += 2) {
      if (this.snake.body[k + 1] === this.food[1]
        && this.snake.body[k] === this.food[0]) {
        this.food = null
        return true
      }
    }
  }

  _rd(from, to) {
    return from + Math.floor(Math.random() * (to + 1))
  }
}

You can see that the above code uses a 16*16 two-dimensional array to store snakes, food, and map information. Snakes and food occupy 1 lattice and the rest 0.

[
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
]

So it represents a snake of five lengths and a food. Can you find it in the gird above?

Game Panel Rendering

import { define, rpx } from 'omi'

define('my-game', ['map'], _ => (
  <div class="game">
    {_.store.data.map.map(row => {
      return <p>
        {row.map(col => {
          if (col) {
            return <b class='s'></b>
          }
          return <b></b>
        })}
      </p>
    })}
  </div>
), rpx(require('./_index.css')))

The cell with s class is black, such as food, snake body, and the rest will be grey background. The ['map'] represents a dependency on store.data. The map updates automatically update views.

Ctrl and Game Panel Rendering


import { define, rpx } from 'omi'
import '../game'


define('my-index', ['paused'], ({store}) => (
  <div class="container">
    <h1>OMI SNAKE</h1>

    <my-game></my-game>

    <div class="ctrl">
      <div class="btn cm-btn cm-btn-dir up" onClick={store.turnUp}><i></i><em></em><span>Up</span></div>
      <div class="btn cm-btn cm-btn-dir down" onClick={store.turnDown}><i></i><em></em><span>Down</span></div>
      <div class="btn cm-btn cm-btn-dir left" onClick={store.turnLeft}><i></i><em></em><span >Left</span></div>
      <div class="btn cm-btn cm-btn-dir right" onClick={store.turnRight}><i></i><em></em><span >Right</span></div>
      <div class="btn cm-btn space" onClick={store.toggleSpeed}><i></i><span >加速/减速</span></div>
      <div class="btn reset small" onClick={store.reset}><i ></i><span >Reset</span></div>
      <div class="btn pp small" onClick={store.pauseOrPlay}><i></i><span >{store.data.paused ? 'Play' : 'Pause'}</span></div>
    </div>
  </div>

), rpx(require('./_index.css')))

Define the Store

import Game from '../models/game'

const game = new Game
const { snake, map } = game

game.start()

export default {
  data: {
    map
  },
  turnUp() {
    snake.turnUp()
  },
  turnRight() {
    snake.turnRight()
  },
  turnDown() {
    snake.turnDown()
  },
  turnLeft() {
    snake.turnLeft()
  },
  pauseOrPlay() {
    if (game.paused) {
      game.play()
    } else {
      game.pause()
    }
  },
  reset() {
    game.reset()
  },
  toggleSpeed() {
    game.toggleSpeed()
  }
}

You'll find that the store is thin and only responsible for transiting View action to Model and for automatically mapping data from Model to View.

Frame Rate Control

How to control the main frame rate and the local frame rate? In general, we think that 60 FPS is fluent, so we have a 16 ms interval between timers. The smaller the amount of computation in the core cycle, the closer to 60 FPS:

this.loop = setInterval(() => {
  //
}, 16)

However, some computations do not need to be computed once in 16 seconds, which reduces the frame rate, so the last execution time can be recorded to control the frame rate:

this.loop = setInterval(() => {
    //60 FPS
  if (Date.now() - this._preDate > this.interval) {
    //1000/this.interval FPS
    this._preDate = Date.now()
    if (!this.paused) {
      //Core Loop Logic
      this.tick()
    }
  }
}, 16)

You can use raf-interval base on requestAnimationFrame instead of setInterval to improve performance:

this.loop = setRafInterval(() => {
  //60 FPS
  if (Date.now() - this._preDate > this.interval) {
    //1000/this.interval FPS
    this._preDate = Date.now()
    if (!this.paused) {
      //Core Loop Logic
      this.tick()
    }
  }
}, 16)

File directory description

├─ build           //Compiled files for production environments
├─ config
├─ public
├─ scripts
├─ src
│  ├─ assets
│  ├─ components    //Components that store all view of pages
│  ├─ models        //Store all models
│  ├─ stores        //Store all store
│  └─ index.js      //The entry file will be built into index.html

So MVC, MVP or MVVM?

From the snake-eating source code, we can see that the view(components) and the model are separated, and there is no interdependence. But in MVC, the view depends on the model and the coupling degree is too high, which leads to the greatly reduced portability of the view, so it must not be MVC architecture.

In MVP mode, views do not depend directly on models, and Presenter is responsible for completing the interaction between Models and Views. MVVM and MVP are similar. ViewModel plays the role of Presenter and provides the data source needed for UI view, instead of directly letting View use the data source of Model. This greatly improves the portability of View and Model, such as using Flash, HTML, WPF rendering for the same model switch, such as using different models for the same View. As long as the Model and ViewModel are mapped well, View can be changed very little or not.

From the snake source code, we can see that the data attribute of Presenter (stores) is directly used to render in View (components). The data attribute comes from the attribute of Model(models), and there is no mapping between Model and ViewModel. So it must not be MVVM architecture.

So the snake above belongs to MVP! It's just an evolutionary version of MVP, because the map changes in M will be more customized than View, and the loop from M - > P - > V is automated, and there is no logic in the code. Simply declare dependency:

define('my-game', ['map'] ...

This also avoids the biggest problem of MVVM: the overhead of M-to-VM mapping.

You can also change data in the store and it will automatically update views:

  pauseOrPlay = () => {
    if (game.paused) {
      game.play()
      //auto update view
      this.data.paused = false
    } else {
      game.pause()
      //auto update view
      this.data.paused = true
    }
  }

Because of:

define('my-index', ['paused'], ...

Evolutionary MVP Advantages

Reusability

Decoupling between Model and View, change of one side of Model or View, unchanged Presenter interface, and change of the other side is unnecessary, so the business logic of Model layer has good flexibility and reusability.

Flexibility

Presenter's data changes are automatically mapped to views, making Presenter thin and thin, and View is a passive view. And Presenter-based data can be rendered using any platform, any framework, any technology.

Testability

If there is tight coupling between View and Model, it is impossible to test one of them before the simultaneous development of Model and View is completed. For the same reason, unit testing of View or Model is difficult. Now, the MVP model solves all the problems. In MVP mode, there is no direct dependency between View and Model, and developers can test either of them by injecting simulated objects.

CSS rpx unit

Rpx (responsive pixel) is a unit invented by wxss in wechat mini programe: it can be adapted according to the width of the screen. Set the screen width to 750 rpx. For example, on the iPhone 6, the screen width is 375 px, with 750 physical pixels, 750 rpx = 375 PX = 750 physical pixels, and 1 rpx = 0.5 PX = 1 Physical pixel.

Device	rpx to px (screenwidth/750)	px to rpx (750/screenwidth)
iPhone5	1rpx = 0.42px	1px = 2.34rpx
iPhone6	1rpx = 0.5px	1px = 2rpx
iPhone6 Plus	1rpx = 0.552px	1px = 1.81rpx

Rpx unit is very conducive to the overall workflow of front-end development, because the designer's design draft is designed according to the width of 750, so the front-end page can directly use sketch export ruler for rpx layout.

Rpx can also be used for web development.

rpx principle

Because the device width can only be known at runtime, the mapping of rpx to PX needs to be calculated dynamically at runtime.

export function rpx(css) {
  return css.replace(/([1-9]\d*|0)(\.\d*)*rpx/g, (a, b) => {
    return (window.innerWidth * Number(b)) / 750 + 'px'
  })
}

HTML structure screenshot

Compatibility

The last 2 versions of all modern browsers are supported, including Chrome, Safari, Opera, Firefox, Edge. In addition, Internet Explorer 11 is also supported.

Edge and Internet Explorer 11 require the web components polyfills.

If you want to be compatible with IE8+, Change on line in the package.json:

  "alias": {
    "omi": "omio"
  }

Omio - Omi for old browsers with same api of omi(IE8+)

HTML structure screenshot by omio: