RFC: 关于 Kawa Resume 的设计提案

[fu050409]

前言

当前实际上对于简历， 已经有了多种解决方案，例如我们可以在各种网站上下载Word模板。类似Canva的网站甚至提供了一些在线设计和编辑的方案。毫无疑问的，对于我们来说，大多数情况下这些解决方案并不能完美解决面试者的需求（我们当然希望我们的简历更加精美和有力），所以我认为这个项目毫无疑问是有效的。但是如果仅仅作为一个模板库，那看起来只是相比于前两者使用了前端代码来实现了几乎一致的解决方案，而实际上在易用性上我们还远远比不上它们（我认为我们应该是不会选择再构建一个codeless的在线编辑平台的），如果我们选择这样的方式，对于用户来说大抵更重要的是我们的设计是否足够美观。但是同样的，我并不认为我们能够设计出能够远远超过当前社区中海量的模板库（即便这些模板并不一定是免费的）中的简历模板。

综上，我认为我们应当构建一个能够弹性构建一个简历的框架。我们可以提供一个类似于组件库的核心库来提供所有可能在简历中使用到的组件，以及一个布局预设和主题（样式）预设库。最后我们可以提供一个类似create-vite-app和create-farm的create-kawa-resume来自动的创建一个Kawa Resume项目，这个项目应当支持在配置文件中设置预设（包括布局预设和主题预设）并在构建时生成PDF文件（当然也可以是可选的）。

设计哲学

• 元编程模式：我们将所有部分（包括组件库、样式表预设等）细粒度的拆分开来，每一个部分都可以独立的工作；
• 集成工作模式：我们可以设计类似farm.config.ts和vite.config.ts的配置文件（也可以选择将我们的运行时嵌入在index.ts中，这样或许可以兼容前端编译器的热重载HMR[？]，能够提供更好的预览功能），在此配置文件中可以修改的；
• 预设优先：我们应当尽力避免创建任何被固定的、无法修改和定制的代码，我们应当使用预设模式来保证预设在我们的框架中是“第一等公民”，即通过配置预设（布局和样式）来动态的组成一个完整的简历构建项目；
• 用户优先：我们的项目是面向用户的，所以我们的接口应当是用户友好和用户优先的，为了提高用户的可定制成都，我们应当提供对已有预设微调或再开发的接口。

术语

• 预设： 参考Tailwind Css 预设及Unocss 预设，用预设来替代死板的模板体系。

架构

• 组件库：包含所有可能在简历中使用到的细粒度组件，例如对于个人信息、技术栈等，我们可以提供特定的组件，我们不必为每一个可能的设计都创建完整的解决方案，实际上我们可以实现一个通用的组件作为元解决方案；
• 布局预设：不同的简历设计往往采用不同的布局模式，例如部分设计可能期望个人信息处于简历右侧、顶部或左侧，期望的大小也不同，这部分的设计应当交由预设的设计者；
• 主题预设：对于同一个布局预设，我们当然也应当可以为它配置不同的样式，或许是颜色，或许是一些诸如padding和margin的设计，我们允许创建主题预设来美化任何一个布局预设（这或许类似于使用KDE Plasma？），对于已有预设，应当提供直接进行微调的方法。

[ztygod]

我有一个问题，我们的用户如何将不同组件按照他们意愿组织起来，如果通过创建一个项目的方式，那这样会不会结果可视性很差

[LofiSu]

我有一个问题，我们的用户如何将不同组件按照他们意愿组织起来，如果通过创建一个项目的方式，那这样会不会结果可视性很差

其实就是低代码的意思

[LofiSu]

我有一个问题，我们的用户如何将不同组件按照他们意愿组织起来，如果通过创建一个项目的方式，那这样会不会结果可视性很差

现在先做组件库吧，把物料库先做起来，可以参考一下vchart和阿里那个低代码

[fu050409]

我有一个问题，我们的用户如何将不同组件按照他们意愿组织起来，如果通过创建一个项目的方式，那这样会不会结果可视性很差

我们的项目可以是渐进式的，我们采用元编程的思想，这意味着我们可以为不同场景提供多种解决方案。

[HsiangNianian]

为什么我突然想到了用 hrc 规则包编写简历