Zhuotao Lian - freeCodeCamp.org

如何使用 JavaScript 控制台改善工作流程

Zhuotao Lian — Mon, 21 Feb 2022 09:11:00 +0000

原文：How you can improve your workflow using the JavaScript console，作者：Riccardo Canella

作为一名 web 开发者，你一定清楚调试代码的必要性。我们经常使用外部库来记录日志，并在某些情况下格式化并/或显示它们。但浏览器的控制台，远比我们想象的强大。

当提到控制台时，我们会首先想到 console.log，没错吧？但它还拥有许多其他的方法。现在，我们将了解如何充分利用控制台。我还会给出一些提示，以便你更好地理解这些方法。

什么是控制台？

JavaScript 控制台是现代浏览器中内置的开箱即用的开发工具，其界面类似 Shell。它允许开发人员执行以下操作：

查看网页上发生的错误和警告的日志。
使用 JavaScript 命令与网页进行交互。
调试应用程序并直接在浏览器中遍历 DOM。
检查并分析网络活动。

简言之，它使你得以在浏览器中编写，管理和监视 JavaScript。

Console.log，Console.error，Console.warn 和 Console.info

这些可能是最常用的方法，它们允许你传递多个参数。每个参数都将被评估，并以空格分隔连接成字符串，但对于对象或数组，你可以查看其内在属性。

Console.group

该方法允许你将一系列控制台日志（也包括错误信息等）归纳在可折叠的小组下。语法非常简单：只需在 console.group() 后输入所需的 console.log（或输入 console.groupColladed() 来让其以默认方式关闭），然后在末尾添加 console.groupEnd() 来结束分组。

console.group 使用示例

结果如下所示：

Console.table

自从发现 console.table，我的生活发生了改变。在 console.log 中显示 JSON 或超大的 JSON 数组是一种令人恐惧的体验。console.table 使我们可以在漂亮的表格中可视化这些结构，它允许通过传递参数的方式命名列。

console.table 使用示例

结果非常令人满意，并且对于调试非常有用：

Console.count，Console.time 和 Console.timeEnd

对于每一名需要调试的开发人员，这三种方法都如同瑞士军刀。 console.count 能计数并输出在同一行和相同标签上调用 count() 的次数。console.time 能启动以指定输入参数为名的计时器，并且最多能在给定页面上同时运行一万个计时器。一旦启动，我们可以通过调用 console.timeEnd 来停止计时器，并将经过的时间打印到控制台。

console.time 和 console.count 使用示例

输出如下所示：

Console.trace 和 Console.assert

这些方法的功能只是从其被调用的位置打印堆栈跟踪。假设你正在创建一个 JS 库，并且想告知用户错误发生的位置。在这种情况下，这些方法可能会非常有用。console.assert 类似于 console.trace，但仅在条件未通过时才会打印。

如你所见，输出正是产生异常时 React（或任何其他库）向我们所展示的内容。

删除所有的 Consoles?

使用控制台通常会迫使我们消除它们。有时我们会忘记是生产版本（并且几天后才粗心地注意到这些控制台输出）。当然，我不建议任何人在不需要控制台的时候滥用它（在看到输入更改生效后就可以删除控制台命令）。你应该将错误日志或跟踪日志保留在开发模式下，以帮助你调试。不论是在工作中还是在我自己的项目中，我都经常使用 Webpack。它允许你使用 [uglifyjs-webpack-plugin] 1 从生产版本中（按类型）删除所有不想保留的控制台。

const UglifyJsPlugin = require('uglifyjs-webpack-plugin')var debug = process.env.NODE_ENV !== "production";.....optimization: {        minimizer: !debug ? [            new UglifyJsPlugin({                // Compression specific options                uglifyOptions: {                    // Eliminate comments                    comments: false,                    compress: {                       // remove warnings                       warnings: false,                       // Drop console statements                       drop_console: true                    },                }           })] : []}

这个配置确实很简单，且简化了工作，所以愉快地使用控制台吧（但不要滥用它！）

React 服务端渲染解析与实践

Zhuotao Lian — Sun, 13 Sep 2020 09:35:00 +0000

让我们仔细研究下这个能让你用 React 构建通用应用程序的特性吧。

服务端渲染（以下简称 SSR）是前端框架在后端系统上运行时渲染。如果一个应用程序在服务端和客户端都可以渲染，那么它被称作通用应用程序（universal app）。

为何需要 SSR 呢?

我们应该先了解 Web 应用程序在过去 10 年的发展历程，这有助于我们理解这个问题。

这与单页应用（以下简称 SPA）的兴起密切相关。与传统的服务端渲染应用相比，SPA 在速度和用户体验方面具有巨大优势。

但问题随之而来。SPA 的初始服务端请求，通常返回带有一组 CSS 和 JavaScript（JS）链接的空 HTML 文件，然后需要提取外部文件以呈现相关标记。

这意味着用户将等待更长的时间才能进行初始渲染，也意味着爬虫可能会将你的页面解析为空白。

因此，其解决方法是首先在服务端渲染应用，然后在客户端使用 SPA。

SSR + SPA = 通用应用

你可能会在其他文章中看到“同构应用（isomorphic app）”这个词，这跟“通用应用（universal app）”是一回事。

现在，用户不必等待 JS 加载，并能在初始请求返回响应后，立即获得完全渲染的 HTML。

试想一下，这能给使用 3G 网络的用户带来多么大的便利。你几乎可以立即在屏幕上获取内容，而不必浪费 20 多秒等它加载完成。

现在，所有发至服务器的请求都将返回完全渲染后的 HTML，这对 SEO 部门来说是个好消息！

爬虫会像索引网络上的其他静态网站那样，索引你在服务器上呈现的所有内容。

综上所述，SSR 有两个主要优点：

更快的初始页面渲染
完全可索引的 HTML 页面

逐步理解 SSR

我们采取迭代的方法来构建完整的 SSR 示例，从用于服务端渲染的 React API 开始，逐步添加内容。

你可以 follow 这个仓库并查看为每个构建步骤定义的标签。

基本设置

首先，为了使用 SSR，我们需要一台服务器。我们将使用一个简单的 Express 应用来渲染 React 应用程序。

import express from "express";
import path from "path";

import React from "react";
import { renderToString } from "react-dom/server";
import Layout from "./components/Layout";

const app = express();

app.use( express.static( path.resolve( __dirname, "../dist" ) ) );

app.get( "/*", ( req, res ) => {
    const jsx = (  );
    const reactDom = renderToString( jsx );

    res.writeHead( 200, { "Content-Type": "text/html" } );
    res.end( htmlTemplate( reactDom ) );
} );

app.listen( 2048 );

function htmlTemplate( reactDom ) {
    return `
        
        
        
            
            React SSR
        
        
        
            ${ reactDom }
            
        
        
    `;
}

在第十行，我们指定了 Express 要服务的位于输出文件夹中的静态文件。

我们创建了一个处理所有非静态请求的路由，该路由将返回渲染完毕的 HTML。

我们使用 renderToString （第 13 到 14 行）来将起始 JSX 转化成要插入到 HTML 模板中的 string 。

请注意，我们在客户端和服务端代码中使用了相同的 Babel 插件，因此 JSX 和 ES Modules 可以在 server.js 中运行。

客户端上相应的函数目前是 ReactDOM.hydrate，该函数将使用服务端渲染的 React 应用程序，并将附加事件处理程序。

import ReactDOM from "react-dom";
import Layout from "./components/Layout";

const app = document.getElementById( "app" );
ReactDOM.hydrate( , app );

你可以查看仓库中的 basic 标签来浏览完整示例。

搞定了，你刚刚创建了第一个服务端渲染的 React 应用!

React 路由

坦白讲，该应用的功能还不够丰富。所以我们添加一些路由，来看看如何处理服务端部分。

import { Link, Switch, Route } from "react-router-dom";
import Home from "./Home";
import About from "./About";
import Contact from "./Contact";

export default class Layout extends React.Component {
    /* ... */

    render() {
        return (
            
                { this.state.title }
                
                    Home
                    About
                    Contact
                
                
                    
                    
                    
                
            
        );
    }
}

现在 Layout 组件会在服务端渲染多个路由。

我们需要模拟服务器端的路由，主要的更改如下所示。

/* ... */
import { StaticRouter } from "react-router-dom";
/* ... */

app.get( "/*", ( req, res ) => {
    const context = { };
    const jsx = (
        
            
        
    );
    const reactDom = renderToString( jsx );

    res.writeHead( 200, { "Content-Type": "text/html" } );
    res.end( htmlTemplate( reactDom ) );
} );

/* ... */

在服务端，我们需要将 React 应用程序封装进 StaticRouter 组件中并为其提供 location。

附带说明一下，context 用于在渲染 React DOM 时追踪潜在的重定向。这需要通过服务端的 3XX 响应来处理。

你可以查看相同仓库中的 router 标签来浏览有关路由的完整示例。

Redux

现在我们已经具备了路由功能，我们来整合 Redux。

在简单的情况下，我们需要 Redux 来处理客户端的状态管理。但如果我们需要基于状态来渲染部分部分 DOM 呢？这就需要在服务端初始化 Rudux 了。

如果你的应用在服务端上调度操作 ，那就需要捕获该状态并将其和 HTML 一同发送。在客户端，我们将初始状态输入 Redux。

首先来看服务端：

/* ... */
import { Provider as ReduxProvider } from "react-redux";
/* ... */

app.get( "/*", ( req, res ) => {
    const context = { };
    const store = createStore( );

    store.dispatch( initializeSession( ) );

    const jsx = (
        
            
                
            
        
    );
    const reactDom = renderToString( jsx );

    const reduxState = store.getState( );

    res.writeHead( 200, { "Content-Type": "text/html" } );
    res.end( htmlTemplate( reactDom, reduxState ) );
} );

app.listen( 2048 );

function htmlTemplate( reactDom, reduxState ) {
    return `
        /* ... */
        
        ${ reactDom }
        
        
        
        /* ... */
    `;
}

它看上去一点也不美观，但我们需要将完整的 JSON 状态和 HTML 一起发送。

接下来看看客户端：

import React from "react";
import ReactDOM from "react-dom";
import { BrowserRouter as Router } from "react-router-dom";
import { Provider as ReduxProvider } from "react-redux";

import Layout from "./components/Layout";
import createStore from "./store";

const store = createStore( window.REDUX_DATA );

const jsx = (
    
        
            
        
    
);

const app = document.getElementById( "app" );
ReactDOM.hydrate( jsx, app );

请注意，我们调用了两次 createStore，首先在服务端，然后在客户端。但是，我们使用保存在服务端的任一状态来初始化客户端。这个过程就像 DOM hydration。

你可以查看相同仓库的 redux 标签来浏览完整示例。

获取数据

最后一个难题就是数据的加载，这有点棘手。

假设我们有一个提供 JSON 数据的API。

在我们的代码库中，我利用一个公共的 API 获取了 2018 年 Formula 1 赛季的所有事件。假设我们要在主页显示所有事件。

在 React 应用挂载完成并渲染完所有内容后，我们能从客户端调用 API。但这会导致糟糕的用户体验，可能在用户看到相关内容之前，页面会显示正在加载。

我们已经有了 Redux 来在服务端存储数据以及发送数据至客户端。

如果我们在服务端调用 API，将结果存在 Redux 中，然后用相关数据来渲染完整的 HTML 给客户端，会如何呢？

但我们怎么知道应该调用哪些呢？

首先，我们需要以一种不同的方式来声明路由，所以我们看一下路由配置文件。

export default [
    {
        path: "/",
        component: Home,
        exact: true,
    },
    {
        path: "/about",
        component: About,
        exact: true,
    },
    {
        path: "/contact",
        component: Contact,
        exact: true,
    },
    {
        path: "/secret",
        component: Secret,
        exact: true,
    },
];

然后我们静态声明每个组件的数据需求。

/* ... */
import { fetchData } from "../store";

class Home extends React.Component {
    /* ... */

    render( ) {
        const { circuits } = this.props;

        return (
            /* ... */
        );
    }
}
Home.serverFetch = fetchData; // static declaration of data requirements

/* ... */

请注意，你可以随意命名 serverFetch 。

附带说明一下， fetchData 是一个 Redux thunk action，它返回一个 Promise。

在服务端，我们使用一个名为 matchRoute 的特别的函数，它来自 react-router。

/* ... */
import { StaticRouter, matchPath } from "react-router-dom";
import routes from "./routes";

/* ... */

app.get( "/*", ( req, res ) => {
    /* ... */

    const dataRequirements =
        routes
            .filter( route => matchPath( req.url, route ) ) // filter matching paths
            .map( route => route.component ) // map to components
            .filter( comp => comp.serverFetch ) // check if components have data requirement
            .map( comp => store.dispatch( comp.serverFetch( ) ) ); // dispatch data requirement

    Promise.all( dataRequirements ).then( ( ) => {
        const jsx = (
            
                
                    
                
            
        );
        const reactDom = renderToString( jsx );

        const reduxState = store.getState( );

        res.writeHead( 200, { "Content-Type": "text/html" } );
        res.end( htmlTemplate( reactDom, reduxState ) );
    } );
} );

/* ... */

这样，我们就获得了当 React 在当前 URL 下被渲染成字符串时所需装载的组件列表。

我们收集了 data requirements 并等待所有调用的 API 的返回值。最终，我们恢复服务端渲染，这时 Redux 中已经得到了数据。

可以查看相同仓库的 fetch-data 标签来浏览完整示例。

你可能会注意到，这导致了性能损失，因为我们在获取数据之后才进行渲染。

这时你就需要权衡了，你需要尽可能弄清楚哪些调用是必不可少的。举例来说，对于一个电商应用，获取产品列表是至关重要的，需要尽快加载，但是价格以及侧边栏选择器可以被延迟加载。

Helmet

作为 SSR 的奖励，让我们来看看 SEO。在使用 React 时，你可能想在标签中设置不同的值，例如 title , meta tags , key words 等等。

请注意，标签通常不属于 React 应用。

在这种情况下，react-helmet 提供了相应的解决方案，并对 SSR 有着很好的支持。

import React from "react";
import Helmet from "react-helmet";

const Contact = () => (
    
        This is the contact page
        
            Contact Page
            
        
    
);

export default Contact;

你只需要将 head 数据添加到组件树的任意位置，这使得你可以在客户端更改已挂载的 React 应用以外的值。

现在，我们添加了对 SSR 的支持：

/* ... */
import Helmet from "react-helmet";
/* ... */

app.get( "/*", ( req, res ) => {
    /* ... */
        const jsx = (
            
                
                    
                
            
        );
        const reactDom = renderToString( jsx );
        const reduxState = store.getState( );
        const helmetData = Helmet.renderStatic( );

        res.writeHead( 200, { "Content-Type": "text/html" } );
        res.end( htmlTemplate( reactDom, reduxState, helmetData ) );
    } );
} );

app.listen( 2048 );

function htmlTemplate( reactDom, reduxState, helmetData ) {
    return `
        
        
        
            
            ${ helmetData.title.toString( ) }
            ${ helmetData.meta.toString( ) }
            React SSR
        
        
        /* ... */
    `;
}

现在，我们得到了一个功能完备的 React SSR 示例！

我们从使用 Express 应用进行简单的 HTML 渲染开始，逐步增加路由、状态管理和数据获取，最终，我们处理了 React 应用以外的更改。

最终的代码库位于前面提到的相同仓库的 master 分支上。

总结

如你所见，SSR 算不上多大的难题，但它可以变得复杂。如果你一步步构建自己的需求，那会简单很多。

在应用中添加 SSR 有必要吗？和往常一样，这需要结合实际情况。如果你的网站是公开的，并且可以供成千上万的用户访问，那答案就是必须的。但如果你要构建一个工具/仪表板之类的应用，那就没什么必要了。

无论如何，利用好通用应用，是前端社区的一大进步。

你用过类似 SSR 的方法吗？或者你是否认为这篇文章存在纰漏？欢迎留言讨论。

如果你认为这篇文章对你有帮助，请在社区中分享吧！

原文：https://www.freecodecamp.org/news/demystifying-reacts-server-side-render-de335d408fe4/，作者：Alex Moldovan

正确理解 CSS 选择器的权值

Zhuotao Lian — Wed, 15 Jul 2020 07:20:00 +0000

前言

直接说结论，CSS 选择器（selector）的权值（以下直接称为“CSS 权值”）不应以进制来理解，因此进制既不是 10，100，也不是 256。
笔者看到过很多文章，发现有很大一部分人认为 CSS 权值是 256 进制甚至是 10 进制的。
下文首先解释 CSS 权值应该如何正确理解，然后尝试解释为何有人会理解为 256 进制。
本文代码运行环境：

Google Chrome 版本 80.0.3987.149（正式版本）
Firefox 74.0 (64 位)
Opera 版本：67.0.3575.97
Safari 版本13.0.2 (15608.2.30.1.1)
抱歉无法在 Edge 和 IE 上测试

1、何为 CSS 权值？如何正确理解与比较？

1.1 定义

Specificity is the means by which browsers decide which CSS property values are the most relevant to an element and, therefore, will be applied. Specificity is based on the matching rules which are composed of different sorts of CSS selectors. (MDN web Docs)

If there are two or more conflicting CSS rules that point to the same element, the browser follows some rules to determine which one is most specific and therefore wins out. Think of specificity as a score/rank that determines which style declarations are ultimately applied to an element. (w3schools)

在英文文档中，用 Specificity 这个单词来描述所谓的 CSS 权值。

Specificity 是“特异性”的意思，CSS Specificity 是应用于 CSS 选择器的规则集，以确定哪些样式应用于元素。简单地说就是特异性决定了哪些样式起作用。那么应该如何理解以及比较呢？

1.2 理解及比较

Every selector has its place in the specificity hierarchy. There are four categories which define the specificity level of a selector.

每个选择器在特异性层次结构中都有其位置。有四个类别定义了选择器的特异性级别。
那么我们可以理解为 A, B, C, D 四个类别，初始各个位置都是 0，即 0，0，0，0。
有一张图描述得很好：

四个类别：

A: 内联样式，写在 HTML 标签中的 style=""，属于 A 类。若有，那么 A 位置加一，可以理解为 1，0，0，0。
B: id 选择器（如 #id1），如 id=""，属于 B 类，若有，那么 B 位置加一。即 0，1，0，0。
C: 类选择器（如 .class1）、伪类（如 :hover）、属性（如 [ type="radio" ]）为 C 类。有则 C 位置加一，即 0，0，1，0。
D: 标签（如 div），伪元素为 D 类，若有则 D 位置加1，即 0，0，0，1。

规律与注意事项

Universal selector (*), combinators (+, >, ~, ' ', ||) and negation pseudo-class (:not()) have no effect on specificity. (The selectors declared inside :not() do, however.)

通配符选择器（*），组合选择器（+, >, ~, '', ||）和否定伪类（: not ( )）对特异性没有影响。但是在:not( )内部声明的选择器可以。

When an important rule is used on a style declaration, this declaration overrides any other declarations.

!important 是一种特殊的声明，它的级别高于其他所有的普通声明。这个链接里有一些关于 !important 的使用注意事项，中文资料也很多，不再赘述。
比较时，A, B, C, D 四位依次比较，A 较大的权重大，不用看后面。当 A 相同时，比较 B。以此类推。
当 A, B, C, D 相同时，后面的规则会覆盖前面的规则。

A class selector beats any number of element selectors

一个类选择器可以击败任意数目的元素选择器。这就说明进制的概念在理论上是不应存在的。即 0, 0, 1, 0 应大于 0, 0, 0, D。 D 可以取任意值。因此比较权重时，还是应该按位去比。

这个链接里也有一张有意思的图，方便大家理解。

1.3 举例说明

  body div {/*此处权重 = 0，0，0，2*/
      background-color: red;
  }
  div {/*此处权重 = 0，0，0，1*/
      height: 100px;
      width: 100px;
      background-color: green;
  }
  Test CSS Specificity

    div {
		width: 100px;
		height: 100px;
    }
    .testClass.testClass {/*权重为0，0，2，0*/
        background-color: yellow;
    }
    .testClass {/*权重为0，0，1，0*/
        background-color: black;
    }

    Test CSS Specificity

这里显示为黄色，说明重复的类选择器权重也会累计。

    div{
		width: 100px;
		height: 100px;
    }
    .testClass.testClass {/*权重为0，0，2，0*/
 		background-color: yellow;
    }
    .testClass {/*权重为0，0，1，0*/
        background-color: black;
    }
    #testClass {/*权重为0，1，0，0*/
        background-color: blue;
    }  	
    Test CSS Specificity

各种各样的例子网上很多，不再赘述。下面第二部分举一些反例证明进制的思想是不合适的。

2、为何进制不是10，100或256呢？

2.1 反例

十一个类选择器，与一个 id 选择器。显而易见的，进制并不是 10。最后还是 id 选择器奏效。

div{
    width: 100px;
	height: 100px;
}
#testId {/*权重为0，1，0，0*/
    background-color: purple;
}  	.testClass1.testClass2.testClass3.testClass4.testClass5.testClass6.testClass7.testClass8.testClass9.testClass10.testClass11 {/*权重为0，0，11，0，并没有任何作用*/
    background-color: red;
}

Test CSS Specificity

256个类选择器能干掉一个 id 选择器吗？

#id {/*权重为0，1，0，0*/
     background: red;
}
   
   .c000.c001.c002.c003.c004.c005.c006.c007.c008.c009.c010.c011.c012.c013.c014.c015.c016.c017.c018.c019.c020.c021.c022.c023.c024.c025.c026.c027.c028.c029.c030.c031.c032.c033.c034.c035.c036.c037.c038.c039.c040.c041.c042.c043.c044.c045.c046.c047.c048.c049.c050.c051.c052.c053.c054.c055.c056.c057.c058.c059.c060.c061.c062.c063.c064.c065.c066.c067.c068.c069.c070.c071.c072.c073.c074.c075.c076.c077.c078.c079.c080.c081.c082.c083.c084.c085.c086.c087.c088.c089.c090.c091.c092.c093.c094.c095.c096.c097.c098.c099.c100.c101.c102.c103.c104.c105.c106.c107.c108.c109.c110.c111.c112.c113.c114.c115.c116.c117.c118.c119.c120.c121.c122.c123.c124.c125.c126.c127.c128.c129.c130.c131.c132.c133.c134.c135.c136.c137.c138.c139.c140.c141.c142.c143.c144.c145.c146.c147.c148.c149.c150.c151.c152.c153.c154.c155.c156.c157.c158.c159.c160.c161.c162.c163.c164.c165.c166.c167.c168.c169.c170.c171.c172.c173.c174.c175.c176.c177.c178.c179.c180.c181.c182.c183.c184.c185.c186.c187.c188.c189.c190.c191.c192.c193.c194.c195.c196.c197.c198.c199.c200.c201.c202.c203.c204.c205.c206.c207.c208.c209.c210.c211.c212.c213.c214.c215.c216.c217.c218.c219.c220.c221.c222.c223.c224.c225.c226.c227.c228.c229.c230.c231.c232.c233.c234.c235.c236.c237.c238.c239.c240.c241.c242.c243.c244.c245.c246.c247.c248.c249.c250.c251.c252.c253.c254.c255 {/*权重为0，0，256，0，并没有任何作用*/
     background: blue;
}
   
test {
     display: block;
     height: 100px;
     width: 100px
}
test 256

这个 256 的测试代码修改自张鑫旭的一篇博客。
结果显而易见，256 个 class 并不能“击败”一个 id，所以进制不是 256。
100 就不再试了。所以进制的说法，从实际看来，也是不合适的。

BUT！你可以发现，在张鑫旭的这篇博客中（2012 年 08 月 20 日），256 个类选择器确实干掉了一个 id 选择器！那也就是说，进制的说法至少在当时是有据可依的。那具体是为什么呢？结合我搜索到的资料，简单的“猜想”一下。

2.2 为什么会有进制的说法？

通过张鑫旭博客，我们可以看到，在当时，确实 256 个类选择器干掉了一个 id 选择器。

在这篇博客中，他提到了：

据说，查看FireFox浏览器的源代码，发现，所有的类名(classes)都是以8比特数据类型存储的。对比特稍稍了解的人都知道，8比特所能hold的最大值就是255. 所以你想啊，当同时出现256个class, 势必会越过其边缘，溢出到id区域。

Gecko overflows the count of classes into the count of IDs, each of which holds 8 bits.

— Cameron McCormack (@heycam) August 16, 2012

根据一个Opera员工的信息，Opera浏览器class类名是以16比特数据类型存储的。因此，该浏览器要想发生class溢出到id的话，需要连续65536个class. 也不知道是不是因为16比特字符串比8自己的更影响选择器引擎

yes, opera uses 16 bits instead of 8. bring on 65536 classes…

— patrick h. lauke (@patrick_h_lauke) August 16, 2012

也就是说，虽然标准是那么规定的，但是落实到浏览器上，实际效果确是不尽相同。
因此我个人认为，这种不存在进制的，按级别按位比较的方式，应该更合理一些。

写在最后：
以上是我个人的理解，欢迎批评指正。
大家如对 CSS 的其他话题感兴趣，也欢迎通过我的邮箱与我交流学习。

用 7 行 JSON 代码将你的网页变成移动应用

Zhuotao Lian — Mon, 07 Oct 2019 11:07:00 +0000

一种将 web 引擎与应用程序融合的新方法

如果我告诉你题图中的 7 行橙色的 JSON 代码 就能将网站变成移动应用，你怎么看？不需要使用框架 API 重写你的网站就能让它像移动应用一样呈现。就让你现有的网站保持原样，利用简单的 URL 引用将其打包成原生应用即可。

倘若如上，你只需略微调整 JSON 代码，就可以访问所有的原生 API，原生 UI 组件以及实现原生视图转换。

下面是一个最简单的范例：

你可以发现我嵌入了一个 github.com 网页，但其余布局都是本地 UI 组件，就像导航栏和底部标签栏。并且原生切换效果是自动生成的，你无需使用任何 API 重写网站。

你可能迫切地想问：”这很酷，但除了在原生应用框架中显示网页，你还能做其他有意义的事吗？“

问得好！因为这就是本篇文章的主题。你只需要创建一个 在 Web 视图和应用程序之间的双向通信信道 ，这样父应用就可以触发 Web 视图内的任何 JavaScript 函数，并且 Web 视图可以从外部调用原生 API。

这有个简单的例子：

请注意，此视图包含：

1.原生导航栏，包括内置的切换功能。

2.一个 Web 视图，其中嵌入了 Web 应用程序：二维码生成器。

3.底部的原生聊天输入组件。

这些都可以通过调整上面的 JSON 代码来实现。

最后，请注意，二维码会随着你输入内容的不同而变化。此输入会触发二维码 Web 应用内的 JavaScript 函数，从而重新生成二维码。

目前还没有试图从根本上解决 “将 Web 视图无缝集成到原生应用程序” 这一问题的应用开发框架，因为它们都专注于完全的原生或 HTML5。

每当你听到有人谈论移动应用的未来，你都可能会听到他们谈论 “究竟是 HTML5 还是原生方法会胜出呢？”

人们觉得 原生 和 HTML 是不能共存的，更不会认为它们能相辅相成，甚至实现看似不可能的功能。

在本文中，我将阐述：

为什么将 Web 引擎和原生组件相融合通常是一个好主意。
为什么 HTML 和原生的无缝融合很困难，以及如何实现。
更重要的是，你如何利用它来快速构建你自己的应用程序。

为什么要在原生应用中使用 HTML ？

在进一步探讨之前，让我们首先讨论一下这个主意是好是坏，以及在何时你会想采用这种方法。这儿给出一些潜在的使用案例：

1. 使用 Web 原生功能

你的应用的某些部分可能更适合用 Web 引擎实现。例如，Websocket 是一个为 Web 环境设计的原生 Web 功能。在这种情况下，安装本质上 “模拟” Websocket 的第三方库，就不如使用内置的 Web 引擎（ iOS 版的 WKWebView 和 Android 版的 WebView ）。

无需安装额外的代码，你就可以免费实现。这也引出了下一点。

2. 避免较大的二进制文件

你可能想快速使用一些功能，但它们需要一个庞大的第三方库。

比如，为了以原生方式实现一个二维码生成器，你可能需要安装某些第三方库，而它们将大大增加文件的体积。但如果你使用 Web 视图引擎以及通过一个简单的