使用 Github Workflow 进行发布 tauri
name: 构建应用
description: 构建应用并发布
on:
workflow_dispatch:
push:
branches:
- release/**
tags:
- v*
jobs:
publish-tauri:
后端开发其实没你想的那么难
很多人认为后端技术很复杂，但其实一般项目的技术其实压根就没有那么高要求。什么查询优化，数据缓存弄着弄那的，结果一看数据才几万条。 复杂的其实是业务，而不是技术。技术你不会可以学，但业务可能上一秒做好了，下一秒产品经理就说：“这个流程改一下。” 后端其实很简单 后端的开发，本质其实就是三个步骤： 接收
跨域通信实现实时预览
需求背景 项目中存在一个复杂的代练服务模块，其服务详情页由运营人员手动配置。 由于涉及的功能繁多，如选项配置、联动逻辑、页面文案和折扣信息等，我们为其专门开发了一个配置工具。 此前的操作流程是：运营人员在工具中完成配置后，手动保存并跳转至预览页面查看效果。 这种方式无法实时反馈修改结果，操作流程冗长
逐步从 Pages 路由迁移到 App 路由
App 路由是 NextJS 13 引入的新特性。 它的功能相较于目前使用的 Pages 路由更加丰富，并且支持更多的特性。 例如它支持布局，服务器组件等特性。 具体可以查看官方的文档。 App 路由是可以和 Pages 路由共存的。 这就意味着我们可以逐步进行迁移，逐步替换。 NextJS 会优先
小明编程记- 第十九章 前人心得
听着张三的话，小明点头。 “既然你没有异议，那就准备编写心得吧。我就先走了。”张三说完，御剑破空而去。 目送张三远去，小明回到住所，开始着手整理所学。 可当他提笔欲书时，却猛然发现，自己对 JavaScript 的认知竟然如此浅薄。 “我……到底学了些什么？”他低声自语。 脑海中浮现出一个个零碎的词
新版代练服务功能的设计
前言 目前，项目已有代练功能模块，但随着业务发展，现有功能已无法满足需求。因此，我们需要对其进行优化，以提升功能的灵活性与可维护性。 此次更改基于上一版设计进行改进。 问题分析 原有的代练功能通过渲染组件列表实现，不同类型的组件（如按钮、下拉框、输入框等）根据类型进行渲染。但该设计存在以下问题： 组
代练服务功能设计
需求背景 项目会提供一些游戏相关的服务。 这其中，就包含有代练这一项服务。简单来说，就是玩家雇佣我们去代替玩家本人进行游戏。 通常是在一些需要长时间投入的游戏中，玩家会选择代练。 需求分析 代练的种类有很多，比如： 完成游戏内的任务。 通关副本。 打败 Boss。 推进游戏剧情。 提升等级。 而每个
实现动态表单
需求背景 项目是一个电商类站点。 售卖的商品都是虚拟化物品或服务。 当用户在购买站点售卖商品时，需要填写一些信息。 而根据商品类目的不同，所需要填写的信息也会有所不同。 比如在商品类目 A，用户需要填写邮箱，名称即可。 而在商品类目 B，用户需要填写邮箱，平台，平台账号，平台密码等信息。 随着商品类