Posted on

一事无成，走走停停，是徘徊，还是前行

Posted on 
Best way to remember thing is writing it down.

Forget about those fancy description, write this down with my own words:
forEach() perform callback for each element in array, THAT IS IT! nothing is return, doing callback inplace.

map() create a new array, then do the callback for each element in the array, so it does return a new array.

that’s it, now you can read official documentation from MDN.

Array.prototype.forEach()

According to JavaScript | MDN

forEach() executes the provided callback once for each element present in the array in ascending order. It is not invoked for index properties that have been deleted or are uninitialized (i.e. on sparse arrays).

Array.prototype.map()

According to JavaScript | MDN)

map calls a provided callback function once for each element in an array, in order, and constructs a new array from the results. callback is invoked only for indexes of the array which have assigned values, including undefined. It is not called for missing elements of the array (that is, indexes that have never been set, which have been deleted or which have never been assigned a value).

Posted on

偶尔需要自己从零开始搭建project，一个好的目录结构觉得了一个项目的可维护性和可拓展性

一个好的目录结构对一个好的项目而言是非常必要的。

一个好的目录结构应当具有以下的一些特点：

1、解耦：代码尽量去耦合，这样代码逻辑清晰，也容易扩展

2、分块：按照功能对代码进行分块、分组，并能快捷的添加分块、分组

3、编辑器友好：需要更新功能时，可以很快的定位到相关文件，并且这些文件应该是很靠近的，而不至于到处找文件

比较推荐的目录结构：

多页面应用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|-- src/ 源代码目录
    |-- page1/ page1 页面的工作空间（与这个页面相关的文件都放在这个目录下）
        |-- index.html html 入口文件
        |-- index.js js 入口文件
        |-- index.(css|less|scss) 样式入口文件
        |-- html/ html 片段目录
        |-- (css|less|scss)/ 样式文件目录
        |-- mock/ 本地 json 数据模拟
        |-- images/ 图片文件目录
        |-- components/ 组件目录（如果基于 react, vue 等组件化框架）
        |-- ...
    |-- sub-dir/ 子目录
        |-- page2/ page2 页面的工作空间（内部结构参考 page1）
          |-- ...
    |-- ...
|-- html/ 公共 html 片段
|-- less/ 公共 less 目录
|-- components/ 公共组件目录
|-- images/ 公共图片目录
|-- mock/ 公共 api-mock 文件目录
|-- ...

单页面应用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|-- src/ 源代码目录
    |-- page1/ page1 页面的工作空间
        |-- index.js 入口文件
        |-- services/ service 目录
        |-- models/ model 目录
        |-- mock/ 本地 json 数据模拟
        |-- images/ 图片文件目录
        |-- components/ 组件目录（如果基于 react, vue 等组件化框架）
        |-- ...
    |-- module1/ 子目录
        |-- page2/ page2 页面的工作空间（内部结构参考 page1）
    |-- ...
|-- images/ 公共图片目录
|-- mock/ 公共 api-mock 文件目录
|-- components/ 公共组件目录   
|-- ...

参考：

Posted on

到底什么是DOM

The Document Object Model（文档对象模型）, 或者叫DOM，是网页的接口。它本质上是网页的API，允许程序读取和操作页面内容，结构和样式。接下来让我们进一步解析。

一个网页是如何构建的

一个浏览器如何从HTML源文档到视窗中展现样式和交互式页面的过程被称为“关键渲染路径（Critical Rendering Path）”,虽然这个过程可以被分解为多个步骤， 但是这些步骤大致可以分为两个阶段。第一个阶段涉及浏览器解析文档到最终确认渲染的内容，第二阶段则是浏览器执行渲染。

render tree

第一阶段的结果被称之为“渲染树（render tree）”。HTML元素及其相关样式在页面上呈现出来的表达形式被称之为渲染树。为了构建树结构，浏览器需要两个东西：

  1. The CSSOM, 与元素相关的样式表达（译者： 就是css文档）
  2. DOM， 元素表达 （译者： 就是HTML文档）

DOM如何被创造出来（看起来什么样）

DOM是源HTML文档基于对象的表现形式。它有些差异，但是它本质上是将HTML文档的结构和内容转化为可以被各种程序使用的一种对象模型。

DOM的对象结构表现为所谓的“节点树（node tree）”，它之所以被这么叫是因为它可以被看作一个单个父茎的树，其有着若干个分支，每个都可能有枝叶。在这种情况下，父“干”是根元素，孩子“分支”是嵌套元素，而“叶”是元素中的内容。

来看看一下这个例子：

1
2
3
4
5
6
7
8
9
10
<!doctype html>
<html lang="en">
 <head>
   <title>My first web page</title>
  </head>
 <body>
    <h1>Hello, world!</h1>
    <p>How are you?</p>
  </body>
</html>

以上文档的节点树表达形式：

example 1 node tree

DOM 不是什么

根据上述例子，DOM是源HTML文档的一对一映射。 但是，正如我所提到的，还是有差异的。 为了完全理解DOM是什么，我们需要看看它不是什么。

DOM不是你的源代码

尽管DOM是从源HTML文档创建的，但它并不总是完全相同。 这里有两个实例展示了：DOM可以与源HTML不同。

1. 当HTML无效时

DOM是有效HTML文档的接口。在创建DOM的过程中，浏览器可能会矫正HTML中的无效代码。

例子：

1
2
3
4
<!doctype html>
<html>
Hello, world!
</html>

上述文档中缺失<head>和<body>元素，对于有效HTML来说这是必需的。如果我们查看生成的DOM树，我们会发现这里被自动矫正了：

example 2 node tree

2. 当JavaScript修改DOM时

DOM除了作为查看HTML文档内容的接口之外，还可以被修改，使其成为一个实时资源。

例如，我们可以使用JavaScript为DOM创建其他节点。

1
2
3
4
var newParagraph = document.createElement("p");
var paragraphContent = document.createTextNode("I'm new!");
newParagraph.appendChild(paragraphContent);
document.body.appendChild(newParagraph);

这样就可以更新DOM， 但是当然并不是直接改变HTML文档

DOM并不是你在浏览器里看到的那样（例如： 渲染树）

你在浏览器视窗中看到的渲染树，正如我所提到，它是DOM和CSSOM的结合，真正把DOM和渲染树区分开的是后者只包含最终将在屏幕上绘制的内容。

因为渲染树仅仅关注与渲染的内容本身，所以它会排除视觉上隐藏的元素。比如：具有display: none的元素。

1
2
3
4
5
6
7
8
<!doctype html>
<html lang="en">
  <head></head>
  <body>
    <h1>Hello, world!</h1>
    <p style="display: none;">How are you?</p>
  </body>
</html>

在DOM里将包含<p>元素：

example 3 node tree

但是，渲染树以及因此在视窗中看到的内容却不包含该元素。

example 4 node tree

浏览器中的DOM并不是DOM

一点点小差异，因为DevTools元素检查器提供了最接近的DOM。但是，DevTools检查器包含里不在DOM中的其他信息。

最好的例子是CSS伪元素。Pseudo-elements created using the ::before and ::after selectors form part of the CSSOM and render tree, but are not technically part of the DOM.。因为DOM仅仅由源HTML文档构建，不包含应用于元素的样式。

尽管伪元素不是DOM的一部分，但他们仍然在我们的DevTools元素检查器中。

element inspector

这就是为什么伪元素不能被JavaScript作为目标的原因，因为它们不是DOM的一部分。

总结

DOM是一个HTML文档的接口。它被浏览器用作确认在视窗中呈现内容的第一步，并通过Javascript程序来修改页面的内容，结构，样式。

虽然与其他形式的源HTML文档类似，但是DOM在许多方面还是有所不同：

  • 有效HTML（It is always valid HTML）
  • 可通过Javascript修改的实时模型（It is a living model that can be modified by JavaScript）
  • 不包含伪元素（It doesn’t include pseudo-elements）
  • 包含隐藏元素（It does include hidden elements）

关于原文作者

原文是来自Ire Aderinokun发表在bitsofco.de上面的。

译者语

工作学习前端两年多，往往这些浅显，基础的知识最容易被忽略。Ire Aderinokun写里一系列DOM相关的文章，包括shadow DOM， Virtual DOM等等，我会争取总翻译出来。有时候我不会翻译，或者感觉原文效果更好的，我就直接把原文po出来。

Posted on

静态化渲染和服务器渲染二者都为你的APP页面进行HTML渲染， 然而他们之间有个巨大的差异。。。
Static rendering and server rendering both involve rendering HTML for each of your app’s pages- but there’s one major difference between them…

也许你曾听过静态化渲染与服务器渲染，你也知道他们二者都可以提高SEO，让你的网站或者APP进行生成HTML页面。当然你也可以使用 ReactDOMServer.renderToString()实现上述两种目的。

这么说，他们两者看上去是一种东西？对吧？他们几乎几乎差不多一样，接下来让我解释下。

热切的静态化渲染， 慵懒的服务器渲染

静态和服务器渲染都参与到了对HTML的生成， 不同点在于静态化渲染只在编译的时候发生一次，然而服务器渲染则是按需发生根据用户的每一次请求。

静态化渲染

当静态化渲染的时候，你需要在每次用户访问前就生成好一个单一的HTML文件。 接着你把这些生成好的文件都存放在云端服务中，比如亚马逊的S3，或者运行中的Nginx服务器。

static rendering image

静态化渲染的优势在于能够对服务器请求做到无脑的快速，因为在处理过程中不需要再去生成什么文件。 实际上, 由于你的网站的响应都是提前生成好的，那么你就可以存放文件在全世界任何角落的CDN。这样可以让你的网站打到一个不可思议的响应速度。但是这也是有代价的。

使用静态化渲染时，你需要给每一个可能的请求提前生成响应。 对于那些对高质量内容的网站来说，这样是没问题的——静态化渲染工具比如Navi可以在仅仅几秒内生成上百个网页。但是如果你需要搭建一些无法预测所以用户请求的项目，比如一个搜索引擎？或者你有一堆用户生成内容，根据每一个请求来改变响应？这种情况的话，你需要的是服务器渲染。

服务器渲染

按React的说法，服务器渲染指的是按照每一个请求生成HTML的过程。通常，你在服务器上架设一些后端框架比如express或者Next.js，根据每个请求渲染你的React app， 就像更传统的PHP和Rails框架网站一样。

server rendering image

服务器渲染总是慢于静态内容的。然而，你还得为了让速度更快些捣鼓一堆东西，当然这样的延迟是否重要取决于你的商业需求。

当然， 服务器渲染的速度短板，成就了他的灵活性，它允许你：

  • 响应任何用户发出的请求 —— 即使是你可能没预想过的
  • 从数据库中抓取最新的内容，而不是过时的静态文件
  • 对没授权的用户选择性的隐藏内容

那么我该选哪一个？

这个问题的 ~ 答案 ~ 当然是 ~~~ 看情况

如果静态渲染可行的话（作者指对于你当前的需求），它是一个快速，低廉，简单的解决方案。但是，如果你的网站需要达到以下这些需求，你则需要服务器渲染：

  • 如果你不能预测所有可能性的用户请求
  • 如果响应内容需要根据不同用户进行改变
  • 如果响应内容很快过时

请记住，如果需要为每个页面提供特定的HTML用于SEO，这些需求将仅使服务器渲染呈现成为必要的选择。举个例子，一个社交网络或者在线电商最好还是用服务器渲染来搭建。

另一方面来说，如果SEO无关紧要的话，例如，一个存在于登录屏幕后面的应用程序 - 然后您的应用程序只需要一个HTML文件。 在曾经，静态渲染可能是最好的选择。但是，最近静态和服务器渲染工具的改进大多缩小了简单性差距。

渲染工具

几年前当我开始用React来构建网站的时候，不管是静态还是动态，都很难。我甚至写了篇文章告诉你别这么做,但是近年来，改变了很多。

有越来越多基于React的工具来静态化渲染网站和APP，Gatsby就是个很受欢迎，高强度的选择。对于一些更简单的东西，你可以选择Navi,一个跟Create-react-app一起使用的框架。

对于服务器渲染，有两种选择（作者只提到这两个），Next.js和Express,使用Next.js，您可以获得一个开箱即用的完整框架和托管解决方案——同时你的整个项目也绑定到Next.js。如果Next.js对你来说不是好的选择，你也可以试试比较传统化的Express。

鸡毛蒜皮的小事

最后，让我解释您正在阅读的网站（这里的网站指原文post的网站frontarm.com）如何运作。 Frontend Armory 是静态渲染的,每次内容更改时，都会使用Navi重新构建站点，然后将其推送到S3。 然后，当您发送请求时，它首先会检查与CloudFront在地理位置上接近您的缓存版本，然后再从S3请求它（如果失败）。

关于原文作者

原文是由 Frontend Armory的编辑James K Nelson发表在Frontend Armory上面的。

译者语

本篇文章，只是很基本的讲解了一下静态渲染和服务器渲染的一些基本特点和区别，适合入门新人，对两种渲染没有基本概念的读者。

由于近期对Frontend Armory这个网站的兴趣，发现上面有些不错的前端基本概念文章，所以想以此为长期学习的地方，通过翻译来提升自己，也帮助他人。

Posted on

最近萌发出通过翻译一些平常看到的国外技术博客的想法

出发点:

  • 目前自己博客内容没什么营养，偶尔也才写一两篇技术性博客，还没什么营养，想通过翻译技术博客来增加自己博客的内容
  • 提高中文写作能力，中文写作水平从高一出国后就止步了
  • 提高英文阅读能力，日常生活在，英语说还行，但是阅读量几乎没有
  • 借此来让自己对某件事无的坚持，积累自己的读者，做点有内容的东西， 从简单容易坚持的项目出发



Posted on

supreme restock monitoring tool (hold)

  • Node.js

  • cheerio

    Done:成功的检查supreme官网的自动补货信息，自动发送Slack bot msg 到对应channel

    Imcomplete: 无法再在云端运行，HTML request return 403 error

VScode todo extension (hold)

  • Javascript

    Done:简单的vscode command

A image scraping app (dropped)

  • Node.js

  • cheerio

    Done: 基本能从6park爬取一定数量的图片，成功部署heroku

    Incomplete: 页面载入太慢，图片链接json文件无法更新

黑胶唱片推荐网站 (working)

  • Gastbyjs
  • Node.js

  • Netlify 部署

    Done: 部署到Netlify

    Imcomplete: 内容创作

Posted on

Remove dead code

Dead code is just as bad as duplicate code. There’s no reason to keep it in your codebase. If it’s not being called, get rid of it! It will still be safe in your version history if you still need it.

Bad:

1
2
3
4
5
6
7
8
9
10
function oldRequestModule(url) {
  // ...
}
function newRequestModule(url) {
  // ...
}
const req = newRequestModule;
inventoryTracker('apples', req, 'www.inventory-awesome.io');

Good:

1
2
3
4
5
6
function newRequestModule(url) {
  // ...
}
const req = newRequestModule;
inventoryTracker('apples', req, 'www.inventory-awesome.io');

Posted on

Limiting the amount of function arguments

It is very important and useful to limit the amount of function arguments, because it makes testing your function easier. Having more than three leads to a combinatorial explosion where you have to test tons of different cases with each separate argument. Using a object if you can’t avoid a situation requires more than 3 arguments.

Bad:

1
2
3
function createMenu(title, body, buttonText, cancellable) {
  // ...
}

Good:

1
2
3
4
5
6
7
8
9
10
function createMenu({ title, body, buttonText, cancellable }) {
  // ...
}
createMenu({
  title: 'Foo',
  body: 'Bar',
  buttonText: 'Baz',
  cancellable: true
});