原文：www.merrickchristensen.com/articles/he…

"策略同机制分离，接口同引擎分离。"— Eric S. Raymond

Headless ui组件是一种新的ui组件开发模式，组件本身不提供ui上的实现，从而让使用者能够自由定制ui样式。“且慢，无ui的ui组件，你知道自己在说什么吗？”

没错，虽然反直觉，但这正是我们所倡导的。

Coin Flip Component

假设你要实现一个抛硬币的功能，需求是这样的：实现一个类似硬币翻转的效果，翻转结束后，硬币正面朝上和反面朝上的概率是对半开。你和产品说，这需求有点复杂，给我半年的时间调研一下，然后你开始写demo

const CoinFlip = () =>
  Math.random() < 0.5 ? <div>Heads</div> : <div>Tails</div>;

太简单了，然后你拉了个会，拿着ppt就上去了。产品说不错，功能是有了，你把样式优化一下。对你来说问题不大。

const CoinFlip = () =>
	Math.random() < 0.5 ? (
		<div>
			<img src="/heads.svg" alt="Heads" />
		</div>
	) : (
		<div>
			<img src="/tails.svg" alt="Tails" />
		</div> 
	);

没多久，他们希望能在营销页上线你这个功能。他们打算投放到博客推文里，希望你的组件能够对SEO友好。于是你撸起袖子继续开干。

const CoinFlip = (
  // 设定默认值为false，以免对之前的应用造成破坏。
  // current usage.
  { showLabels = false }
) =>
  Math.random() < 0.5 ? (
    <div>
      <img src="/heads.svg" alt="Heads" />

      {/* 增加label标签，用于营销页 */}
      {showLabels && <span>Heads</span>}
    </div>
  ) : (
    <div>
      <img src="/tails.svg" alt="Tails" />

      {/* 增加label标签，用于营销页 */}
      {showLabels && <span>Tails</span>}
    </div>
  );

然后又来了一个需求，加一个重来的按钮，并且这个按钮只在应用程序当中添加。组件开始变得丑陋了起来

const flip = () => ({
  flipResults: Math.random(),
});

class CoinFlip extends React.Component {
  static defaultProps = {
    showLabels: false,
    // We don't repurpose `showLabels`, we aren't animals, after all.
    showButton: false,
  };

  state = flip();

  handleClick = () => {
    this.setState(flip);
  };

  render() {
    return (
      // Use fragments so people take me seriously.
      <>
        {this.state.showButton && (
          <button onClick={this.handleClick}>Reflip</button>
        )}
        {this.state.flipResults < 0.5 ? (
          <div>
            <img src="/heads.svg" alt="Heads" />
            {showLabels && <span>Heads</span>}
          </div>
        ) : (
          <div>
            <img src="/tails.svg" alt="Tails" />
            {showLabels && <span>Tails</span>}
          </div>
        )}
      </>
    );
  }
}

然后有一天你同事找到你：“好兄弟，你的掷硬币功能碉堡了。我们有个新需求叫投骰子，可以复用你的代码么？“你拆分了一下新需求:

需要重来按钮
需要同时用于应用程序和营销页
和你的组件有着完全不一样的ui
有着不一样的随机概率
现在你面临两种选择，要不就是拒绝你的同事，要不就是改造你的组件，把投骰子功能赛到掷硬币组件当中，看着这个组件变得臃肿难以维护。

使用Headless组件

Headless ui组件将自身的ui和行为分离出来。当一个组件的行为足够复杂，并且逻辑与视觉表现可以解耦时，这种模式非常有效。CoinFlip组件实现Headless的方式可以是让具体的ui实现作为一个子组件或者是renderProp传入，就像下面这样:

const flip = () => ({
  flipResults: Math.random(),
});

class CoinFlip extends React.Component {
  state = flip();

  handleClick = () => {
    this.setState(flip);
  };

  render() {
    return this.props.children({
      rerun: this.handleClick,
      isHeads: this.state.flipResults < 0.5,
    });
  }
}

上面这个组件是一个headless ui组件，因为这个组件不渲染任何内容。它完成了逻辑状态的提升，期望消费者去做实际的渲染工作。所以回到我们的应用，代码可能长这样：

<CoinFlip>
  {({ rerun, isHeads }) => (
    <>
      <button onClick={rerun}>Reflip</button>
      {isHeads ? (
        <div>
          <img src="/heads.svg" alt="Heads" />
        </div>
      ) : (
        <div>
          <img src="/tails.svg" alt="Tails" />
        </div>
      )}
    </>
  )}
</CoinFlip>

然后是我们的营销页，它可能长这样：

<CoinFlip>
  {({ isHeads }) => (
    <>
      {isHeads ? (
        <div>
          <img src="/heads.svg" alt="Heads" />
          <span>Heads</span>
        </div>
      ) : (
        <div>
          <img src="/tails.svg" alt="Tails" />
          <span>Tails</span>
        </div>
      )}
    </>
  )}
</CoinFlip>

完美，我们对逻辑和状态进行了很好的抽象，剥离了ui，这样我们就可以随意的定制我们的ui了。我知道你可能在想什么...

你是不是傻，不就是一个renderProp么，有必要绕来绕去么？

这个例子当中，恰好我们是利用renderProp去实现它。在react当中，我们当然也可以用HOC来实现。稍微扩散一下思维，我们甚至可以将其实现为MVC当中的View和Controller，或者MVVM中的ViewModel和View。（注：将组件内部的逻辑状态封装，具体的渲染和事件绑定交由渲染框架，单独的开发适配层，组件甚至可以做到跨平台）这里的核心思想是分离组件的机制和表现。

回到投骰子组件

这种分离的好处是，我们很容易扩展我们的headless组件，以支持同事的投骰子功能：

const run = () => ({
  random: Math.random(),
});

class Probability extends React.Component {
  state = run();

  handleClick = () => {
    this.setState(run);
  };

  render() {
    return this.props.children({
      rerun: this.handleClick,

      // 设置不同的threshold，得到不同的概率
      result: this.state.random < this.props.threshold,
    });
  }
}

因为是headless组件，我们只需要更新CoinFlip组件的代码，而不需要去修改下级消费者的代码。

const CoinFlip = ({ children }) => (
  <Probability threshold={0.5}>
    {({ rerun, result }) =>
      children({
        isHeads: result,
        rerun,
      })
    }
  </Probability>
);

同样的，同事也可以通过复用Probability组件来实现他们的逻辑

const RollDice = ({ children }) => (
  // 六面骰子
  <Probability threshold={1 / 6}>
    {({ rerun, result }) => (
      <div>
        {/* 这里可以实现一些自定义事件 */}
        <span onMouseOver={rerun}>Roll the dice!</span>
        {/* 完全不同的ui实现 */}
        {result ? (
          <div>Big winner!</div>
        ) : (
          <div>You win some, you lose most.</div>
        )}
      </div>
    )}
  </Probability>
);

优雅，非常优雅。

分离原则-Unix设计哲学

这是一个广受业界认可的共识，并且经久不衰。Unix设计哲学基础第四条：

"策略同机制分离，接口同引擎分离。"— Eric S. Raymond

我想引用这一部分，并且用界面替代策略这个词。

因为界面和机制是按照不同的时间尺度变化的，界面的变化要远远快于机制。GUI工具包的观感时尚来去匆匆，而光栅操作和组合确实永恒的。
所以，把界面同机制揉成一团有两个负面影响：一来会使界面变得死板，难以适应用户需求的改变，二来也意味着任何界面的改变都极有可能动摇机制。
相反，将两者剥离，就有可能在探索新界面的时候不足以打破机制。另外，我们也可以更容易为机制写出较好的测试（因为界面太短命，不值得花太多精力在这上面）。

我喜欢这里的深刻见解，这也给我们带来思考，哪些情况下headless ui设计模式是非常有价值的。

这个组件的寿命有多久？抛开界面表现，背后的机制是否值得我们刻意保留？这个机制我们是否会用在另外一个外观和风格完全不同的项目当中。
我们的界面外观多久更新一次，同样的功能，我们会有多少不同的外观界面？

将机制和政策分离，是有成本的。我们需要平衡好分离带来的收益和成本。我认为这是过去许多MV*模式容易犯错的地方，就是死守这个原则，一切都以这种方式去分离。回到现实，很多机制和政策都是深度耦合的，分离的好处可能不足以覆盖所带来的成本。

本文由博客一文多发平台 OpenWrite 发布！

Headless UI组件

Coin Flip Component

使用Headless组件

回到投骰子组件

分离原则-Unix设计哲学