精读《对前端架构的理解 - 分层与抽象》

[ascoders]

前端的基础知识精读已经写的差不多了，如果基础知识可以一直写下去的话，反而说明这些基础知识不够抽象，甚至不够稳定。每周蹦出来的新东西也不多，所以这段时间准备写写高大上的东西。

最近正在学习 七牛云许式伟的架构课，本周结合自己经验谈谈对前端架构的理解。

---

精读《对前端架构的理解 - 分层与抽象》

[wangrongding]

👍

[NameWjp]

👍对这个比较感兴趣

[Retrospection]

关于最后总结前的这段，想探讨一下

抽象的方式是无数的，哪种更好取决于业务如何变化，不用过于纠结完美的抽象，就连 Unix 一切皆文件的最基础抽象都备受争议，业务抽象的稳定性肯定会更差，也更需要随着需求变化而调整。

抽象之所以为抽象，正是因为我们期待它是尽可能稳定。而且抽象一旦被抽象，变更它的代价会变得非常巨大。 Unix 一切皆文件的抽象哪怕再备受争议，为了避免这种抽象变更带来的代价，还是不得不对显示设备进行并不十分理想的强行适配，而不是选择去变更「一切皆文件」的抽象。

那么，对于业务系统来说，尤其是业务系统的前端来说，构建抽象真的有那么强烈的需求么？

[ascoders]

那么，对于业务系统来说，尤其是业务系统的前端来说，构建抽象真的有那么强烈的需求么？

@Retrospection 抽象的层次越基础改动成本就越大，业务层的抽象相对比较上层，重构是相对可行的，所以抽象还是划来的。当然要不要抽象不仅要考虑推翻的成本，更要考虑如果不抽象带来的理解成本与维护成本。

[zphhhhh]

@Retrospection 博主说的架构应该对应重交互的前端产品，比如地图、搭建平台、图表平台等，但现实中大多数产品都是轻交互的，可以说没什么架构可言，比如运营后台、产品展示类，每个页面基本只有几个 button、几个 table、来个筛选、文章、可能的一两个 form 等。这种轻交互类前端产品如果给业务代码抽象，反而不容易维护。前端产品应该重声明式代码、轻命令式代码，而抽象恰恰属于命令式代码。比如同样的三个 table，如果抽象一点：

// 命令式代码
function getColumns(type,other){
 if (type === 'table1') {
  return [
   { title, dataIndex, render },
   {
    title, dataIndex,
    render: () => (
     <Button onClick={other.openModel}>
       open!
     </Button>
    ),
   },
   {
    title, dataIndex,
    render: () =>
      other.showTable1Button && (
        <Button>click!</Button>
      ),
   },
  ];
 }
 
 if (type === 'table2') {
   return [
    { title, dataIndex, render },
    {
      title, dataIndex,
      render: (text) =>
        other.showTable2Tip && (
          <Tip />
        ),
    },
    { title, dataIndex, render},
   ];
 }
 
 if (type === 'table3') {
   return [
    { title, dataIndex, render },
    { title, dataIndex, render },
    { title, dataIndex, render },
   ];
 }
};

const CommonTable = (
  <Table
    columns={getColumns(
      props.type,
      props.other,
    )}
  />
);

return (
  <div>
    <CommonTable
      type="table1"
      other={{
        openModel,
        showTable1Button,
      }}
    />
    <CommonTable
      type="table2"
      other={{
        showTable2Tip,
      }}
    />
    <CommonTable
      type="table3"
    />
  </div>
);

如果不抽象，也就是前端一把梭，尽可能的声明式：

// 声明式代码
return (
<>
 <Table
  columns={[
   { title, dataIndex, render },
   {
    title, dataIndex,
    render: () => (
     <Button onClick={openModel}>
       open!
     </Button>
    ),
   },
   {
    title, dataIndex,
    render: () =>
     showTable1Button && (
       <Button>click!</Button>
     ),
   },
  ]}
 />

 <Table
   columns={[
    { title, dataIndex, render },
    {
      title, dataIndex,
      render: (text) => (
        showTable2Tip && <Tip />
      ),
    },
    { title, dataIndex, render},
   ]}
 />

 <Table
   columns={[
    { title, dataIndex, render },
    { title, dataIndex, render },
    { title, dataIndex, render },
   ]}
 />
</>
);

上面两种形式结果上完全一致，但声明式代码明显更容易维护。当然上面关于抽象的例子只是把 column 公共了一下并不是很合理（但来源于我见过的真实代码）。另外声明式代码一般会比命令式代码更冗长，我的原则是，代码宁愿多写，也不要少写，抽象不值得，后人来背锅。

[superAo005]

@zphhhhh 关于抽象的例子column 公共了一下 声明式代码。 目前我团队老大乐此不疲 经常这样命令式写代码 代码量反而更冗长 确实难以维护 要怎么说服他换声明式方式写代码呢