02月27, 2019

关于脚手架和UI的那些事

和大家聊一下最近我和我所在的团队在做的一些事。

离春节过去其实也没多久,现在的状态在半恢复中。似乎我的公众号也没啥人关注,本来还想着提供一些福利的(学习资料相关),不过也没事。

搭建私服

这是年前确定下来的,现在运维团队帮我们搭建完成,用的是:verdaccio

噢对,中间踩了一个坑是:yarnrc不需要配置registry,只要根目录下有一个.npmrc指向私有源,然后在yarn add xx,就会走私服。理由是:

alt

另外还有一点是关于权限的控制,访问及publish,具体可以参考这两篇文章:

脚手架

先来一个定义吧?什么叫脚手架?

我对它的理解是:能够提供基础的模板文件、能够提供dev、build、proxy的功能,甚至也可以提供一些规范:如eslint插件等。

所以就有了这个成果:

alt

一些说明

由于去年部门大整合,所以目前新团队的项目既有react,又有vue。。但老实讲,新项目用react还是vue,这个容易打架,唯一能定下来的是移动端就用vue。不过我只是当小弟的,也只能听从上级的安排,就个人来说,更加倾向于react。

所以在上面的目录中,你会看到有cui-react-scriptscui-vue-scripts的存在。

cui

cui是整个的脚手架,它提供类似vue的功能:

alt

这里面借助了gitlab这个强大的npm包,来读取放在内网gitlab的模板。

cui-scripts

cui-react-scriptscui-vue-scripts提供两个基本的命令:

  • start
  • build

alt

alt

当然options在未来肯定会变得更加健壮。目前有的这些,是我这边参考了去年做的项目。

去年做的项目,可能是我这辈子接触的最大项目了,面向全国的税务网站及应用APP。在那个项目中,和两个阿里大佬学了很多,也把他们好的东西直接借鉴到新写的这个脚手架里面,比如proxy这一块。

proxy

这个做法是这样的:根目录下有一个配置文件,.rdrc.js,然后它会导出一个对象。在server.js中去require,通过http-proxy-middleware这个模块实现最终的代理。

这里面涉及到:

  • 本地mock
  • 远程mock

本地mock

本地mock的写法,可以是:json文件、js文件(导出一个json)、函数。

function localMockHandler(req, res) {
  const reqUrl = url.parse(req.baseUrl);

  const reqPath = reqUrl.path;
  const apiIndex = req.baseUrl.slice(1).indexOf('/') + 1;
  const mockPath = path.resolve(utils.PROJ, `mock/${reqPath.slice(apiIndex)}`);
  const mockJsPath = path.resolve(mockPath, 'index.js');
  const mockJsonPath = path.resolve(mockPath, 'index.json');
  let mock;

  if (fs.existsSync(mockJsPath)) {
    /* eslint-disable import/no-dynamic-require */
    /* eslint-disable global-require */
    proxyDebugger(`${reqPath} -> ${path.relative(utils.PROJ, mockJsPath)}`);
    mock = forceRequire(mockJsPath);
  } else if (fs.existsSync(mockJsonPath)) {
    proxyDebugger(`${reqPath} -> ${path.relative(utils.PROJ, mockJsonPath)}`);
    mock = forceRequire(mockJsonPath);
  } else {
    proxyDebugger(`${reqPath} -> 没找到对应文件夹`);
    mock = {
      code: '404',
      message: '没找到对应mock的文件夹, 请在mock下建立'
    };
  }
  if (typeof mock === 'function') {
    const mockFileName = mock(req.query, req.body, req);
    if (typeof mockFileName === 'string') {
      const mockFilePath = path.resolve(mockPath, mockFileName);
      mock = forceRequire(mockFilePath);
    } else {
      mock = mockFileName;
    }
  }
  res.setHeader('Content-Type', 'application/json');
  res.send(mock);
}

远程mock

一般我们都能想到这样的写法:

{
    "/api/xxx": "http://xxx.com"
}

但是实际的工作,可能要对接不同的开发,还有不同的环境,所以就有了下面的写法:

{
     "/api/xxx": {
          "dev1": "http://xx1.com", 
          "dev2": "http://xx2.com"
     }
}

当然我们上述两种方式都要兼容。第二种无非通过命令行传入是dev1还是dev2

你以为这样就好了么?在实际中,还会存在:有些接口后端正在开发中,有些接口已经好了的。那么正在开发中的,我们要使用mock,已经开发好的了,我们就直连他们的机器。所以在options中,你能看到有pathignore-path这两个option。

cui-scripts-shared

这个是我的假想,因为cui-react-scriptscui-vue-scripts,总会有一些相同的代码的,所以后期会考虑将公共的代码放到cui-scripts-shared里面去。

eslint-plugin-cui

这个我直接抄了去年阿里大神写的自定义eslint插件。

里面放了两个规则:

  • function-length : 用来检测函数体的行数是否超过50行(除去注释)
  • comment-percentage: 用来检测文件的注释是否大于10%

未来可能还有会一些其他的。如检查业务代码里面是否用到了antd这个库。如果用了,前期报warning,后期报错误。(为什么?我会在UI的部分中提到)。

UI

这个不得不说的,就是我司的DPL。前年从阿里来了一个交互大神,然后在前年,我和另外一个同事一起搭建了DPL平台,视觉往上面放相关的资料。到现在,可以说已经半成熟了。

说半成熟,是因为web端有些组件还没有出全,还有像移动端这一块是完全没有DPL的。但是去年经历了ITS这个项目,他们多少会有一些积累。

得益于这个,我们完全可以抛开antd,可以自己造一个轮子。

但是这个UI轮子,可以依托于antd,只是说屏蔽开发人员使用antd。原因有几个:

  • 我们会有一些其他的ui组件,如果不屏蔽antd,那么在项目中会存在多套UI
  • 组件样式的问题,有时候并不是仅仅改一个皮肤颜色就行了,而且重写的方式很是别扭

我和同事探讨了一下,他还是认同我的方案的。于是乎,他现在在造:dpl-react

当然与之对应的还有:dpl-vue

甚至我觉得移动端UI,也可以这样来玩,写一个dpl-mobile。然后询问业务人员需要哪些基础库。

需要的基础库,看时间来决定是自己写,还是从开源项目里面扒。

当然有时候难免会踩一些坑,但是我个人觉得这样的方向是没错的。

本文链接:www.my-fe.pub/post/about-scaffold-and-ui-lib.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。