让我们把垫片GIF带回来

假设我们正在构建一个HomeButton组件，可以在标题中弹出一些内容，以使用户可以轻松找到回家的路。 我们走在正确的轨道上，但是我们的箭头图标都“紧贴”了文本。 对我来说，这绝对是幽闭恐怖症。 😬 我们可以通过将文本包装在＆lt; span＆gt;中来解决此问题。 并给它一些余量： 我没有使用边距，而是显式创建了一个新元素来在图标和文本之间添加一些空间！ 这不是一个新想法-实际上，这是一个非常古老的想法。 而且我认为现在该卷土重来了。 在90年代后期，如果您打开一个典型网站的源代码，则可能会遇到以下奇怪的想法： CSS还不存在，Web布局是使用HTML表构建的。 表格非常细腻，一个空单元会折叠并破坏布局，因此开发人员会将此图像扔到一个表格单元中以使其保持打开状态。

使用GIF是因为GIF是唯一支持透明性的图像格式（这是PNG之前的格式）。我们的间隔好友包括一个透明像素，一个完全空白的图像。

这种多功能的工具还有另一个目的：可以将其拉伸和挤压成任意大小或形状，从而在元素之间创建不可见的缓冲区。例如，如果您希望在两个表之间留一点空隙，则间隔GIF在快速拨号盘上为＃1。

那怎么了？好吧，间隔GIF在动荡的十年中只是较大转变的一小部分。

CSS已添加到浏览器中，以提供样式的替代方法。该语言最初并不是在设计时就考虑到布局的，但是开发人员很快意识到，通过使用一些巧妙的浮动技巧，它可以完全替代表格布局！

这是在线辩论的恶心。老警卫对他们的表布局，间隔GIF和舒适的生活方式感到满意，而一所喜of的新学校则主张避免HTML布局并由CSS独占所有陈述性内容。

这场辩论与网络上的另一种变革同时发生：我们正在构建的东西变得越来越复杂，越来越像应用程序，而不像文档。 “ Jambalaya开发”非常适合快速交付产品，但是它混乱且难以维护，而且扩展性差。

通过分离我们的关注点（用于结构的HTML，用于布局和表示的CSS，用于行为的JS），我们有了一个约定，可以帮助我们降低复杂性，最终使维护变得更容易。

在HTML中进行任何演示性的工作都成了假事。诸如＆lt; font＆gt;，＆lt; center＆gt;，＆lt; strike＆gt;和＆lt; marquee＆gt被驱逐出境，并替换为CSS替代品。 ＆lt; table＆gt;保留用于实际表。

十年来，每个人都同意为每个关注点设置不同的支柱是一个好主意。然后，Facebook发布了FaxJS React.js。

React.js的定义特征之一是HTML是在JS内部创建的。加上样式化组件之类的工具，我们的三个支柱已经合并为一个。我们已经全面发展，而Jambalaya的开发又重新流行起来。

当涉及到像Facebook这样庞大而庞大的Web应用程序中管理复杂性时，React无疑是一个强大的工具。这是否意味着在我们几年前通过技术将关注点分开时，社区做出了错误的选择？

我不这么认为。我记得在2000年代初修改过Web开发，当时是Wild West。我记得使用PHP动态生成JS，它将更新HTML以更改CSS。真是一团糟。

因此，结构是一个好主意，但仍然是一个好主意，但这并不是唯一的好主意。没有一种正确的方法来构建产品。诀窍是要有某种约定，以便随着应用程序的大小和复杂性的增长，事情不会变成意大利面条。

重要的是您可以绘制边界线。这些线绘制在哪个轴上的关系越小。

在最初的什锦饭餐桌布置时期，间隔GIF是一种美味的补充成分。当我们转向制作解构的三明治时，味道并不好。但是，既然我们中的许多人正在使用组件驱动的体系结构，那么我们的代码可能会受益于少量的GIF间隔。

该组件使用像素值，因为我发现通常需要选择超出比例的值以进行光学对准。也就是说，此模式可以轻松地改编为使用设计令牌：

您可能想知道为什么我要用我的Spacer代码做出某些决定。让我们深入研究其中的一些！

最初，我的＆lt; Spacer＆gt;组件渲染了一个div而不是一个span，但是我发现这有点限制。根据HTML规范，不应将div放在某些元素内，例如p和button。

span是一种更加灵活的标记，但默认显示：内联和内联元素并不是为布局任务设计的；您不能给他们明确的宽度或高度，这就是我们想要一个垫片的全部原因！

通常，我要使用＆lt; Spacer＆gt;分隔块级元素，因此将其赋予display：block而不是display：inline-block是有意义的。在极少数情况下，我想分离内联元素，可以通过一些组合来完成：

这样做是因为宽度实际上是一个建议，而不是硬约束。考虑这种情况：

在此示例中，容器的宽度受到maxWidth的限制，并且我们没有足够的空间。我已更换了＆lt; Spacer＆gt;一个粉红色的盒子，所以我们可以看到发生了什么。

粉色框希望是16px x 16px，但是从渲染的输出中可以明显看出它被挤压了。它不是正方形！

我们已将浏览器置于一个困境：没有足够的空间来渲染所有内容！默认情况下，它会进行有根据的猜测，并决定挤压空孩子。这是一个合理的假设，但这不是我们想要的！

min-width是更严格的属性。它不会被推。这可以让我们告诉浏览器该元素很重要，并且我们不希望它受到挤压。它应该找到其他元素来选择。

为什么我们的垫片比其兄弟更重要？因为保持一致的间距对于维护专业，精致的UI至关重要。我希望能够相信页面上的每个按钮在图标和文本之间都将保持一致的间隙，即使这意味着文本已被截断或多行也是如此。

＆lt; Spacer /＆gt;上面显示的组件没有响应；它在每个视口占用相同的空间量。

我倾向于在上述情况下使用这种组件，这种情况下不需要动态间距。但是，如果我遇到了会因响应间隔而受益的情况，我将对其进行更新以使用如下所示的API：

对于上下文相关的东西，我喜欢使用prop名称。它读起来很好（至少从消费者方面来说。这是IMO最重要的观点）。

好吧，那我为什么要这么做呢？为什么不像其他所有人一样使用保证金？

从语义上来说，有时候对我来说很奇怪。在我们的主页按钮示例中，边距应该在后箭头还是文本上？在我看来，这两个元素都不应该拥有＆＃34;空间。这是一个独特的布局问题。

边距很时髦。它们以怪异和令人惊讶的方式崩溃。在上面的示例中，边距没有崩溃，但是存在内在的精神负担；我始终需要牢记这一点，并加以考虑。

有结构上的含义。在上面的示例中，我将文本包裹在＆lt; span＆gt;中，这在某些情况下可能会引起问题（例如，网格中的子项）。在父母和孩子之间放置额外的层可能会出现问题。

从根本上讲，现代组件体系结构的余量很大。它们渗出，渗入组件边界，渗入相邻元素。

越来越多的开发人员正在淘汰利润，而是依靠布局组件。 ＆lt; Spacer＆gt;是该工具包中的出色工具。

我开始尝试＆lt; Spacer＆gt;组件是几年前的，那时，我已经在此博客中添加了大约100个实例（包括托管的项目，例如我的有效投资组合书和操作员查找）。

我最担心的是DOM大小。 Google建议将网页保留在1500个DOM节点以下，这是我的一些更复杂的网页所超过的阈值。

不过，我还没有发现需要添加那么多间隔物。在实践中，我将其视为＆lt; ShiftBy＆gt;组件-它是我可以在特定情况下部署的“特殊代理”。大多数页面只需要一小部分。

我大部分的间距问题都是通过填充，其他布局组件以及网格间隙/间隙来解决的。而且，是的，尽管我越来越少地使用保证金，但有时还是会使用保证金。

还有其他避免DOM污染的原因，例如可访问性和SEO。据我所知，在这些方面，一些额外的空跨度并不会有害。

当我对此博客文章进行一些研究时，我偶然发现了spacerGIF.org，这是一个提供间隔gif的API！它也不是十年前的遗物。在过去一年中增长了30倍！

我怀疑许多读者，尤其是长期从事游戏的读者会对这一想法产生内在的负面反应。从网络的混乱初期开始，它就带来了很多负担。但是今天的生态系统已经不一样了，这只老狗令人惊讶地非常适合组件系统。不要这么快就将其注销！