鸿蒙应用开发，比 React 体验更好

HarmonyOS龙哥

已于 2024-05-13 21:41:13 修改

阅读量1.1k

点赞数 26

文章标签： harmonyos react.js 华为

于 2024-03-11 06:30:00 首次发布

本文链接：https://blog.csdn.net/2401_83048197/article/details/136577817

版权

痛点

一直以来，使用 HTML + CSS 来表达 UI 结构，都有一个若隐若现的痛点。痛点来源主要体现在 DOM 结构的语义表现力不足。

例如这样一段代码，我们能够很清晰的知道 DOM 结构是怎么样的，但是其具体的布局结构方式和特性就不知道了。

<div>
  <div>1</div>
  <div>2</div>
  <div>3</div>
  <div>4</div>
</div>

尽管 HTML 也新增了许多语义化标签来弥补这种语义表现力缺失的问题，但是由于大家的应用场景是在是很难和这些语义化标签非常契合的对应上，从而导致了语义化标签的使用并不是很广泛，到目前为止，语义化标签都处于一个很尴尬的境地

<div>
  <header></header>
  <nav></nav>
  <section></section>
  <footer></footer>
</div>

导致语义化标签被广大开发者冷淡的很大一部分原因，是因为 HTML 设计的这几个语义化标签确实是不太匹配日常开发的大多数具体场景。

好在我们在使用 React/Vue/Angular 开发项目时，可以通过自定义组件来增强某一个部分的语义表达

例如在 React 中，我们编写一个分页列表，你一眼就能看出来我的页面结构长什么样

<RefreshScrollView>
  <Filter />
  <Pagination />
</RefreshScrollView>

这已经是 UI 表述的最佳实践。但是我们也不是只看最外面这一层，当你深入到更底层的逻辑时，最后看到的还是 div，语义表现力不足的事实总是存在的

因此为了解决这个问题，在 antd 等优秀的开源框架中，为了增强组件的语义表现力，会提供 Row Cloumn Flex Grid 等容器组件供开发者使用。

这其实是 UI 表达的最佳实践。但是 antd 等框架对于这种思路的践行并不是非常彻底。他没有非常明确的建议说，我们不要使用 div 了，所以许多开发者就算使用了这种方式，也不是把它当成最佳实践来使用，很多时候只是为了少些两行 css 代码才使用他们。

很多时候也源自于 UI 组件库本身也没有想要去做一个大而全的布局思维重构，从而导致 antd 虽然提出了这个方向和构思，但是普通开发者也不一定能领会到。

HTML + CSS 语义表现力缺失还体现在结构和样式分离。有很大一部分开发者并不喜欢写完结构之后，还要重新去另外的文件给他补充样式。并且这样方式在维护的时候也并不友好，隐性的规则让样式的最终结果变得扑朔迷离。

最明显的一点就是默认的样式继承规则和样式优先级，这东西让许多人在调样式的时候非常难受

所以很多后端来写前端，可能他什么都能搞定，就是搞不定 css 样式，这可太难了，哈哈哈哈。

许多开发者都意识到了这种痛点。因此 css in js 的方案层出不穷。原子 css 又再次重新火了起来。不过在根源上由于 HTML 文档流的设计不够简洁，视觉格式化模型中涉及到的概念太多，因此最终在使用上依然会有不小的理解成本与麻烦。

例如大家在使用原子化 css 的时候，很容易会出现一个元素上套用了太多 class 的情况，反而导致可读性极大的降低

<!--随意搞的一个简易案例来说明这个问题-->
<button
  class="blue-400 hover:blue-500 dark:blue-500 dark:hover:blue-600 text-sm text-white font-mono font-light py-2 px-4 border-2 rounded border-blue-200"
>
  Button
</button>

因此我们需要思考新的方案来解决这种场景，例如使用一个变量名来复用这些样式

const btn = 'blue-400 hover:blue-500 dark:blue-500 dark:hover:blue-600 text-sm text-white font-mono font-light py-2 px-4 border-2 rounded border-blue-200'

<button class={'btn'}>
  Button
</button>

这些理念都非常好。但是原子化 CSS 毕竟不是直接编写样式，他的适用场景会受到很大的限制。

并且当我们在思考如何复用原子化 CSS 的时候，其实就表示，开发者确实在期待一套完整的，全新的 UI 布局表述方式。

这就是鸿蒙应用开发中， ArkUI 的布局思路。

在设计上，arkUI 充分吸收了 HTML 等客户端方案发展这么多年的经验教训，在设计上完全摒弃了文档流的概念，转而强调容器的概念。为了应对不同的场景，arkUI 目前已经支持了 26 种容器组件。因为其明确的语义化，学习成本也非常低，例如如下容器组件，我们一看就能知道这是用来干嘛的

Row
Column
Flex
Grid
List
Scroll
Swiper
Tabs
Refresh
...

并且布局方式到底是什么情况，由容器组件说了算，而不是子元素的类型说了算。

// 表示从左到右布局
Row() {
  Text('hello world')
  Text('hello world')
  Text('hello world')
}

// 表示从上到下布局
Column() {
  Text('hello world')
  Text('hello world')
  Text('hello world')
}

除了在语义化上非常重视之外，arkUI 并不支持结构与样式分离，而是把设置样式的行为当成一个 set 方法，支持一种链式调用的方式来做到样式与结构合并的最终结果

Text('width: 10px')
  .fontSize('12fp')
  .color('#333')
  .border({
    width: '10px',
    color: Color.Red,
    style: BorderStyle.Dotted,
    radius: 15
  })

这其实是原子化 css 的进化版。如果你觉得原子化 CSS 真香，那么这种方式的好处你也一定能够快速理解到。

而且他比原子化 CSS 学习和记忆成本更低，更灵活，可以说是原子化 CSS 的理想化实现。

ArkUI 在设计上，还引入了一个风险较大的设定：样式后置。

这个最开始是在 Swift UI 中出现，可能许多前端开发都没见过

Column() {
  Text('hello text')
    .fontSize('12fp')
    .fontColor(Color.Black)
    .fontStyle(FontStyle.Italic)
}
.width(20)
.height(20)
.border({
  width: 10,
  color: Color.Blue
})

之所以说他风大，是因为这种书写方式大家都没见过，可能会容易给人的第一感觉就是：什么玩意儿 …

哪怕是在 Flutter 的设计中，也是可前置可后置，然后不管是文档案例，还是大家在开发中，其实也是让样式前置

// 伪代码
Widget build(BuildContext context) {
  return new Container(
    width: 20,
    height: 20,
    ...
    child: new Text()
  )
}

我刚开始在学习 Swift 使用的时候也会担心这种样式后置的方式会让样式堆在一起比较难受，但是用了一段时间之后发现，真香！

我们来看一下这样一段代码。

Column() {
  Text(`最新值：${this.counter}`)
  Column().block()
  Column().block()
  Column().block()
    .onClick(() => {
      this.counter ++
    })
}
.margin(10)
.border({width: 4})
.width('50%')
.height('400lpx')
.justifyContent(FlexAlign.SpaceEvenly)

.block 是样式的复用。

@Extend(Column) function block() {
  .width(40)
  .height(40)
  .backgroundColor(Color.Orange)
  .border({
    width: 2,
    color: Color.Red
  })
}

之所以我觉得真香的原因是因为我们在开发过程中，其实子元素的样式重复非常多，因此我们会考虑将子元素的样式封装起来，用一些方式来复用它

这样，当我们将样式后置之后，虽然我们依然对父元素添加了一串样式，但是前面一部分的代码结构就依然非常简洁。

以前在刚开始接触学习 Flutter 的时候，也觉得 Flutter 的 UI 表现形式太糟糕太复杂了，为什么不学着 JSX 那样搞简单一点，并且其他人的这个类似想法还在 github 上有非常激烈的探讨。

直到后来我才理解到，这种注重语义化和容器的 UI 表达方式，可能比 JSX 更好，这才是最佳实践。

除此之外，这种声明式语法的编译速度会比 JSX 更快，性能上会更好

2 总结

鸿蒙应用开发的 ArkUI，和基于 HTML + CSS 的 React 相比，能够更方便的使用语义化，提倡样式与结构合并，并在 UI 设计上，简化了视觉格式化模型，注重容器特性，学习理解成本得到了极大的降低，并且基于 set 的思维方式链式调用样式，大胆的将样式后置，在我个人的主观感受里，这是一种比 React，比 Flutter 更舒适的开发体验

最后分享一份鸿蒙（HarmonyOS）开发学习指南需要的可以扫码免费领取！！！

《鸿蒙（HarmonyOS）开发学习指南》

第一章快速入门

1、开发准备

2、构建第一个ArkTS应用（Stage模型）

3、构建第一个ArkTS应用（FA模型）

4、构建第一个JS应用（FA模型）

5、…

第二章开发基础知识

1、应用程序包基础知识

2、应用配置文件（Stage模型）

3、应用配置文件概述（FA模型）

4、…

第三章 资源分类与访问

1、资源分类与访问

2、创建资源目录和资源文件

3、资源访问

4、…

第四章学习ArkTs语言

1、初识ArkTS语言

2、基本语法

3、状态管理

4、其他状态管理

5、渲染控制

6、…

第五章 UI开发

1.方舟开发框架（ArkUI）概述

2.基于ArkTS声明式开发范式

3.兼容JS的类Web开发范式

4…

第六章 Web开发

1.Web组件概述

2.使用Web组件加载页面

3.设置基本属性和事件

4.在应用中使用前端页面JavaScript

5.ArkTS语言基础类库概述

6.并发

7…

11.网络与连接

12.电话服务

13.数据管理

14.文件管理

15.后台任务管理

16.设备管理

17…

第七章应用模型

1.应用模型概述

2.Stage模型开发指导

3.FA模型开发指导

4…

扫描下方二维码免费领取，《鸿蒙（HarmonyOS）开发学习指南》

HarmonyOS龙哥

关注

26
点赞
踩
19

收藏

觉得还不错? 一键收藏
0
评论
鸿蒙应用开发，比 React 体验更好

鸿蒙应用开发的 ArkUI，和基于 HTML + CSS 的 React 相比，能够更方便的使用语义化，提倡样式与结构合并，并在 UI 设计上，简化了视觉格式化模型，注重容器特性，学习理解成本得到了极大的降低，并且基于set的思维方式链式调用样式，大胆的将样式后置，在我个人的主观感受里，这是一种比 React，比 Flutter 更舒适的开发体验最后分享一份鸿蒙（HarmonyOS）开发学习指南需要的可以扫码免费领取！！！
复制链接

扫一扫