DRY React:是否扩展。我的团队似乎不同意

时间:2018-07-05 12:49:18

标签: javascript reactjs

我正在一个React项目中工作,我们有自定义样式的表单元素。一个复选框和一个单选按钮都使用:

  1. 一个隐藏的<input />字段。
  2. 连接到<label>的{​​{1}}。
  3. 基于input伪类,它更改了呈现的SVG元素。
  4. :checkedcheckbox之间的唯一区别是CSS使单选按钮看起来是圆形的,复选框项目是方形的。
  5. 浏览器只能选择1个单选项目。

现在,此组件的基本呈现的HTML是:

radio

所以我设置了radio.js React文件。而我的checkbox.js React文件只是扩展了收音机:

<input type={type} id={someid} />,
<label htmlFor={someid}>
  <div className="icon">
    {type === 'checkbox' && <CheckMark />}
    {type === 'radio' && <CircleMark />}
  </div>
  {label}
</label>

与附加的CSS文件相同。它们使用SASS工作,所以我的checkbox.sass基本上可以做到:

export default class Checkbox extends PureComponent {
  render() {
    return <Radio {...this.props} type="checkbox" />;
  }
}

无代码重复。一切都很好。

现在我的同事已经复制了整个radio.js和radio.scss文件,并复制了checkbox.js和checkbox.scss的代码。

我的团队100%同意他的看法,因为:“他们与众不同!”

结果是72行重复的JS和80行重复的CSS。

谁对谁错?

1 个答案:

答案 0 :(得分:2)

在决定共享代码(创建抽象)时我问自己的问题是

  1. 此抽象有何假设?
  2. 这些假设成立和使用案例的可能性有多大 不分歧?如果看起来很有可能 现在相同,一个月后会有所不同,现在共享代码 可能不是一个好主意。我通常会很悲观 关于这一点,因为软件趋向于以 难以预测。
  3. 我从抽象中受益多少?会大大提高生产率吗?
  4. 如果我最终发现一个不合适的用例,那么解开该抽象有多困难?

不幸的是,那里并没有一个真正的魔术公式,但是我再次尝试变得非常悲观,避免在有危险信号的情况下创建抽象。稍后创建抽象并替换重复代码比删除不良抽象要容易得多。

对于您而言,我对问题的回答将是

  1. 要做出的假设是,单选按钮和复选框组件在输入类型和图标之外是相同的。
  2. 由于复选框和单选框是不同的,因此可能还会有其他差异。您可能需要一种样式或行为,而另一种则不需要,这在没有抽象的情况下更容易实现。
  3. 好处很小。如您所说,删除了少量重复项。如果两个确实需要以相同的方式进行更改,那么现在必须在两个位置而不是一个位置进行更新。
  4. 由于共享代码量非常小且非常简单,因此删除抽象并不难。

因此,按照我的看法,由于不良的抽象而导致处于不良状况的风险很小,但是您也不会从中受益匪浅。我个人倾向于不在这两者之间共享代码,但是我也不认为这是对/错的情况。对我来说,好处并不能证明它的存在。

This talk from a few years ago来自React团队的塞巴斯蒂安·马克伯格(SebastianMarkbåge),确实改变了我对抽象的看法,总的来说,让我更加犹豫了。