Shell 子组件嵌套方式讨论

[youluna]

1. 单层模式

<Shell>
    <Shell.Branding /> Box(row)
    <Shell.Navigation/>
    <Shell.Action /> Box(row)
    <Shell.LocaleNavigation /> Box(column)

    <Shell.AppBar /> Box(column)
    <Shell.Content /> Grid
    <Shell.Footer /> Box(column)
    
    <Shell.Ancillary /> Box(column)
    <Shell.ToolDock /> Box(column)
        <Shell.ToolDockItem />
</Shell>

2. 嵌套模式

<Shell>
    <Header>
        <Shell.Branding /> Box(row)
        <Shell.Navigation/>
        <Shell.Action /> Box(row)
    </Header>
    <Content>
        <Aside>
            <Shell.Navigation/>
            <Shell.LocaleNavigation /> Box(column)
        </Aside>
        <Content>
             <Shell.AppBar /> Box(column)
            <Shell.Content /> Grid
            <Shell.Footer /> Box(column)
        </Content>
        <Footer />
    </Content>
</Shell>

[jasonintju]

组件结构布局即 DOM 结构布局，符合认知习惯；
从顶至下嵌套清晰也方便用户自定义修改某些wrapper样式，比如Header增加style、className等。
赞成嵌套模式

方式1平铺组件，不利于感知真实的DOM结构，修改Header组件样式还需要用户自己去寻找真实的header dom在哪里，有点反常和不方便。

[youluna]

单层模式：

Shell是一个中台体系下的设计强约束性组件，与传统Layout的区别在于，每一个Shell组件/子组件都有它的含义、固定位置、固定UI设置，在不同device下有约定的样式展示。现有的Shell一定无法覆盖所有场景，需要不断迭代。

优点：

1. 用户不用关心页面布局，只专注于内容区域
2. 自带自适应能力
3. 由于子组件是限定的类型，可以在代码层面上强约束到使用者

缺点：

1. 无法从代码结构上，感知页面dom结构

嵌套模式

嵌套模式用的是传统Layout，用户关心布局，自适应能力有限，也需要用户自己做。

另外关于自定义Header区域样式的问题，我的看法是这样的：Shell的这层设计约束就是为了减少不确定性的。之所以开放了Branding/ Navigation / Action 而没有开放Header，是因为目前在设计层面上不认为它是必要的，一切对于Header的改造都应该可以通过主题配置、API使用来解决。

支持按照现在的逻辑，采用单层模式

[micate]

从自适应布局方面考虑，确实不应该采用嵌套模式，无法完整表述组件在各种布局下的嵌套关系。

但希望在 Shell 层面，能开放一些定义 header / aside / main 属性的口子，在合适的时机应用上去，比如 headerProps / asideProps / mainProps。

[youluna]

话说这些props是准备解决哪些问题的呢？

如果是样式问题，可以通过提需求，让Shell增加配置项来解决。Shell会纳入到基础组件体系里，并且增加种类配置项（比如button有normal secondary primary等多种类），支持定义不同的模版（例如深色header浅色aside、浅色header深色asider等多种组合）

这样能解决你的问题么 @micate