记 `*ngIf` 生命周期导致的一个坑

情景

*ngIf 中的 ViewChild 要在 ngAfterViewInit 生命周期钩子中才能拿到。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
  condition = true;
  @ViewChild('div') div: ElementRef;

  ngOnInit() {
    console.log(this.div); // undefined
  }

  ngAfterContentInit() {
    console.log(this.div); // undefined
  }

  ngAfterViewInit() {
    console.log(this.div); // ElementRef
  }
}
1
2
3
<ng-container *ngIf="condition">
  <div #div></div>
</ng-container>

ALL >>

Angualr 开源组件设计

序

公司的技术展选择的是 Angular ，设计风格也是Google的 Mateiral Design。Goolge官方团队有提供一套Material Angular版本的组件库 material.angular.io。但是国人的操作习惯与国外还是有一些区别，针对这部分业务，公司打算基于官方组件，封装一些自定义的组件，并且开源出来。这一过程当中，主要对以下几个方面做了一些考虑。希望能对大家的开源项目有所帮助。不足之处还望多多包含( ´ ▽ ` )。

Github 欢迎大家Star

  • Debug
  • Demo 及 Demo源代码
  • Build
  • Github开源
  • npm发布

目录结构

directory

Debug

Debug阶段主要考虑到的是路径引入问题，为了让 Demo源代码 能够和生产环境下的使用保持一致，在 PROJECT_ROOT/tsconfig.json (PROJECT_ROOT指项目根目录)中做了一些配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  ...
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@petkit/*": [
        "./src/lib/*"
      ],
      "demo/*": [
        "./src/demo/*"
      ],
      "util/*": [
        "./src/util/*"
      ]
    }
  }
  ...
}

将所有 @petkit/ 开头的路径引入转换至 src/lib/ 下

schema

1
import { NgxHighlightModule } from '@petkit/ngx-highlight';

将被转换为

1
import { NgxHighlightModule } from 'PROJECT_ROOT/src/lib/ngx-highlight';

Demo 及 Demo源代码

这里参考了Angualar Material官方团队的设计（此处Demo和Example概念与官方有出入，官方的示例代码是放在example目录下的，个人觉得都可以，只是项目已经配好了，就不想再去调整得与官方保持一致了）。

material 2

将所有demo目录下的文件作为静态资源，通过http请求源代码，使用 ngx-highlight 高亮语法。 angular.json 配置如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
  "projects": {
    "example": {
      "root": ".",
      "sourceRoot": "src/example",
      "architect": {
        "build": {
          "options": {
            "assets": [
              {
                "glob": "**/*",
                "input": "src/demo",
                "output": "assets/demo"
              },
              "src/example/assets"
            ]
          }
        }
      }
    }
  }
}

注：sourceRoot 是 ng g * 的相对路径

demo 与 example 同级，直接引入会报错

1
2
3
4
5
6
7
8
9
{
  ...
  "assets": [
    // Error: The src/demo asset path must start with the project source root.
    "src/demo",
    "src/example/assets"
  ]
  ...
}

demo会被当作静态资源输出至 dist/example/assets/demo，此时使用http请求对应路径文件即可。

Build

这部分已经有现成的库 ng packagr 可以帮助我们直接打包了

ng-packagr

1
ng-packagr -p ./src/**/package.json

Github 开源

针对 lib 下的源代码，采用 git submodule 的方式可以帮助我们更好地维护开源组件。

关于 git submodule segmentfault 上有篇文章写得蛮不错的 git submodule

1
git submodule add git@github.com:petkit-io/ngx-highlight.git src/lib/ngx-highlight

npm发布

ng-packagr 打包出来的代码便可以直接发布。

1
npm publish path --access public;

npm 上的 organization 需要加上 --access public 才能发布。每次发布完成后自动生成 CHANGELOG，打上新的版本号。

conventional-changelog 可以帮助我们自动生成Change Log
commitlint可以帮助我们规范commit message

自动化

build github npm 三个阶段可以通过脚本自动执行。PROJECT_ROOT/bin/pub.sh：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/usr/bin/env bash
libRoot=src/lib;
distRoot=dist;

buildLib() {
  packagePath=$1;

  npx ng-packagr -p $packagePath;
}

publishLib() {
  libName=$1;
  libPath=$libRoot/$libName;

  buildLib $libPath/package.json;
  npm publish $distRoot/$libName --access public;

  cd $libPath;
  git add .;
  git commit -m "chore(version): publish npmjs" 1>/dev/null 2>&1;
  npm version patch;
  git push;
  git push --tags;
}

publishLib $1

maidfile.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
## pub

发布类库
命令格式 `npx maid pub [lib-name]`

e.g.
- `npx maid pub ts-lib`
- `npx maid pub ngx-material`

```bash
libName=$1

command="./bin/pub.sh $libName"

echo $command

$command

使用：

1
npx maid pub ngx-highlight

End

整体结构还有一些不完善的地方，希望大家多多提些建议，我们也会逐步改善。

Github Star Star Star 重要的事情说三遍o(≧v≦)o

ALL >>

Angular Route Reuse Strategy

场景

路由跳转的过程相当于是对组件的实例化，销毁过程。
这种机制能够应付绝大部分业务场景，但是在大部分管理系统当中，从 列表 -> 编辑 -> 保存 -> 返回列表 该场景需要保存类似搜索，分页等状态数据，此时则需要使用 Angular 的 RouteReuseStrategy 贯穿路由状态并决定构建组件的方式。

RouteReuseStrategy

  • shouldDetach Determines if this route (and its subtree) should be detached to be reused later.
  • store Stores the detached route.
  • shouldAttach Determines if this route (and its subtree) should be reattached.
  • retrieve Retrieves the previously stored route.
  • shouldReuseRoute Determines if a route should be reused.

执行顺序如下：

SimpleReuseStrategy

网上很多例子在这里都是用的 route.routeConfig.path 作为 key。
如果不涉及到lazy load是不会有问题的，但是如果存在 loadChildren，那么route.routeConfig.path就有可能会重复。
于是我将 key 改为了 route['_routerState'].url 取的绝对路径。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
import {
  RouteReuseStrategy,
  DefaultUrlSerializer,
  ActivatedRouteSnapshot,
  DetachedRouteHandle
} from '@angular/router';

export class SimpleReuseStrategy implements RouteReuseStrategy {

  _cacheRouters: { [key: string]: any } = {};

  shouldDetach(route: ActivatedRouteSnapshot): boolean {
    return !route.data.reuse;
  }

  store(route: ActivatedRouteSnapshot, handle: DetachedRouteHandle): void {
    this._cacheRouters[route['_routerState'].url] = {
      snapshot: route,
      handle: handle
    };
  }

  shouldAttach(route: ActivatedRouteSnapshot): boolean {
    return !!this._cacheRouters[route['_routerState'].url];
  }

  retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle {
    if (!route.routeConfig || route.routeConfig.loadChildren || !this._cacheRouters[route['_routerState'].url]) {
      return null;
    }

    return this._cacheRouters[route['_routerState'].url].handle;
  }

  shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
    // 同一路由时复用路由
    return future['_routerState'].url === curr['_routerState'].url;
  }
}

注册策略到 forRoot 模块。

lazy laod 的 forChild 模块是无法注册的

1
2
3
4
5
6
7
8
9
10
@NgModule({
  imports: [
    RouterModule.forRoot(routes),
  ],
  providers: [{
    provide: RouteReuseStrategy,
    useClass: SimpleReuseStrategy,
  }],
  exports: [RouterModule]
})

具体模块使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
const routes: Routes = [{
  path: '',
  children: [{
    path: '',
    redirectTo: 'list',
  },  {
    path: 'list',
    component: ListComponent,
    data: {
      reuse: true,
    }
  }, {
    path: 'detail/:id',
    component: DetailComponent,
  }],
}];

Refs

ALL >>

tsconfig 浅析

相对 vs. 非相对模块导入

根据模块引用是相对的还是非相对的，模块导入会以不同的方式解析。

相对导入是以/，./或../开头的。 下面是一些例子：

1
2
3
import Entry from "./components/Entry";
import { DefaultHeaders } from "../constants/http";
import "/mod";

所有其它形式的导入被当作非相对的。 下面是一些例子：

1
2
import * as $ from "jQuery";
import { Component } from "@angular/core";

相对导入在解析时是相对于导入它的文件，并且不能解析为一个外部模块声明。 你应该为你自己写的模块使用相对导入，这样能确保它们在运行时的相对位置。

非相对模块的导入可以相对于 baseUrl 或通过下文会讲到的路径映射来进行解析。 它们还可以被解析成 外部模块声明。 使用非相对路径来导入你的外部依赖

路径映射

有时模块不是直接放在baseUrl下面。 比如，充分 "jquery"模块地导入，在运行时可能被解释为 "node_modules/jquery/dist/jquery.slim.min.js"。加载器使用映射配置来将模块名映射到运行时的文件。

TypeScript编译器通过使用tsconfig.json文件里的”paths”来支持这样的声明映射。 下面是一个如何指定 jquery的”paths”的例子。

1
2
3
4
5
6
7
8
{
  "compilerOptions": {
    "baseUrl": ".", // This must be specified if "paths" is.
    "paths": {
      "jquery": ["node_modules/jquery/dist/jquery"] // 此处映射是相对于"baseUrl"
    }
  }
}

请注意"paths"是相对于"baseUrl"进行解析。 如果 "baseUrl"被设置成了除"."外的其它值，比如tsconfig.json所在的目录，那么映射必须要做相应的改变。
如果你在上例中设置了 "baseUrl": "./src"，那么jquery应该映射到"../node_modules/jquery/dist/jquery"。

Refs

ALL >>

Angular 组件开源架构

Common

Common 的定义是 公共，参考的 angular，所有开源组件公共的代码都放在这个项目中，包括两部分：

  • ts
  • sass

这部分定义了基于 typescript 的所有公共库，类似lodash，包含组件需要使用的公共的功能。目前包含以下部分：

  • util
  • net
  • error
  • global

代码最终会被编译成 js，并且包含 *.d.ts，无论是 js 还是 ts 项目都可引用。

1
2
3
import {
  SearchArray,
} from '@petkit/common';

Style

这部分定义了基于 sass 的公共样式。目前包含以下部分：

  • animation
  • icon
  • support
  • wechat
  • mp

该部分样式针对不同平台（Web, PC,公众号,小程序等）做了兼容处理，需要在配置文件中配置，默认 750 占满屏幕宽度（类似微信小程序）。

1
2
3
4
5
6
7
8
// _theming.config.scss
@import '~@petkit/style/theming';

$app-primary: mat-palette($mat-cyan);
$app-accent: mat-palette($mat-orange);
$app-warn: mat-palette($mat-yellow, 700, 300, 900);
$app-theme: mat-light-theme($app-primary, $app-accent, $app-warn);
$app-size: size(wp);

ALL >>

Sketch Useful Shortcut

Duplicate

usage command
复制样式 Option + Command + C
粘贴样式 Option + Command + V
复制 Ctrl + Command + arrow
自定义复制 Ctrl + Shift + Command + arrow

Groups

usage command
Bring Forward Alt + Cmd + ↑
Bring to Front Control + Alt + Cmd + ↑
Send Backward Alt + Cmd + ↓
Sent to Back Control + Alt + Cmd + ↓
Select Parent Artboard Esc

ALL >>

Centos 7 安装SSL

安装epel-release

1
2
3
4
5
6
7
yum install -y epel-release

yum search python2-certbot-nginx

# 如果没有对应的package
yum reinstall -y epel-release
yum update -y

安装certbot

1
sudo yum install certbot python2-certbot-nginx

生成ssl

1
2
# 根据提示选择即可
sudo certbot --nginx

Issues

  1. 找不到 nginx 命令
    解决方案：将nginx命令所在目录添加至环境变量

    1
    2
    vim /etc/profile
    PATH=$PATH:/usr/sbin;

  2. 浏览器无法访问 https://xxxx
    解决方案：将443端口添加至防火墙

    1
    2
    3
    4
    vim /etc/firewalld/services/ssh.xml

    # add rule
    <port protocol="tcp" port="443"/>

Refs

ALL >>

Gitlab Docker安装

安装 GitLab

1
docker pull gitlab

运行容器

1
2
3
4
5
6
7
8
9
10
docker run --detach \
  --hostname gitlab.example.com \
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.example.com';" \
  --publish 443:443 --publish 8000:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume /srv/gitlab/config:/etc/gitlab \
  --volume /srv/gitlab/logs:/var/log/gitlab \
  --volume /srv/gitlab/data:/var/opt/gitlab \
  gitlab/gitlab-ce:latest

配置 Nginx 反向代理

1
2
3
4
5
6
7
8
9
10
11
12
13
# /etc/nginx/conf.d/gitlab.conf

server {
  listen 80;
  server_name gitlab.example.com;

  access_log  /var/log/nginx/gitlab.access.log  main;

  location / {
    proxy_pass http://localhost:8000;
    index  index.html index.htm;
  }
}

设置密码

第一次访问 gitlab.example.com 会提示输入密码，用户名默认是 root。

坑

docker0: iptables: No chain/target/match by that name

重启docker即可

1
systemctl restart docker.service

Refs

ALL >>

GitLab CI/CD Runner 入门

我自己用的 Centos 7 x64 ，一下流程都是以 Centos 7 x64 roor权限为基础的

安装

Linux手动安装
使用Docker

1
2
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
yum install gitlab-runner

使用

官方Runner命令手册

1. 注册runner

1
2
3
4
5
6
7
8
9
10
11
12
# register
gitlab-runner register

# register
gitlab-runner register \
  --name runner-name \
  --url http://gitlab.example.com \
  --registration-token my-registration-token \
  --executor shell

# 查看runner列表
gitlab-runner list

这里遇到了个坑，不添加 --executor 会报错
running register from command line,–executor Xresults in:ERROR: Invalid executor specified``
但是官方文档里却没有说必须要加

2. 启动服务

1
2
3
4
5
6
7
8
# 安装服务
gitlab-runner install runner-name --user root

# 启动
gitlab-runner start runner-name

# 查看服务启动状态
gitlab-runner status runner-name

3. 配置runner tag

先说一下 Specific Runners 。

这个tag配置是用来 标识 该 runner 的。

进入[Settings -> CI/CD -> Specific Runners] ，点击编辑按钮(这个按钮我是找了好久才找到)，添加一个tag，在job中可以通过指定tags来定位到对应的 Runner

runners

runners tag

关于 jobs 这里有几篇很不错的文章，我就不多赘述了。

官方文档
gitlab-ci配置详解(二)

ALL >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

嗯？ 嗯～