两个组件似乎都会重新排列标题中的 .contents div。
具有全宽布局的结构：
带 header-search 的结构：
所以我不能一起使用它们。但不确定在哪里最好修复这个问题？
3 个赞
上周，我遇到了这两个组件的完全相同的问题……这有点棘手，因为我原本打算让全宽组件只是一个临时实验，但我们没有任何计划将其默认集成，所以它停留的时间比我预期的要长。
全宽组件并非理想选择，因为它需要更改页眉模板（这是我能克服一些布局问题的方法）。
乍一看……我认为页眉搜索组件中的模板覆盖不是必需的，因此我可以将其移至小部件装饰器，这样就可以避免这个问题。
4 个赞
我尝试的临时修复方法是不更改全宽组件上的 header-contents widget。这样，sidebar-toggle 和 title 就不会被分组到 __toggle-and-logo 下。然后只需将两者都放置在 toggle grid-area 中。到目前为止，我没有看到布局问题。但我可能遗漏了什么？
我认为它非常受欢迎。我有三个当前的定制项目，都选择了全宽。这也是我发帖的原因，我希望不要调整官方组件来实现似乎是常见的选择。
2 个赞
如果我没记错的话，额外的包装器可以更轻松地将标题与主题内容对齐，因为我可以将组合的 .header-contents__toggle-and-logo 宽度设置为 var(--d-sidebar-width)，它与侧边栏的宽度相同，与内容无关。
没有额外的包装器，布局是可以实现的……但有了两个网格列，我就无法依赖单一的宽度了。
我需要假设侧边栏切换按钮始终是某种固定宽度，然后根据该宽度计算最大徽标宽度。这可行，但我记得它更脆弱……我有一段时间没看这个了，但也许值得再试一次 
回到这个……我可以看到为什么它使用了覆盖。没有它，您必须装饰标题或 header-icons 小部件，因此您最终会在 .title 或 .panel 中添加内容，这使得搜索栏的居中对齐更加困难……并且需要一些 CSS 来使布局更脆弱，并使与其他标题组件的兼容性更难。理想情况下，搜索栏内容应位于这些 div 之外，但没有可以挂钩的地方。
我们现在可以将插件出口添加到小部件中，这可能会有所帮助……
这将允许在 .panel div 之前添加内容，而不是在其中使用 decorateWidget。在这种情况下，可以从 header-search 组件中删除模板覆盖，并添加一个新的连接器到：
javascripts/discourse/connectors/before-header-panel
其中可以包含
<MountWidget @widget="search-banner" />
将插件出口添加到小部件以便我们可以将小部件添加到插件出口似乎有点迂回……@david/@cvx 您知道这是否会对性能产生负面影响或引起任何其他问题吗？
1 个赞
顺便说一句，这是我尝试修复全宽组件的方法：https://github.com/discourse/discourse-full-width-component/compare/main...nolosb:discourse-full-width-component:header-contents
即：
- 使用默认模板布局，在切换器和标题 logo 周围不添加额外的包装 div
- 将项目匹配到网格区域
但是，我看到当主题标题显示在标题栏上时，标题 logo 会切换回小 logo。在 meta 的全宽布局上这里也会发生这种情况。我不太明白应该使用哪些模板参数才能始终显示完整的 logo。
我明白了，您将它们都放在同一个网格区域中并应用了边距到徽标……这似乎是一个合理的折衷！
这就是为什么 home-logo 在这里重新打开的原因：
如果未显示侧边栏，它将使用默认的徽标逻辑在大小徽标之间切换……如果显示侧边栏，它将始终返回大的徽标。
1 个赞
这可能会稍微慢一点，但在此情况下我不太担心，因为页面上只有一个插件插槽实例（与例如主题列表项插件插槽不同，后者将渲染 25 次以上）。
在此处添加插槽对我来说听起来很棒 
1 个赞
好的，我已经更新了这两个组件以避免模板覆盖 —
现在它们应该可以协同工作了 
感谢 @manuel 的建议！
3 个赞