swift TabBar使用总结

在Xcode 11 GM中，使用TabBar的语法格式为：

struct Tabs: View {

    @State private var selected = 0

    var body: some View {
        TabView(selection: $selected) {
            MyFirstView()
                .tabItem {
                    Image(systemName: (selected == 0 ? "star.fill" : "star"))
                    Text("One")
                }.tag(0)
            MySecondView()
                .tabItem {
                    Image(systemName: (selected == 1 ? "star.fill" : "star"))
                    Text("Two")
                }.tag(1)
            MyThirdView()
                .tabItem {
                    Image(systemName: (selected == 2 ? "star.fill" : "star"))
                    Text("Three")
                }.tag(2)
        }
        .edgesIgnoringSafeArea(.all) // Important if you want NavigationViews to go under the status bar...
    }
}

其中原来的TabbedView变为TabView，tabItemLabel变为tabItem，并且可以使用传入binding值的方式匹配tag，对当前选中的不同tab产生响应。
如果要改变TabBarItem被选中时系统显示的颜色，可以修改属性

.accentColor()

在其中传入要设定的颜色值，tabbar item被选中时就会呈现出指定颜色而不是系统默认的蓝色。但是要注意对于非系统icon，不会有对本地图片自动填充颜色的效果。

此外这次issue的教训是：

• 在进行merge请求时的代码也要注意优雅，特别是工程代码

• 逻辑层和数据层的代码要分开；如果已经有了大致框架，不同的逻辑也要写在不同的文件中

• 最好不要在传值的时候传入一个过长的表达式，这样代码的可读性会降低，可以通过计算属性取得状态值

• 在用switch语句时，尽量不要使用default语句，而是尽可能将所有可能的情况都枚举出来。这样在编译时编译器可以帮助检查是否对所有的枚举值进行了判断，防止添加新的case时部分代码忘记添加case情况直接执行default语句，最后运行出现bug

• 任何方法在制定时都要考虑到程序的健壮性，如果以后有添加/删除怎么办？不能只满足当前的情况，要对未来的修改有预见，让修改的程度降到最低。

最后：我的第一个还算优雅的（？）方法，纪念一下

判断是否选中tab的方法

在学习中起到帮助的：
stackoverflow-tabview的格式
apple developer-bug