SwiftUI 很有趣，但 NotSwiftUI 更好

        自从 SwiftUI 在 2019 年 WWDC 会议期间宣布以来，社区对 SwiftUI 以其声明性性质引入桌面的核心思想一直存在分歧。

        我自己和其他人还没有接受 SwiftUI 作为编程的真正未来，但我们大多数人已经同意，SwiftUI 所代表的总体思想实际上是编程的发展方式（甚至可能成为新标准）。

问题

        随着时间由我们通过DEVE升打开信惊人的应用程序从而彻底改变了生活。我们彻底改变了食品和产品交付，使其变得如此简单，任何人都可以使用它（甚至您的祖母也可以这样做！），我们使跟踪我们的家务和 ToDo 变得更容易，在遥远国家的外国道路导航从未如此简单和各种翻译应用程序消除了人与人之间的界限。现在，所有这些都是由命令式编程完成的——它告诉程序事情应该如何发生。这很有趣，但有时会变得非常复杂。

        SwiftUI 将声明式编程带到了桌面上，这意味着 - 应该发生什么。这也很有趣，让程序自己处理很多逻辑，同时只给它一套要遵循的规则。虽然在外面很棒，但这可能会导致我们失去对事物的一些控制。

        由于我主要在没有 Storyboard 的情况下开发应用程序（在我看来，这让我可以更好地控制正在发生的事情并帮助我更好地控制 UI 本身），我经常发现自己用多行代码声明了各种 UIKit 元素。例如：

        

        声明 UIButton 元素的常规方法。

        这是一个带有向左箭头 SFSymbol 的按钮的常规声明。我稍后会将它添加到视图中并使用一些约束（这是更多的代码行）来定位它。现在你已经看到，这需要 15 多行代码来编写。现在想象一下有几十种不同的 UI 元素。通过这种方式，您可以轻松访问包含许多此类声明的文件。换句话说，这也会损害可读性，因为它有时会使您的代码“沉重”且令人费解。

解决方案

        我真的很喜欢使用 SwiftUI 声明各种变量的简单方法。只需几行代码，您就可以拥有一个圆圈、一个标签、一个图像、一个按钮等。因此，我着手将 SwiftUI 的美学与常规 Swift (UIKit) 相结合，并创建了一个 Swift 包，其整个前提是允许程序员在保持可读性的同时，用更少的代码行轻松地创建复杂的对象——NotSwiftUI！例如，这里UIButton与通过NotSwiftUI包声明的SFSymbol相同：

        本质上声明一个带有 SFSymbol 的 UIImageView，以视图为中心，给它一个背景颜色并添加一些阴影。

        现在，如果我想将它集中在一个视图中，我只需执行以下操作：

        在视图中居中创建元素。

        这可以轻松地为您节省时间和代码行数，从而可以轻松创建 UI 元素并在保持可读性的同时对其进行定位。

NotSwiftUI 背后的理念

        利用 UIKit 中的所有元素本质上都是 UIViews 的想法，您可以在 NotSwiftUI 的帮助下声明所有 UIKits 元素。同时，它还用于自定义元素，例如添加阴影、更改背景颜色、添加动作、圆角等。

        在具有水平轴的 UIStackView 中堆叠一个正方形和一个圆形（均为 UIViews），将其添加到视图中并对其进行一些自定义。

结论

         是一个有趣的项目，旨在将两个世界结合起来，并允许程序员在纯 Swift (UIKit) 驱动的应用程序中拥有 SwiftUI 的一些功能。主要是试图从一遍又一遍地编写许多乏味的代码行中减轻一些负担，同时保持良好的可读性。虽然它仍处于起步阶段，但随着时间的推移，更多功能将稳步可用。

        在我看来，SwiftUI 还没有为黄金时间做好准备，但它仍然是 Apple 开发生态系统中非常重要的一部分。如果您正在考虑集成各种功能（例如 CarPlay 或 Apple Watch 扩展）、为您的应用程序创建小部件，甚至构建跨平台应用程序，则必须这样做。

        关于NotSwiftUI，请 随时提供建议、反馈，甚至为这个小项目做出贡献。最重要的是，享受和快乐的编程！

七爪网7claw.com