DEV Community: 叶师傅

让 AI 学会"问一嘴"：assistant-ui 前端工具的人机交互实践

叶师傅 — Tue, 20 Jan 2026 14:04:38 +0000

让 AI 学会"问一嘴"：assistant-ui 前端工具的人机交互实践

🤖 当 AI 助手要帮用户执行敏感操作时，总不能闷头就干吧？得先问问人家确不确认啊！

背景：一个"莽撞"的 AI 助手

我在做一个工单管理系统，里面有个 AI 助手功能。用户可以说"帮我创建一个工单，数量 50"，AI 就会调用工具创建记录。

听起来很美好，但问题来了：

AI 太"自信"了。

它收到指令就直接执行，万一用户说错了呢？万一 AI 理解错了呢？50 变成 500，那可就麻烦了。

所以我需要一个机制：AI 调用工具前，先让用户确认一下。

用户: 帮我创建一个工单，数量 50

AI: 好的，我来帮你创建记录
    ┌─────────────────────────┐
    │ 确认创建记录             │
    │ 名称: A 款               │
    │ 数量: 50                 │
    │ [确认]  [取消]           │
    └─────────────────────────┘

用户: *点击确认*

AI: ✅ 已创建记录：A 款 x 50

这就是所谓的 Human-in-the-Loop（人机协作）模式。

技术选型

前端：React + @assistant-ui/react
后端：Rust + Axum + Rig（AI 框架）
AI：OpenAI GPT-4

assistant-ui 是一个专门为 AI 聊天界面设计的 React 组件库，它有个很棒的特性：前端工具（Frontend Tools）。

架构概览

flowchart TB
    subgraph Frontend["前端 (React)"]
        Runtime[useChatRuntime]
        Tool[CreateRecordTool<br/>前端工具]
        UI[确认 UI]
        Runtime --> Tool --> UI
        UI -->|resume| Tool
        Tool -->|sendAutomatically| Runtime
    end

    subgraph Backend["后端 (Rust)"]
        Handler[Chat Handler]
        FTool[FrontendTool<br/>工具定义转发]
        AI[AI Model]
        Handler --> FTool --> AI
    end

    Runtime <-->|HTTP| Handler

核心概念：前端工具 vs 后端工具

	前端工具	后端工具
执行位置	浏览器	服务器
能否与用户交互	✅ 可以	❌ 不行
适用场景	需要确认的操作	查询、计算

前端工具的精髓在于：工具定义发给 AI，但执行在前端。

AI 知道有这个工具可以用，当它决定调用时，前端拦截执行，可以弹个确认框、让用户填个表单，用户操作完再把结果告诉 AI。

实现步骤

1. 定义工具参数

// schema.ts
import { z } from "zod";

export const CreateRecordSchema = z.object({
  name: z.string().describe("名称"),
  amount: z.number().describe("数量"),
});

2. 创建前端工具

这是最关键的部分，使用 makeAssistantTool：

import { makeAssistantTool } from "@assistant-ui/react";

export const CreateRecordTool = makeAssistantTool({
  toolName: "create-record",
  type: "frontend",  // 🔑 关键：标记为前端工具
  parameters: CreateRecordSchema,
  description: "创建记录",

  // execute 在前端执行
  execute: async (args, ctx) => {
    const { human } = ctx;

    // human() 会暂停执行，等待用户确认
    const response = await human("请确认创建记录");

    if (response === "confirmed") {
      // 调用实际 API
      await api.createRecord(args);
      return { success: true };
    }
    return { success: false };
  },

  // render 渲染确认 UI
  render: ({ args, status, result, resume }) => {
    // 等待确认状态
    if (status.type === "requires-action") {
      return (
        <div className="rounded-lg border p-4">
          <div>确认创建记录</div>
          <div>名称: {args.name} | 数量: {args.amount}</div>
          <button onClick={() => resume("confirmed")}>确认</button>
          <button onClick={() => resume("cancelled")}>取消</button>
        </div>
      );
    }

    // 完成状态
    return <div>{result?.success ? "✅" : "❌"} 已处理</div>;
  },
});

核心 API 解释：

human(message): 暂停执行，等待用户操作
resume(value): 用户操作后恢复执行，value 会作为 human() 的返回值

3. 注册工具

function ChatPage() {
  const processedToolCalls = useRef(new Set<string>());

  const runtime = useChatRuntime({
    transport: new AssistantChatTransport({
      api: "/api/chat",
    }),
    // 工具完成后自动发送结果给后端
    sendAutomaticallyWhen: (options) => {
      if (!lastAssistantMessageIsCompleteWithToolCalls(options)) {
        return false;
      }
      const lastMsg = options.messages.at(-1);
      const toolPart = lastMsg?.parts.find(
        (p) => p.type === "tool-create-record" && p.state === "output-available"
      ) as { toolCallId: string } | undefined;

      if (toolPart && !processedToolCalls.current.has(toolPart.toolCallId)) {
        processedToolCalls.current.add(toolPart.toolCallId);
        return true;
      }
      return false;
    },
  });

  return (
    <AssistantRuntimeProvider runtime={runtime}>
      <Thread />
      <CreateRecordTool />
    </AssistantRuntimeProvider>
  );
}

4. 后端接收工具定义

前端会把工具定义发给后端，后端需要转发给 AI：

// Rust 后端
pub struct FrontendTool {
    pub name: String,
    pub description: String,
    pub parameters: Value,
}

impl ToolDyn for FrontendTool {
    fn name(&self) -> String { self.name.clone() }

    fn definition(&self, _: String) -> ToolDefinition {
        ToolDefinition {
            name: self.name.clone(),
            description: self.description.clone(),
            parameters: self.parameters.clone(),
        }
    }

    fn call(&self, _: String) -> Result<String, ToolError> {
        // 前端工具不在后端执行！
        Err(ToolError::ToolCallError("Frontend tool".into()))
    }
}

完整流程

sequenceDiagram
    participant 用户
    participant 前端
    participant 后端
    participant AI

    用户->>前端: "创建工单，数量 50"
    前端->>后端: 发送消息 + 工具定义
    后端->>AI: 转发
    AI->>后端: 调用 create-record
    后端-->>前端: 返回工具调用
    前端->>前端: execute() → human()
    前端->>用户: 显示确认框
    用户->>前端: 点击确认
    前端->>前端: resume("confirmed")
    前端->>后端: 发送工具结果
    后端->>AI: 转发结果
    AI->>后端: "好的，已记录"
    后端-->>前端: 返回回复
    前端->>用户: 显示完成

踩坑记录

坑 1：`Tool call is not waiting for human input`

原因：没在 execute 里调用 human()，或者在错误状态下调用了 resume()

解决：确保 execute 里有 await human()，且只在 status.type === "requires-action" 时调用 resume()

坑 2：工具完成后消息无限发送

原因：sendAutomaticallyWhen 对同一个工具调用重复返回 true

解决：用 useRef 记录已处理的 toolCallId

const processedToolCalls = useRef(new Set<string>());

sendAutomaticallyWhen: (options) => {
  // ... 找到完成的工具调用
  if (!processedToolCalls.current.has(toolCallId)) {
    processedToolCalls.current.add(toolCallId);
    return true;
  }
  return false;
}

坑 3：用错了 `makeAssistantToolUI`

makeAssistantToolUI 只渲染 UI，不会把工具定义发给后端。如果需要 AI 能调用，必须用 makeAssistantTool。

总结

通过 assistant-ui 的前端工具机制，我们实现了：

AI 能力不打折：AI 仍然可以决定何时调用工具
用户有控制权：敏感操作必须经过用户确认
体验很自然：确认框嵌入在对话流中，不突兀

这套方案已经在生产环境稳定运行，用户再也不用担心 AI "手滑"了 😄

技术栈：React + Rust + Tauri + assistant-ui

如果你也在做 AI 应用，需要人机协作的场景，希望这篇文章对你有帮助！

欢迎评论区交流 👇

Cargo Actions: An efficient tool for managing and creating GitHub Actions workflow templates

叶师傅 — Fri, 31 May 2024 07:04:03 +0000

In software development, continuous integration and continuous deployment (CI/CD) are crucial processes. To simplify this process, I developed Cargo Actions, a command-line tool based on the Rust language, which provides efficient workflow template management and creation functionality for GitHub Actions.

The main functions of Cargo Actions include:

User authentication and login: Securely integrate with GitHub via the OAuth 2.0 protocol, allowing users to log in to Cargo Actions using their GitHub accounts.
Workflow initialization: Support for initializing a workflow from a GitHub repository or template ID, providing a flexible way to integrate GitHub Actions workflows.
Template upload and sharing: Users can upload their own created workflow templates to the Cargo Actions platform and share them with other users.
Personalized template management: Allow users to manage their uploaded and favorite templates, facilitating the quick launch of familiar or commonly used workflow configurations.

Installation

Run the following command in the terminal:

cargo install cargo-actions

Usage

Initialization

Create a project using the GitHub repository URL, and you can omit the https://github.com/ prefix. By default, the workflow template in https://github.com/yexiyue/cargo-actions will be used.

Using the abbreviated form, the rule (User/Repo) is:

cargo actions init yexiyue/cargo-actions

Using the URL form:

cargo actions init https://github.com/yexiyue/cargo-actions.git

Using the SSH form:

cargo actions init git@github.com:yexiyue/cargo-actions.git

You can also use the workflow on the Cargo Actions platform.

Copy the favorite workflow template to the terminal. For example:

cargo actions init 1 -i

Upload Template

If you want to upload your own workflow to the Cargo Actions platform, please log in first.

cargo actions login

Then prepare a workflow template.

A standard workflow template should have the following files:

cargo-action.json: Configuration file used to prompt the user for input
Template name.yaml.hbs: Template file
README.md (optional)

cargo-action.json configuration field description

Field Name	Type	Description
name	string	Template name
description	string	Short description of the template
path	string	Template file path, default `${name}.yaml.hbs`
prompts	Prompt[]	Defines the command-line interactive input items
success_message	string	Success message after template creation

Prompt configuration instructions

There are 4 types of prompts:

type: "input"

Field Name	Type	Description
field	string	Field name (corresponding to the variable name in the template)
prompt	string	Input prompt
default	string	Default value

type: "confirm"

Field Name	Type	Description
field	string	Field name (corresponding to the variable name in the template)
prompt	string	Input prompt
default	bool	Default value

type: "select"

Field Name	Type	Description
field	string	Field name (corresponding to the variable name in the template)
prompt	string	Input prompt
default	number	Index value of the default option
options	{value: any, label: string}[]	Option list, where label is the prompt value and value is the value used in the template at the end

type: "multiselect"

Field Name	Type	Description
field	string	Field name (corresponding to the variable name in the template)
prompt	string	Input prompt
default	number[]	Array of index values of default options
options	{value: any, label: string}[]	Option list, where label is the prompt value and value is the value used in the template at the end

Example:

{
  "name": "web-deploy",
  "description": "Build a web application to Github Pages",
  "prompts": [
    {
      "type": "select",
      "field": "toolchain",
      "prompt": "Please select a package management tool",
      "default": 0,
      "options": [
        {
          "label": "npm",
          "value": "npm"
        },
        {
          "label": "yarn",
          "value": "yarn"
        },
        {
          "label": "pnpm",
          "value": "pnpm"
        }
      ]
    },
    {
      "type": "confirm",
      "field": "enable_cache",
      "prompt": "Enable caching",
      "default": true
    },
    {
      "type": "input",
      "field": "node_version",
      "prompt": "Please enter the node version number",
      "default": "node"
    },
    {
      "type": "input",
      "field": "folder",
      "prompt": "Web project path",
      "default": "."
    },
    {
      "type": "input",
      "prompt": "Build artifact directory (relative to the web project path)",
      "field": "target_dir",
      "default": "dist"
    },
    {
      "type": "confirm",
      "prompt": "Copy index.html to 404.html to support spa",
      "field": "copy_index",
      "default": false
    }
  ]
}

The template file is rendered using handlebars, and the template syntax can be referred to Handlebars (handlebarsjs.com).

Template file example:

name: web on: push: branches: - "master" workflow_dispatch: jobs: deploy:
runs-on: ubuntu-latest permissions: contents: write concurrency: group:
{{#raw}}$\{{ github.workflow }}-$\{{ github.ref }}{{/raw}}
steps: - name: Checkout repository uses: actions/checkout@v4
{{#if (eq toolchain "pnpm")}}
  - name: Install pnpm run: npm install -g pnpm
{{/if}}
- name: Sync node version and setup cache uses: actions/setup-node@v4 with:
node-version: "{{node_version}}"
{{#if enable_cache}}
  {{#if (eq toolchain "pnpm")}}
    cache: "{{folder}}/pnpm-lock.yaml"
  {{/if}}
  {{#if (eq toolchain "npm")}}
    cache: "{{folder}}/package-lock.json"
  {{/if}}
  {{#if (eq toolchain "yarn")}}
    cache: "{{folder}}/yarn.lock"
  {{/if}}
{{/if}}
- name: Install dependencies run: | cd
{{folder}}
{{toolchain}}
install - name: Build run: | cd
{{folder}}
{{toolchain}}
build
{{#if copy_index}}
  cp
  {{target_dir}}/index.html
  {{target_dir}}/404.html
{{/if}}
- name: Deploy uses: peaceiris/actions-gh-pages@v4 with:
{{#raw}}github_token: $\{{ secrets.GITHUB_TOKEN }}{{/raw}}
publish_dir:
{{folder}}/{{target_dir}}

Note:

Expressions in {{{{raw}}}} {{{{/raw}}}} will not be escaped.

Before uploading, you can use the check command to verify if the workflow template is working properly.

cargo actions check

Then use the upload command to upload the workflow template.

cargo actions upload

Using the created template

You can quickly use your own created workflow template with the following command, note that you need to log in.

cargo actions mine

You can also view the workflow template you created in the Cargo Actions platform Personal Center.

Using the favorite template

cargo actions favorite

This command is similar to the mine command, and allows you to select a workflow from the templates you favorited on the Cargo Actions platform for initialization.

View more usage with the following command

cargo actions --help

Conclusion

If you are interested in Cargo Actions, welcome to visit my GitHub repository for more information.

At the same time, if you find this tool helpful, don't forget to give it a like! Your support is the driving force for me to continuously update and improve.

How to Implement Git Clone Operation Progress Display and Cancellation in Rust with Tauri and git2

叶师傅 — Sun, 07 Apr 2024 12:42:44 +0000

In modern software development, integrating Git as a version control system into applications for code management and updates is a common requirement. This article will introduce how to implement progress display and cancellation features for Git clone operations using the Rust language in combination with Tauri and the git2 library.

Core Logic

Firstly, we use the git2 library to implement the Git clone functionality. git2 is a Git library in the Rust language that provides a rich set of APIs for interacting with Git repositories. Next, we leverage the command and event mechanisms provided by the Tauri framework to execute the download operation through commands and handle cancel messages from the front end using atomic boolean values and event listeners. Finally, we implement the cancellation logic to ensure that the download task can be stopped promptly when the user cancels the operation.

Challenges Encountered

When using the remoteCallback of git2, we found that its execution frequency is quite high. If messages are frequently sent to the front end through the Tauri Channel, it may cause the application to become unresponsive. Therefore, we need to throttle message sending to avoid excessive message transmission affecting performance.

Code Implementation

Below is a simplified code example showing how to use Tauri and git2 to implement progress display and cancellation for Git clone operations.

git2 Implementation of Clone and Pull Logic

// Import the Path module from the standard library for handling file paths.
use std::path::Path;

// Import the custom error type MyError for error handling.
use crate::error::MyError;
// Import the anyhow library, which provides a convenient error handling context.
use anyhow::Context;
// Import the derive_builder library for generating builder pattern code.
use derive_builder::Builder;
// Use the git2 library, which provides interfaces for interacting with Git repositories.
use git2::{build::RepoBuilder, FetchOptions, Progress, RemoteCallbacks, Repository};
// Import the tracing library for logging.
use tracing::info;

// Define a constant GITHUB_PROXY to store the URL of the GitHub mirror.
pub const GITHUB_PROXY: &str = "https://mirror.ghproxy.com";

// Git struct definition, using the Builder macro to generate a builder pattern.
#[derive(Debug, Builder, Clone)]
#[builder(setter(into))]
pub struct Git {
    // The URL address of the Git repository.
    url: String,
    // The local repository path.
    path: String,
    // Whether to use a proxy, default to true.
    #[builder(default = "true")]
    proxy: bool,
}

// Implementation of the Git struct.
impl Git {
    // The git_clone method is used to clone a Git repository.
    pub fn git_clone<F>(&self, cb: F) -> Result<(), MyError>
    where
        F: FnMut(Progress) -> bool,
    {
        // Create a RemoteCallbacks object to handle network transfer progress.
        let mut rc = RemoteCallbacks::new();
        rc.transfer_progress(cb);

        // Create a FetchOptions object to set the options for the fetch operation.
        let mut fo = FetchOptions::new();
        fo.remote_callbacks(rc);

        // Construct the repository URL based on whether a proxy is used.
        let url = if self.proxy {
            format!("{}/{}", GITHUB_PROXY, self.url)
        } else {
            self.url.clone()
        };
        // Log the URL for the clone operation.
        info!("git clone {}", url);
        // Use RepoBuilder to clone the repository to the specified path.
        RepoBuilder::new()
            .fetch_options(fo)
            .clone(&url, Path::new(&self.path))?;
        Ok(())
    }

    // The git_pull method is used to fetch updates from the remote repository and merge them into the local repository.
    pub fn git_pull<F>(&self, cb: F) -> Result<usize, MyError>
    where
        F: FnMut(Progress) -> bool,
    {
        // Open the local repository.
        let repo = Repository::open(&self.path)?;
        // Get the remote repository named "origin".
        let remote_name = "origin"; // The default name for the remote repository
        // Connect to the remote repository.
        let mut remote = repo.find_remote(remote_name)?;
        remote.connect(git2::Direction::Fetch)?;

        // Get the default branch name of the remote repository.
        let default_branch = remote.default_branch()?;
        let default_branch_name = default_branch.as_str().context("Failed to get default branch name")?;
        // Set the callback function to handle progress information during the fetch process.
        let mut fetch_opts = FetchOptions::new();
        let mut rc = RemoteCallbacks::new();
        rc.transfer_progress(cb);
        fetch_opts.remote_callbacks(rc);
        // Execute the fetch operation.
        remote.fetch(&[default_branch_name], Some(&mut fetch_opts), None)?;
        // Find the FETCH_HEAD reference.
        let fetch_head = repo.find_reference("FETCH_HEAD")?;
        // Convert the FETCH_HEAD reference to an annotated commit.
        let fetch_commit = repo.reference_to_annotated_commit(&fetch_head)?;
        // Get the merge analysis result.
        let analysis = repo.merge_analysis(&[&fetch_commit])?;
        // If the local repository is up-to-date, then return 1.
        if analysis.0.is_up_to_date() {
            return Ok(1);
        } else if analysis.0.is_fast_forward() {
            // If a fast-forward merge is possible, then perform the merge operation.
            let mut reference = repo.find_reference(default_branch_name)?;
            reference.set_target(fetch_commit.id(), "Fast forward")?;
            repo.set_head(default_branch_name)?;
            return Ok(repo
                .checkout_head(Some(git2::build::CheckoutBuilder::default().force()))
                .map(|_| 2usize)?);
        } else {
            // If it is not a fast-forward merge, then return 0.
            return Ok(0);
        }
    }

    // The builder method is used to create a builder instance for the Git struct.
    pub fn builder() -> GitBuilder {
        GitBuilder::default()
    }
}

tauri Define Front-end Invocation Interface

// Use the Tauri framework's command macro to define a function that can be called by the front end.
#[tauri::command]
pub async fn download_plugin(
    // The app parameter is the handle of the Tauri application, used for communication with the front end.
    app: AppHandle,
    // The config parameter is a state object containing configuration information.
    config: State<'_, MyConfig>,
    // The plugin parameter is an object containing plugin information.
    plugin: Plugin,
    // The on_progress parameter is a channel used to send download progress to the front end.
    on_progress: Channel,
) -> Result<(), MyError> {
    // Clone the configuration information from the state object.
    let config = config.inner().clone();
    // Send a pre-download status message to the front end through the channel.
    on_progress
        .send(
            PluginDownloadMessage::builder()
                .status(PluginStatus::Pending)
                .build()
                .unwrap(),
        )
        .context("Send Message Error")?;

    // Create an atomic boolean value to control the cancellation of the download task.
    let cancel = Arc::new(AtomicBool::new(true));
    // Clone the cancel variable to modify its value within the closure.
    let cancel2 = cancel.clone();
    // Clone the plugin's reference information for subsequent cancellation operations.
    let plugin_reference = plugin.reference.clone();
    // Clone the channel to send messages to the front end within the closure.
    let on_progress2 = on_progress.clone();

    // Use the spawn function from the tokio library to create a new asynchronous task.
    let handler = tokio::spawn(async move {

        // Lock the configuration information for use within the asynchronous task.
        let config = config.lock().await;
        // Record the start time of the download.
        let mut start_time = Instant::now();
        // Initialize the download progress.
        let mut progress = 0f64;

        // Call the plugin's download method and provide a callback function for progress updates.
        match plugin
            .download(&config.comfyui_path, config.is_chinese(), |p| {
                // Check if the download task has been cancelled.
                let v = cancel2.load(std::sync::atomic::Ordering::SeqCst);
                // Calculate the current download progress.
                let new_progress = percent(p.received_objects(), p.total_objects());
                // To avoid blocking due to too many messages being sent, throttle the messages.
                if start_time.elapsed() > Duration::from_millis(60) && progress != new_progress {
                    start_time = Instant::now();
                    progress = new_progress;
                    // Log the current download progress.
                    info!("Download Progress: {}", new_progress);
                    // Send the current download progress to the front end through the channel.
                    on_progress
                        .send(
                            PluginDownloadMessage::builder()
                                .status(PluginStatus::Downloading)
                                .progress(new_progress)
                                .build()
                                .unwrap(),
                        )
                        .unwrap();
                }
                return v;
            })
            .await
        {
            // If the download is successful, send a 100% progress message to indicate the download is complete.
            Ok(_) => {
                on_progress.send(100f64).unwrap();
                // Wait for 500 milliseconds to ensure the message is received by the front end.
                sleep(Duration::from_millis(500)).await;
                // Send a download success status message to the front end.
                on_progress
                    .send(
                        PluginDownloadMessage::builder()
                            .status(PluginStatus::Success)
                            .build()
                            .unwrap(),
                    )
                    .unwrap();
            }
            // If the download fails, send an error status message to the front end.
            Err(e) => {
                if !cancel2.load(std::sync::atomic::Ordering::SeqCst) {
                    // Send an error status message to the front end.
                    on_progress
                        .send(
                            PluginDownloadMessage::builder()
                                .status(PluginStatus::Error)
                                .error_message(e.to_string())
                                .build()
                                .unwrap(),
                        )
                        .unwrap();
                }
            }
        }
    });

    // Listen for cancellation events from the front end.
    app.listen("plugin-cancel", move |event| {
        // Parse the reference information from the event.
        let reference = serde_json::from_str::<Value>(event.payload()).unwrap();
        // If the reference information matches the current plugin's reference information, cancel the download task.
        if reference["reference"] == plugin_reference {
            // If successfully set the cancel variable to false, it means the cancellation operation was successful.
            if cancel
                .compare_exchange(
                    true,
                    false,
                    std::sync::atomic::Ordering::SeqCst,
                    std::sync::atomic::Ordering::SeqCst,
                )
                .is_ok()
            {
                // Send a cancelled status message to the front end.
                on_progress2
                    .send(
                        PluginDownloadMessage::builder()
                            .status(PluginStatus::Canceled)
                            .build()
                            .unwrap(),
                    )
                    .context("Send Message Error")
                    .unwrap();
                // Cancel the asynchronous task.
                handler.abort();
            }
        }
    });

    // The function execution is successful, return Ok.
    Ok(())
}

This code provides a comprehensive guide on how to integrate Git clone operation progress display and cancellation features into a Rust application using Tauri and the git2 library. By following the outlined steps and code examples, developers can effectively manage Git operations within their applications, providing a smooth user experience and the ability to handle long-running tasks with ease.

Axum+SeaORM+Async-graphql: Building a GraphQL Service from Scratch

叶师傅 — Thu, 21 Mar 2024 02:04:58 +0000

This article takes a learner's perspective and guides you step by step to quickly set up a GraphQL service.

First, let's understand what Axum, SeaORM, and Async-graphql are.

Axum

Axum is a high-performance, asynchronous, modular framework for building web applications. It is based on the Rust language and relies on the Tokio asynchronous runtime for handling concurrency and I/O. The main features of Axum include:

Ergonomics and modularity:
- The design focuses on the developer experience, providing an easy-to-use API to organize the structure of applications.
- Supports breaking down application logic into reusable modules, which helps build large and complex services.
No macro-based routing:
- Provides a mechanism for defining and matching HTTP routes without relying on macros, allowing you to clearly declare how requests are dispatched to corresponding handlers.
Extractors:
- Offers a declarative way to extract data from requests, such as query parameters, path parameters, form data, etc.
Middleware support:
- Allows the writing of custom middleware through native methods provided by the axum::middleware module or by combining existing middleware for authentication, logging, error handling, etc.
Asynchronous services:
- Based on Rust's asynchronous programming model, Axum can efficiently utilize system resources, achieving non-blocking I/O and high concurrency performance.
Feature-rich:
- Supports handling various HTTP features, such as GET, POST requests, file uploads, WebSocket connections, and serving static resources.

Axum does not have a very good documentation; when I was learning, I mainly referred to the axum - Rust (docs.rs) library documentation.

SeaORM

SeaORM is an Object-Relational Mapping (ORM) framework written in Rust. It aims to simplify interactions with SQL databases, allowing developers to represent database tables through structured Rust types and provides a convenient, type-safe, and intuitive way to perform CRUD (Create, Read, Update, and Delete) operations.

The main features of SeaORM include:

Multi-database support:
- SeaORM supports various SQL databases, such as SQLite, PostgreSQL, MySQL, etc., allowing developers to easily switch database backends without changing the code.
Entity definition:
- Developers can define Entity structs, annotate them to correspond to tables in the database, and automatically map columns to the struct's fields.
Query builder:
- Provides a flexible and powerful query-building API, making it simple and type-safe to write complex SQL queries.
Active Record pattern:
- SeaORM follows the ActiveRecord pattern, meaning entities can directly manipulate the database like objects, for example, saving, updating, and deleting records.
Asynchronous support:
- For high-performance application scenarios, SeaORM can integrate with asynchronous runtimes and database drivers (such as SQLx) to perform asynchronous I/O operations.
Type safety:
- It emphasizes the advantages of Rust's type system, ensuring that many potential database access errors are caught at compile time.
Migration tools:
- SeaORM also includes database migration tools to help developers manage version control and changes to the database schema.
Modular design:
- It has a high degree of modularity and extensibility, allowing the selection of partial features based on project requirements.

For more information, see the SeaORM official tutorial.

Async-graphql

Async-graphql is an asynchronous GraphQL server library for the Rust language, allowing developers to build high-performance and GraphQL-compliant APIs. Async-graphql provides a complete GraphQL service implementation, including schema definition, resolvers, executors, and subscription features, and is deeply integrated with Rust's asynchronous programming model.

The main features of Async-graphql include:

Asynchronous support: Fully designed based on Rust's asynchronous programming model, leveraging Rust's async/await keywords and Futures to efficiently utilize system resources when handling high-concurrency requests, avoiding blocking, and reducing context-switching overhead.
Type safety: Ensures the safety of GraphQL APIs through Rust's powerful type system, allowing developers to define GraphQL types and catch errors at compile time.
Zero-cost abstractions: Follows Rust's core principles, ensuring ease of use while minimizing runtime overhead.
Flexible schema definition: Provides an intuitive way to define GraphQL schemas, which can be easily mapped to Rust data structures (such as enums, structs) and automatically generate corresponding GraphQL types.
Integration convenience: Can seamlessly integrate with various Rust ecosystem database ORMs (such as Diesel) and HTTP server frameworks (such as Actix-web) for building full-stack Rust applications.
Performance optimization: Due to the characteristics of the Rust language and the library's design, Async-graphql can run GraphQL queries with low memory usage and high throughput.

For more information, see the Async-graphql official tutorial.

The above is just a simple copy and paste of some concepts; the real highlight of this article is about to begin. I believe you are eager to start practicing.

Quick Start

Integrate GraphQL

Shuttle

Shuttle is a cloud service platform that allows users to access and utilize server and database resources for free, aiming to provide convenience for beginners so they can quickly start learning and practicing without additional investment.

You can log in with GitHub to get three free projects.

Install Shuttle:

cargo install cargo-shuttle

Initialize:

cargo shuttle init

Then choose the Axum framework.

Install dependencies:

cargo add async-graphql async-graphql-axum

Then modify main.rs:

use async_graphql::{http::GraphiQLSource, *};
use async_graphql_axum::GraphQL;
use axum::{
    response::{Html, IntoResponse},
    routing::get,
    Router,
};

// Define an enum

#[derive(Debug, Enum, PartialEq, Eq, Clone, Copy)]

enum Role {
    Admin,
    User,
}

impl Default for Role {
    fn default() -> Self {
        Self::User
    }
}

// Define a complex object

#[derive(Debug, SimpleObject, Default)]
#[graphql(complex)]
struct User {
    role: Role,
    username: String,
    email: String,
    address: String,
    age: i32,
}

#[ComplexObject]
impl User {
    async fn users(&self) -> String {
        format!("{:?}", self)
    }
}

// Define a query object

struct Query;

// Implement methods for the query object

#[Object]
impl Query {
    // Asynchronously return a string
    async fn hello(&self) -> String {
        "Hello, world!".to_string()
    }

    // Asynchronously return the GraphiQL page
    async fn graphql() -> impl IntoResponse {
        Html(GraphiQLSource::build().endpoint("/graphql").finish())
    }

    // Asynchronously return a static string
    async fn hello_world() -> &'static str {
        "Hello, world!"
    }
}

// Main function

#[shuttle_runtime::main]
async fn main() -> shuttle_axum::ShuttleAxum {
    // Build the GraphQL Schema
    let schema = Schema::build(Query, EmptyMutation, EmptySubscription)
        .finish();
    // Build the router
    let router = Router::new()
        .route("/", get(hello_world))
        .route("/graphql", get(graphql).post_service(GraphQL::new(schema)));

    // Use the router
    router
}

Then run:

cargo shuttle run

Enter http://127.0.0.1:8000/graphql in your browser to access the GraphQL playground.

Define database tables

Set up migration

If starting with a new database, it's best to version control the database schema. SeaORM comes with a migration tool that allows you to write migrations using SeaQuery or SQL, meaning you write migration code first and then generate entities, the specific content of which can be seen in the above documentation.

Install sea-orm-cli:

cargo install sea-orm-cli

Then initialize migration:

sea-orm-cli migrate init

Add the package to the workspace by modifying the Cargo.toml at the project root:

[dependencies]
// add
entries = { path = "./entries" }
// add
[workspace]
members = ["migration"]

Then write the migration file:

// Include the preset items from the sea_orm_migration library
use sea_orm_migration::prelude::*;

// Use the DeriveMigrationName trait to automatically generate migration names

#[derive(DeriveMigrationName)]
pub struct Migration;

// Implement the MigrationTrait trait, which defines the creation and deletion operations of the database table

#[async_trait]
impl MigrationTrait for Migration {
    // The up method is used to execute the upgrade operation of the database table structure, i.e., creating a new table or modifying the table structure
    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
        // Create the User table
        manager.create_table(
            Table::create()
                .table(User::Table)
                // If the table does not exist, create it
                .if_not_exists()
                // Define theprimary key ID column as an integer type, not null, and auto-increment
                .col(ColumnDef::new(User::Id).integer().not_null().auto_increment().primary_key())
                // Username column, string type and not null
                .col(ColumnDef::new(User::Username).string().not_null())
                // Email column, string type and not null
                .col(ColumnDef::new(User::Email).string().not_null())
                // Address column, string type and not null
                .col(ColumnDef::new(User::Address).string().not_null())
                // Age column, integer type and not null
                .col(ColumnDef::new(User::Age).integer().not_null())
                // Convert the above definitions into an owned Table object
                .to_owned(),
        )
        .await?;
      ...
    }
}

Use Shuttle's database

Shuttle Shared Databases

Step 1: Install Shuttle Shared Database dependencies

To use Shuttle's shared database service in your project, first, you need to install the corresponding Rust libraries. Execute the following command in the directory where your Cargo.toml file is located:

cargo add shuttle-shared-db sea-orm sqlx \
    -F shuttle-shared-db/postgres \
    -F shuttle-shared-db/sqlx \
    -F sea-orm/sqlx-postgres \
    -F sea-orm/runtime-tokio-native-tls

This will add dependencies such as shuttle-shared-db, sea-orm, and sqlx, and specify related features.

Step 2: Configure the main program entry (src/main.rs)

Next, in the src/main.rs file, introduce the necessary modules and modify the main function to utilize Shuttle's database connection pool:

// Introduce necessary modules
use migration::MigratorTrait;
use sea_orm::SqlxPostgresConnector;
use shuttle_runtime::{main, ShuttleAxum};
use shuttle_shared_db::Postgres;

#[main]
async fn main(
    // Add Shuttle Shared Database's Postgres connection pool parameter
    #[shared_db(Postgres)] pool: sqlx::PgPool,
) -> ShuttleAxum {
    // Convert SQLx's PgPool to the connector required by SeaORM
    let connector = SqlxPostgresConnector::from_sqlx_postgres_pool(pool);
}

Step 3: Run the Shuttle application

Make sure Docker is installed, as the Shuttle framework will provide database services by starting database images locally.

Execute the following command to start your application:

cargo shuttle run

After Shuttle successfully starts, you will see the database connection address automatically built and assigned by Shuttle in the console. This address can be used directly to connect to the shared database instance managed by Shuttle, without manual configuration. Please refer to the log information output at runtime for specific connection details, as shown in the figure below.

Now, your application has integrated Shuttle's shared database and has performed the necessary initialization and connection settings, and you can continue to develop data operations and business logic.

Define entities

Step 1: Database migration

Before defining entities, first ensure that the database has been manually migrated. Use the following command to upgrade:

cargo run -p migration -- -u "postgres://postgres:postgres@localhost:22732/postgres"

If you need to revert to a previous migration version, execute the following downgrade command:

cargo run -p migration -- -u "postgres://postgres:postgres@localhost:22732/postgres" down

Step 2: Generate entities

After the database migration is successful, use the command-line tool (sea-orm-cli) provided by sea-orm to generate entity files:

sea-orm-cli generate entity \
    -o entity/src \
    -l \
    -u postgres://postgres:postgres@localhost:22732/postgres \
    --with-serde both \
    --model-extra-attributes='graphql(concrete(name = "Favorite", params()))' \
    --model-extra-derives async_graphql::SimpleObject

This will automatically generate entity model code based on the database table structure.

Step 3: Review the generated directory structure and entity code

The generated entity directory and its contents are as follows:

.
├── Cargo.toml
└── src
    ├── actions.rs
    ├── comment.rs
    ├── favorite.rs
    ├── lib.rs
    ├── prelude.rs
    └── user.rs

Take the favorite.rs file as an example; it contains the entity code automatically generated by sea-orm-codegen:

//! SeaORM Entity. Generated by sea-orm-codegen 0.12.14

// ... (omitted import part)

#[derive(...)]
#[sea_orm(table_name = "favorite")]

#[graphql(concrete(name = "Favorite" params()))] // There is a small error here
pub struct Model {
    #[sea_orm(primary_key, auto_increment = false)]
    pub user_id: i32,
    #[sea_orm(primary_key, auto_increment = false)]
    pub action_id: i32,
    pub create_time: Option,
}

// ... (omitted relationship and ActiveModelBehavior implementation part)

Step 4: Correct the generated entity code

Since there is an error in the GraphQL annotation in the generated favorite.rs, it needs to be manually modified:

#[graphql(concrete(name = "Favorite" params()))]
// Note that a comma is added here, and the name is correctly matched with the table name

Step 5: Initialize and configure the entity module

Enter the entity directory, initialize a new Rust project, and install the required dependencies:

cd entity
cargo init
cargo add async-graphql sea-orm serde -F serde/derive async-graphql/chrono

Step 6: Add the entity module to the workspace

Go back to the Cargo.toml file in the root directory, configure it as a workspace member, and add related dependencies:

[dependencies]
// Other existing dependencies...
migration = { path = "./migration" }
entity = { path = "./entity" }

[workspace]
members = ["entity", "migration"]

Now you have completed the definition and integration of entities. You can further refine or expand these entities and related service codes according to actual needs.

Write services

This section will guide you on how to create a new library package in a Rust application specifically for handling logic related to database interactions. We will implement user service operations through the sea-orm framework and prepare for subsequent writing of tests.

Step 1: Create a service library

First, create a new Rust library under the project root directory:

cargo new --lib service

Next, install the required dependencies:

cargo add entity --path ../entity
cargo add sea-orm -F debug-print,runtime-tokio-native-tls,sqlx-postgres
cargo add tokio --dev -F full

Step 2: Configure Cargo.toml file

Open the service/Cargo.toml file and add mock functionality, configuring related dependencies:

[package]
name = "service"
version = "0.1.0"
edition = "2021"

[dependencies]
entity = { version = "0.1.0", path = "../entity" }
sea-orm = { version = "0.12.14", features = [
    "debug-print",
    "runtime-tokio-native-tls",
    "sqlx-postgres",
] }

[dev-dependencies]
tokio = { version = "1.36.0", features = ["full"] }

[features]
mock = ["sea-orm/mock"]

[[test]]
name = "mock"
required-features = ["mock"]

Step 3: Create and configure test files

Create a file named mock.rs under the tests/ directory, where we will later write mock tests for the service.

The current project directory structure should be as follows:

.
├── Cargo.toml
├── src
│   ├── actions.rs
│   ├── comment.rs
│   ├── favorite.rs
│   ├── lib.rs
│   ├── prelude.rs
│   └── user.rs
└── tests
    └── mock.rs

Step 4: Implement User service

In the src/user.rs file, we define the UserServer struct and implement methods for getting all users, getting a user by ID, creating a user, updating a user, and deleting a user:

use ::entity::{
    prelude::User,
    user::{ActiveModel, Model},
};
use sea_orm::*;

pub struct UserServer;

impl UserServer {
    /// Get all users
    pub async fn get_all_user(db: &DbConn) -> super::Result<()> {
        User::find().all(db).await
    }
}

Other service classes can be derived and implemented in a similar manner.

Summary:

So far, we have successfully created a new library package service and implemented user service operations. In the next section, we will write corresponding unit tests anduse the mock functionality provided by sea-orm to verify these services.

Write service tests

The directory structure is as follows:

.
├── Cargo.toml
├── src
│   ├── actions.rs
│   ├── comment.rs
│   ├── favorite.rs
│   ├── lib.rs
│   ├── prelude.rs
│   └── user.rs
└── tests
    ├── mock.rs
    └── prepare.rs

Step 1: Set up mock data in prepare.rs

First, in the tests/prepare.rs file, create a function to initialize and configure a mock database connection. This function will return a mock DatabaseConnection object and preset query results.

use ::entity::user;
use sea_orm::*;

#[cfg(feature = "mock")]
pub fn prepare_mock_db() -> DatabaseConnection {
    // Create a new Mock database connection
    MockDatabase::new(DatabaseBackend::Postgres)
        // Add query results
        .append_query_results(vec![
            // User 1
            [user::Model {
                id: 1,
                username: "张三".to_string(),
                email: "zhangsan@example.com".to_string(),
                address: "河南省郑州市".to_string(),
                age: 25,
            }],
            // User 2
            [user::Model {
                id: 2,
                username: "李四".to_string(),
                email: "lisi@example.com".to_string(),
                address: "广东省广州市".to_string(),
                age: 30,
            }],
            // User 3
            [user::Model {
                id: 3,
                username: "王五".to_string(),
                email: "wangwu@example.com".to_string(),
                address: "上海市".to_string(),
                age: 22,
            }],
            [user::Model {
                id: 4,
                username: "张三".to_string(),
                email: "zhangsan@example.com".to_string(),
                address: "河南省郑州市".to_string(),
                age: 25,
            }],
            [user::Model {
                id: 4,
                username: "李四".to_string(),
                email: "lisi@qq.com".to_string(),
                address: "地球村".to_string(),
                age: 0,
            }],
            [user::Model {
                id: 6,
                username: "张三6".to_string(),
                email: "zhangsan6@example.com".to_string(),
                address: "河南省郑州市".to_string(),
                age: 6,
            }],
        ])
        // Add execution results
        .append_exec_results([MockExecResult {
            last_insert_id: 4,
            rows_affected: 1,
        }])
        // Convert the Mock database connection to the DatabaseConnection type
        .into_connection()
}

Step 2: Write service tests in mock.rs

Next, in the tests/mock.rs file, write actual service tests. Use the prepare_mock_db function to obtain a mock database connection and perform various operations on the user service.

use entity::user::Model;
use service::user::UserServer;
mod prepare;

#[tokio::test]
async fn test_get_user_by_id() {
    // Prepare mock database connection
    let db = &prepare::prepare_mock_db();

    // ...
}

Run the test command:

cargo test -p service -F mock --test mock -- --nocapture

Note:

Each database read operation requires a corresponding query result to be added in prepare_mock_db.
Delete or other modification operations require corresponding exec_results to be added.
After each operation, the Mock database automatically removes the matching buffered data.
Therefore, when preparing mock results, be sure to consider how many read or delete operations are actually performed in the code.

Writing API Interface Tutorial

This section will guide you on how to create GraphQL API interfaces in a Rust application. We will implement user query and operation-related APIs based on the async-graphql and sea-orm frameworks.

Step 1: Create a Rust library

First, create a new Rust library under the project root directory for writing APIs:

cargo new --lib api

Step 2: Create file structure

Under the api/src directory, create query and mutation subdirectories, and establish corresponding modules and files within them. The final directory structure is as follows:

.
├── Cargo.toml
└── src
    ├── lib.rs
    ├── mutation
    │   ├── mod.rs
    │   └── user.rs
    └── query
        ├── mod.rs
        └── user.rs

Step 3: Configure Cargo.toml file

Edit the api/Cargo.toml file and add dependencies:

[package]
name = "api"
version = "0.1.0"
edition = "2021"

[dependencies]
service = { path = "../service" } // Introduce the service layer library
entity = { path = "../entity" } // Introduce the entity layer library
async-graphql = { version = "7.0.2", features = ["chrono"] }
sea-orm = { version = "0.12.14", features = [
    "sqlx-postgres",
    "runtime-tokio-native-tls",
]}

Step 4: Write query-related APIs

In the query/user.rs file, define the UserQuery struct and implement it as a GraphQL query object:

// query/user.rs
use async_graphql::*;
use service::user::UserServer;

#[derive(Default)]
pub struct UserQuery;

#[Object]
impl UserQuery {
    pub async fn get_users(&self, ctx: &Context<'_>) -> Result<()> {
        let db = ctx.data()?;
        let users = UserServer::get_all_user(db).await?;
        Ok(users)
    }
}

In the query/mod.rs, import and merge the query object:

// query/mod.rs
use async_graphql::MergedObject;

use self::user::UserQuery;
mod user;

#[derive(Default, MergedObject)]
pub struct Query(UserQuery);

Step 5: Write mutation-related APIs

In the mutation/user.rs file, define the UserMutation struct and implement it as a GraphQL mutation object, and also define input objects:

// mutation/user.rs
use async_graphql::*;
use entity::user;
use service::user::UserServer;

#[derive(InputObject)]
pub struct CreateUserInput {
    username: String,
    email: String,
    address: String,
    age: i32,
}

impl Into for CreateUserInput {
    fn into(self) -> user::Model {
        user::Model {
            id: 0,
            username: self.username,
            email: self.email,
            address: self.address,
            age: self.age,
        }
    }
}

#[derive(InputObject)]
pub struct UpdateUserInput {
    id: i32,
    email: String,
    address: String,
    age: i32,
}

impl Into for UpdateUserInput {
    fn into(self) -> user::Model {
        user::Model {
            id: self.id,
            username: "".to_string(),
            email: self.email,
            address: self.address,
            age: self.age,
        }
    }
}

#[derive(Default)]
pub struct UserMutation;

#[Object]
impl UserMutation {
    // Create a user
    pub async fn create_user(
        &self,
        ctx: &Context<'_>,
        input: CreateUserInput,
    ) -> Result<()> {
        let db = ctx.data()?;
        let res = UserServer::create_user(db, input.into()).await?;
        Ok(res)
    }

    // ...
}

// mutation/mod.rs
use async_graphql::MergedObject;

use self::user::UserMutation;
mod user;

#[derive(MergedObject, Default)]
pub struct Mutation(UserMutation);

Step 6: Build the GraphQL Schema

In the src/lib.rs file, import the query and mutation modules, and define a function to build the GraphQL schema:

// src/lib.rs
mod mutation;
mod query;
use async_graphql::*;
use mutation::Mutation;
use query::Query;
use sea_orm::DbConn;

pub fn build_schema(db: DbConn) -> Schema {
    Schema::build(Query::default(), Mutation::default(), EmptySubscription)
        .data(db)
        .finish()
}

Now you have successfully built user query and mutation-related GraphQL API interfaces based on async-graphql and sea-orm. In practice, you can integrate these interfaces into your application server to provide services as needed.

Deploy the application using Shuttle

Step 1: Integrate the API package in the main program

First, in the src/main.rs file under the project root directory, add the previously created api package as a dependency, and use the methods provided by the api to build the GraphQL schema in the main function.

// Introduce necessary modules and packages
use async_graphql::{http::GraphiQLSource, *};
use async_graphql_axum::GraphQL;
use axum::{
    response::{Html, IntoResponse},
    routing::get,
    Router,
};
use migration::MigratorTrait;
use sea_orm::SqlxPostgresConnector;
use api; // Introduce the api library

async fn graphql() -> impl IntoResponse {
    Html(GraphiQLSource::build().endpoint("/graphql").finish())
}

async fn hello_world() -> &'static str {
    "Hello, world!"
}

#[shuttle_runtime::main]
async fn main(#[shuttle_shared_db::Postgres] pool: sqlx::PgPool) -> shuttle_axum::ShuttleAxum {
    let coon = SqlxPostgresConnector::from_sqlx_postgres_pool(pool);
    migration::Migrator::up(&coon, None).await.unwrap();
    // ...
}

Step 2: Local run and test

Run the application locally to verify that the interfaces are working properly:

cargo shuttle run

Visit http://localhost:3000/graphql to view and test the GraphQL API interfaces, and check the welcome page at http://localhost:3000/. Upon success, you should see the GraphiQL page as shown below:

Step 3: Deploy to Shuttle

Idle Projects - Shuttle

Start a new project

Start a never-idle new project in the Shuttle environment (set --idle-minutes to 0):

cargo shuttle start --idle-minutes 0

Deploy the application

Use the cargo shuttle deploy command to deploy the application to the Shuttle platform:

cargo shuttle deploy

After successful deployment, you will see success messages similar to the following in the console:

Your application has now been successfully deployed to the Shuttle platform and can be accessed and managed as needed. Please note that actual deployment may require specific configurations based on the Shuttle environment.

🚀 dialoguer-macro Framework 0.3 Release: Redefining Command Line Interaction Design

叶师傅 — Sun, 17 Mar 2024 04:07:00 +0000

🎉 Dear developers, I am thrilled to present the latest masterpiece from the dialoguer-macro library—version 0.3! This groundbreaking update will revolutionize your traditional understanding of command line user interaction design. We have proudly introduced powerful support for enums and nested structures in this new release, allowing you to effortlessly create structured, hierarchical command line interfaces with elegance and clarity.

📚 Documentation Tutorial Direct Link: https://yexiyue.github.io/dialogue-macro/

🎯 Practical Demonstration Primer:

In this blog post, we'll delve into a vivid example demonstrating how to leverage the SubAsker attribute along with the associated Asker, Build, and EnumAsker traits in dialoguer-macro 0.3 to craft an efficient and user-friendly command line data collection process.

Let's dive right in!

First, define a struct called UserInput that is adorned with the #[derive(Asker)] and #[asker(theme = "...")] macros, thereby enabling a visually appealing and feature-rich command line input interface:

use dialogue_macro::{Asker, Build, EnumAsker};

#[derive(Debug, Asker)]
#[asker(theme = "dialogue_macro::ColorfulTheme")]
struct UserInput {
    // Basic information fields
    username: String,
    educational_institution: String,

    // Use SubAsker to collect detailed user information
    #[asker(SubAsker)]
    detailed_info: DetailedUserInfo,

    // Use SubAsker for identity selection
    #[asker(SubAsker)]
    identity: EnumSelection,
}

Next, we carefully construct two nested data structures for questioning:

The DetailedUserInfo struct encapsulates the user's email address and age attributes. To work harmoniously with SubAsker, this struct implements not only the Debug and Clone traits but also Asker and Build. The .build() method is defined within the impl Build for DetailedUserInfo to sequentially collect email address and age from the user:

#[derive(Debug, Clone, Asker)]
struct DetailedUserInfo {
    email_address: String,
    age: u8,
}

impl Build for DetailedUserInfo {
    fn build() -> Self {
        Self::asker()
            .email_address("Please provide your email address")
            .age("Enter your age")
            .finish()
    }
}

The EnumSelection enum consists of Teacher, Student, and Leader options. Besides implementing Debug, Clone, it derives the EnumAsker trait, which means it presents these choices in a clear and intuitive way to the user:

#[derive(Debug, EnumAsker, Clone)]
#[asker(prompt="Please select your identity", default="Student")]
enum EnumSelection {
    Teacher,
    Student,
    Leader,
}

Finally, inside the main function, we instantiate the UserInput object and call the respective asking methods for each field in logical order:

fn main() {
    let collected_user_input = UserInput::asker()
        .username("Please enter your username")
        .educational_institution("Please enter your school name")

        // Invoke SubAsker to collect detailed user info
        .detailed_info()

        // Invoke another SubAsker to allow user selection from an enum
        .identity()

        // Gather all user inputs and complete the questioning process
        .finish();

    println!("{:?}", collected_user_input);
}

When the program runs, users are guided through a series of questions in a pre-defined hierarchical sequence, experiencing a sophisticated yet organized command line interaction journey.

Through this sample code, we demonstrate how to use features like SubAsker to easily achieve well-structured command line interaction designs. If you're excited about what this library has to offer and would like to try out these innovative features in your projects, head straight to our GitHub repository:

👉 GitHub Project Homepage: https://github.com/yexiyue/dialogue-macro

We sincerely invite you to follow my project, test the new version of dialoguer-macro, and be part of its growth. By clicking the "Star" button on the repository page, you can lend us valuable support and encouragement. Moreover, I eagerly anticipate your feedback, contributions, and real-world application case studies!

DEV Community: 叶师傅

让 AI 学会"问一嘴"：assistant-ui 前端工具的人机交互实践

让 AI 学会"问一嘴"：assistant-ui 前端工具的人机交互实践

背景：一个"莽撞"的 AI 助手

技术选型

架构概览

核心概念：前端工具 vs 后端工具

实现步骤

1. 定义工具参数

2. 创建前端工具

3. 注册工具

4. 后端接收工具定义

完整流程

踩坑记录

坑 1：Tool call is not waiting for human input

坑 2：工具完成后消息无限发送

坑 3：用错了 makeAssistantToolUI

总结

Cargo Actions: An efficient tool for managing and creating GitHub Actions workflow templates

Installation

Usage

Initialization

Upload Template

Using the created template

Using the favorite template

View more usage with the following command

Conclusion

How to Implement Git Clone Operation Progress Display and Cancellation in Rust with Tauri and git2

Core Logic

Challenges Encountered

Code Implementation

Axum+SeaORM+Async-graphql: Building a GraphQL Service from Scratch

🚀 dialoguer-macro Framework 0.3 Release: Redefining Command Line Interaction Design

坑 1：`Tool call is not waiting for human input`

坑 3：用错了 `makeAssistantToolUI`