Jetpack Compose是一种声明式UI，它可以随着数据的变化而自动更新UI。它对于列表的变化和内容的更新非常敏感，也方便易用。因此我在想，用它来制作一个类似于Notion的块式文本编辑器，是否也可以如此方便呢？

因此我在《小鹅事务所》的笔记模块中尝试把旧的富文本编辑器（EditText渲染 + HTML持久化）替换成Compose块式编辑器（TextField编辑 + Markdown持久化 + Text渲染）。

阅读该文章需要部分Room、Compose基础，由于篇幅内容并不会过多解释概念，由于代码冗杂，我只会在文章中放重点部分代码，若大家感兴趣可以clone一份到本地，准备好的话我们开始吧。

本次数据存储将使用SQLite完成，我们可以使用Room作为数据库框架。先定义两个Entity类创建两个表，分别是Note和NoteContentBlock。

Note entity存放自增的主键id、标题和最后修改时间。

NoteContentBlock entity存放id、关联Note的note_id、index和内容。index为该block在列表中的索引。

定义完数据类之后，Room需要一个Dao来定义和数据库的交互逻辑。

在编写函数之前，我们注意到，每一个Note可能关联多个NoteContentBlock，而他们的关联点为Note中的id和NoteContentBlock的note_id。因此可以写出以下SQL Query语句。

这个方法需要执行两次查询，因此需要添加 @Transaction 注解，以确保整个操作以原子方式执行。尽管我们知道只会找到一个Note和一个NoteContentBlock列表，由于SQLite本身不知道会找到多少对Note和NoteContentBlock列表，因此只能返回一个Map。而此处我使用了Flow 来监听数据的变化。

创建一个数据库类

根据谷歌目前的最佳架构实践，创建Repository和UseCase类作为Domain层。以下展示部分代码：

由于Compose是声明式UI，可以使用@Preview注解加上假数据预览，非常方便。因此我们可以先看UI层，可以先定义需要什么State，再去ViewModel层为UI层准备State。

NoteScreen可以分为三部分，分别为TopBar、BottomBar和App Content。我们先从顶层往底层拆解App Content。

App Content分为两个模式，Markdown预览模式和编辑模式，我们先看编辑模式的UI：

编辑模式的页面由两个部分组成，分别为标题的编辑TextField和内容的编辑列表，我们可以使用LazyColumn来完成。

这个页面UI就这么简单，由三个部分组成，分别为标题、内容、添加block的按钮。

由于LazyColumn的item默认是没类似于RecyclerView 的item动画的，可以使用animateItemPlacement把动画加上。

我们重点看NoteContentBlockItem，设计该UI需要考虑两个非常重要的功能：

那么该怎么解决这两个问题呢？我们大家在学习Compose的时候经常看到一个名词：状态提升。只要我们把所需要的状态提升到最低的共同的父级就，不同的组件就可以通过共享这个状态来实现它们之间的通信，这样问题就解决了。

滑动删除可以使用谷歌Material3提供的Compose函数：SwipeToDismiss

而Delete Icon变大的动画怎么做呢？可以使用animateFloatAsState动画API，如下：

关于Compose如何渲染Markdown文本可以查看Rendering Markdown with Jetpack Compose，我使用Mike Penz根据这个思想编写的多平台Compose Markdown渲染库来进行MD渲染。

在渲染之前，需要把列表中的所有block全部合在一起，形成一个完整的Markdown文本，于是我使用了produceState函数，先给一个空字符串初始值，然后Markdown文本再放到子线程进行加工。

由于一个Markdown文本是很长的，并且需要滑动，因此需要使用verticalScrollModifier。

渲染出来的效果如下所示，感觉还不错：

关于Block的md格式化应该怎么做到呢？我们需要考虑几个点：

因此我们需要TextFieldValue,并修改其中的selection字段来实现复位。

我们在实例MutableInteractionSource的时候可以对其中的interactions进行监听，示例代码如下：

若监听到某一个Block获取到焦点，则可以将焦点id存到本地，供format的时候进行读取。若某个Block失去焦点了，则可以判断当前焦点id是否为失去焦点的block的id，如果是的话则清除焦点，如果不是的话就不做操作。

这里考虑到一点：监听到新的焦点和旧的焦点丢失的时序是不确定的，因此需要加一个判断操作。

由于本地已经存了一份焦点id，因此我们在执行format文本的时候可以先去本地获取：

由于存的是焦点id，因此需要去最新的NoteContentBlock列表中去找最新的block。那么为什么不直接存焦点block数据结构呢？

由于实例化MutableInteractionSource监听焦点的时候，NoteContentBlock刚刚被创建，并且在监听到取焦点的时候获取到的刚刚被创建的block是旧的。会有数据过时的问题，而id是恒不变的，因此存下为焦点id。

需要注意的是此处使用了findLast来查找而不是find的原因是：我们通常编辑列表下方文本比较多，因此findLast可以节省部分时间。

若需要获取上下文信息，则可以根据找到的block的索引信息去列表去查找，例如我想找到上一个block的有序列表数字我可以这么干：

然后就可以对TextFieldValue进行format操作了

代码中的format是一个扩展函数，我目前定义了两个FormatType大类：

我们简单看一下formatList如何操作：

需要注意的是：在执行完format之后，需要同步修改selection，否则会出现上面动图的Cursor不跟手的现象。修改完selection之后，在选中部分文本进行format，选中的区域也会同步移动。

由于所有复杂逻辑都是在ViewModel来进行的，那么该如何驱动UI变化呢？其实非常简单，有且仅有两种方式：UI State变更、Event发送。

众所周知，在Compose中维护UI状态并驱动UI变更大多数使用的是如下State：

在ViewModel中也可以使用mutableStateOf来维护UI状态，在逻辑简单的情况下这么做也是最佳实践。但是在这次的逻辑比较复杂，如果使用到Flow会极大提高编码效率。在ViewModel中维护StateFlow并且在Compose中转换成所需的State：

有两个API可以将Flow转换成State，前者在所有时间都会监听并刷新UI。而后者仅在指定Lifecycle.State以上的状态才能监听并刷新UI，默认为START。

使用StateFlow需要注意的一点是：StateFlow会使用equals判断新进来的value是否相等，若相等的话，UI就不监听这个value，防止不必要的UI刷新。

因此在使用的时候我有以下建议：

举一个我在代码中的例子：

牢记这一点很重要。

可能有人会说：重复创建很多实例了，会造成很多没必要的性能消耗。

这里我引用Effective Java中的一句话，关于这一点的讨论可以翻阅原文：

“当你应该创建新对象的时候，请不要重用现有的对象”，在提倡使用保护性拷贝的时候，因重用对象而付出的代价要远远大于因创建重复对象而付出的代价。

有某些时候，逻辑层不仅仅需要为UI层提供UI State，还需要发送事件。举个例子，在新增block的时候，我想把焦点转移到新的block。

但是，ViewModel的viewModelScope是不允许调用LazyListState的scrollTo函数的，缺少MonotonicFrameClock上下文，而这个上下文是Compose的CoroutineScope中自带的。

因此我可以把新增block的事件发送到UI层，UI层监听该事件去滑动到新增的block并申请焦点，代码如下。

FocusRequester需要被添加到Compose组件中才可以申请焦点，否则会报错，因此做了重试操作。由于LazyListState的scrollTo函数一般在Compose组件被渲染之后才执行完毕，因此申请焦点的时候一般不会报错，保险起见做了一个重试操作。

当我在使用ViewModel的时候，我发现了一个问题，当我把所有逻辑都写在了ViewModel，由于我需要BottomBarState，ContentState等等，整个ViewModel变得臃肿不堪难以维护。

针对这个问题，我结合Kotlin委托属性的功能，把StateFlow和它所附带的逻辑整个委托出去，所有逻辑封装在委托类中，而我只需要取这个StateFlow就好了，我不关注也无法获取委托类中的逻辑。

于是我写出了如下代码：

ViewModel层由多个委托实现逻辑，并且这些委托封装了大量逻辑，仅暴露了一个StateFlow的value，除此之外无法获取委托中的其他信息，不仅解耦了逻辑，还极大增加了封装性。关于架构这一块我后续可能会聊聊。

絮絮叨叨地把《小鹅事务所》中的Markdown编辑器模块的思路和坑点给讲了一遍，我也不知道讲明白没有，我不喜欢展示太多代码，建议clone一份代码到本地看一下。该模块还有很多不完善之处，仅做抛砖引玉作用。

使用Compose实现文本块编辑器还算比较轻松，心智负担非常小，编写不同模块的时候无需考虑其他模块的事情。

关于Markdown实际渲染我着墨不多，更多的是如何编写文本块编辑器，但是关于Markdown渲染的思想非常建议看一下Rendering Markdown with Jetpack Compose，里面的思路非常新颖。

Rendering Markdown with Jetpack Compose

多平台Compose Markdown渲染库

Room官方教程

StateFlow

Effective Java第三版

Compose状态提升