Question

阅读Chris Pearce的Handling spacing in a UI component library我发现了这个：

...组件需要高度自包含，以便它们对任何特定UI上下文或其他组件没有依赖性。每个组件都应该能够在UI中的任何地方被删除，它只会起作用。

假设我有一个Button组件，对于“工作”按钮，让我有理由让这个组件有一个外边距，按钮周围的最小空间让它“工作”（“工作“，看起来很好，而不是打击另一个元素。”

然后文章反方向说：

默认情况下应用了外部间距的组件可能会出现问题。

这篇以及整篇文章的论点相反，Button不应该有那个外层空间，我们可以使用其他技术来设置它：一个Spacer组件，一个{{ 1}}组件等

回到基础：

Wrapper

在这种情况下，我认为，应该是负责确保自身与其他元素之间存在空间的p标签（或<div id="container"> <p>Hello</p> <p>World</p> </div> <Container> <Paragraph>Hello</Paragraph> <Paragraph>World</Paragraph> </Container>组件）。

这篇文章和我发现的其他文章似乎反过来说：Paragraph应该只关心自己，并且根据使用P的位置，我们应该区别对待。

实际问题：是否有关于如何处理外部元件间距的文档化最佳实践或共识？

Answer 1

目前没有最佳做法。据我了解。我并不是要推广，但我一直在讨论实际解决这个问题的组件优先设计/开发（https://medium.com/@jerrylowm/front-end-development-is-like-figure-skating-it-rewards-to-be-more-technical-than-artistic-784323079131）。

简而言之，第一个设计/开发与Chris Pearce的方法非常相似（我必须完成文章），但唯一的区别是<button>示例将包括外边距。但！可能不是，为什么？

这个概念是组件设计，所以它实际上取决于你是否将按钮视为自己的组件。例如，如果按钮是营销横幅的CTA，则横幅本身可能是组件。就好像它的日历按钮放在应用程序的整个应用程序按钮本身可能是组件。在您显示的示例中：

<div id="container">
  <p>Hello</p>
  <p>World</p>
</div>

我会为父级提供一个类名，并将其视为一个组件，并相应地对其中的段落进行空格处理，因为大多数时间段落需要不同的间距。我的方法：

<div id="container" class="body-text>
  <p class="body-text__p">Hello</p>
  <p class="body-text__p>World</p>
</div>

带BEM的CSS：

.body-text {
  margin: 20px auto;
}

.body-text__p + .body-text__p {
  margin-top: 20px;
}

有一次，因为没有最佳实践，每个人都有自己的方法来解决这个问题。我想如果你开始在<p>左右开始创建间距，那么你接近它的原子级别更多，我认为它适用于某些应用但不是全部。

Answer 2

您在我的文章中引用的参考文献并不像您暗示的那样相互矛盾：

然后文章反方向说：

但是，我可以看到你如何解释它。

基本上我的意思是：

每个组件都应该可以在UI中的任何位置删除，它只会起作用。

外部组件间距的烘焙是否会导致可伸缩性问题，因为您对组件的可重用性（可移植性）不太重要，因为他们对 中使用或使用的上下文过于自以为是今天 ......

今天，您的<Button>组件在整个UI中的相同两个上下文中实现，其中外部间距烘焙是有意义的。然而，明天，一个新的环境涌现出那个间距没有意义的地方。在这种情况下，您可以关闭间距，例如：

<Button spacing={false} />

但如果它再次发生又怎么样呢？这就是事情开始变得丑陋的地方，因为现在spacing={false}是默认值，但显然消费者每次都应用它是没有意义的，所以你现在必须进行搜索并替换{{{{}的所有实例。 1}}删除<Button>如果您使用的是小应用程序，可能不会太糟糕，但想象一下您正在设计系统上工作，在那里您可以为一些处理单个应用程序的团队提供高度可重用的UI组件。即使spacing={false} 8的10个不同实现（上下文）中需要外部间距，我仍然不会将其烘焙。

这才是真正的关键，只有<Button>只关注自己，以便它更可重复使用（便携式），我认为更容易消费和记录。如果出现模式需要以某种方式组合<Button>组件，我很可能会考虑创建另一个组件来处理这些问题。

乐高比喻是一种很好的思考方式。每个组件都是一块乐高积木，可以通过多种不同的方式组装，从而形成一个整体系统。间距分量covered here只是另一个Lego部分，负责处理所述系统的一个特定部分。我认为它可以与某些计算机科学设计原则有关，例如：

在你的段落示例中，我处理每个段落之间的间距的方法是让另一个组件处理它，例如：

<Button>

CSS：

<LongFormCopy>
    <P>Bla bla</P>
    <P>Bla bla</P>
</LongFormCopy>

很少有人会在你的视图（或你的容器组件）中放置一个段落，例如：

.c-long-form-copy p:not(:last-child) {
    margin-bottom: var(--spacing-base);
}

我的方法是将它们封装到一个组件中，因为它将代表某种很可能再次出现的UI模式。同样在应用程序UI的长格式副本很少见，因此我喜欢拥有<SomeComponent> <SomeOtherComponent> <P>Bla bla</P> <P>Bla bla</P> <SomeOtherComponent>组件，因为在您的应用程序具有长格式副本的罕见情况下，您可以在一个地方处理所有这些排版问题。这是使用间距组件在我的文章here中无法理解的例外情况之一。

可能会发送您<LongFormCopy>实施的截图，因为我很好奇。

直接问题：

是否有关于如何处理外部元件间距的文件化最佳实践或共识？

我不确定他们是否会成为如何做到这一点的真理来源。如果您发现烘焙间距适合您，同时具有高度可扩展性和可维护性，那么请继续这样做。

外部组件间距

2 个答案: