enpitsulin

enpitsulin

这个人很懒,没有留下什么🤡
twitter
github
bilibili
nintendo switch
mastodon

Building Desktop Applications with Tauri - A Case Study of TodoMVC (Part 1)

Are you confused about learning Rust? Wrong, it's just too difficult to learn, so let's jump straight into practice. We'll use the classic practical project TodoMVC to implement a rust+sqlite backend and a react frontend for a cross-platform desktop app.

Create a Tauri Project#

Although it's simple to create a new project according to the official documentation.

However, I use pnpm for package management, and to create a project, run the following command:

pnpm create tauri-app

We choose to use the create-vite and then the react-ts template.

Create Project|1481x785

Then wait for the CLI to install the dependencies, open the project with VSCode. Here, I recommend installing rust-analyzer, but I guess it should have been recommended for learning Rust long ago. Our project directory looks like this:

Directory|311x225

The src directory contains the frontend project content, and src-tauri contains the Rust backend. Developing the web interface is just like developing with React, but writing the Rust backend is different from Electron since Rust and Node.js are completely different.

Build the Page#

First, we directly use the CSS provided by the TodoMVC project and install todomvc-app-css.

pnpm add todomvc-app-css

Then import it in the entry file and delete the previously imported stylesheet.

import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App'
import 'todomvc-app-css/index.css'
import './index.css'

ReactDOM.createRoot(document.getElementById('root')!).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
)

Next, create a components directory and create the TodoItem component.

const TodoItem = () => {
  return (
    <li>
      <div className="view">
        <input type="checkbox" className="toggle" autoFocus />
        <label>some todo item</label>
        <button className="destroy"></button>
      </div>
    </li>
  )
}
export default TodoItem

And the TodoList component.

import TodoItem from './TodoItem'
const TodoList = () => {
  return (
    <>
      <header className="header">
        <h1>todos</h1>
        <input type="text" className="new-todo" placeholder="What needs to be done?" />
      </header>
      <section className="main">
        <input type="checkbox" className="toggle-all" />
        <label htmlFor="toggle-all"></label>
        <ul className="todo-list">
          <TodoItem />
        </ul>
      </section>
      <footer className="footer">
        <span className="todo-count">
          <strong>1</strong> items left
        </span>
        <ul className="filters">
          <li>
            <a>All</a>
          </li>
          <li>
            <a>Active</a>
          </li>
          <li>
            <a>Completed</a>
          </li>
        </ul>
      </footer>
    </>
  )
}
export default TodoList

Then in App.tsx, delete the original template code and import TodoList to display it.

import TodoList from './component/TodoList'

function App() {
  return (
    <div className="todoapp">
      <TodoList />
    </div>
  )
}

export default App

Start Tauri#

Then start Tauri, and you can see the effect.

pnpm tauri dev

Effect|1002x789

However, this part only displays a simple HTML structure and corresponding CSS styles without any functionality.

Develop the Backend#

Let's set aside implementing the web interface functionality for now and consider the Rust backend operations. First, let's understand how Tauri communicates.

According to the official documentation, we can mount invoke to the window.__TAURI__ object either by using the TauriAPI package or by setting tauri.conf.json > build > withGlobalTauri to true. It's recommended to enable withGlobalTauri to make debugging easier later, although Tauri has official tests, I find testing directly in the console simpler.

Then we can use invoke to call methods provided by the Rust backend.

The following operations are all under the src-tauri/ directory.

Use SQLite#

First, add the rusqlite dependency to gain the ability to operate SQLite.

[dependencies]
# ...
rusqlite = { version = "0.27.0", features = ["bundled"] }

Operations on the SQLite Database#

Referring to the usage of rusqlite, we create a method to establish a database connection.

fn connect() -> Result<()>{
    let db_path = "db.sqlite";
    let db = Connection::open(&db_path)?;
    println!("{}", db.is_autocommit());
    Ok(())
}

Then we can implement more methods to perform CRUD operations on the database, but writing too many methods requires creating and disconnecting the database connection each time, which is cumbersome. So we can implement a struct TodoApp to encapsulate commonly used methods.

Design the TodoApp Class#

Design the Table Structure#

First, let's design the database table structure.

The Todo table has a relatively simple structure, and the create table statement is:

CREATE TABLE IF NOT EXISTS Todo (
    id          varchar(64)     PRIMARY KEY,
    label       text            NOT NULL,
    done        numeric         DEFAULT 0,
    is_delete   numeric         DEFAULT 0
)

Todo Module#

Next, we create a todo.rs module and establish a Todo struct as the type for database rows for future use. Here, we use pub because we might access these properties in main.

pub struct Todo {
    pub id: String,
    pub label: String,
    pub done: bool,
    pub is_delete: bool,
}

And the TodoApp struct, although its internal methods are not yet implemented.

pub struct TodoApp {
    pub conn: Connection,
}
impl TodoApp {
    //To be implemented
}

Next, we abstract CURD into several member methods. Since Rust does not have a new keyword, we generally define a pub fn new() to construct the corresponding class, which essentially returns a struct that has an impl.

So we add the following implementation.

impl TodoApp{
    pub fn new()->Result<TodoApp>{
        let db_path = "db.sqlite";
        let conn = Connection::open(db_path)?;
        conn.execute(
            "CREATE TABLE IF NOT EXISTS Todo (
                id          varchar(64)     PRIMARY KEY,
                label       text            NOT NULL,
                done        numeric         DEFAULT 0,
                is_delete   numeric         DEFAULT 0
            )",
            [],
        )?;
        Ok(TodoApp { conn })
    }
}

Using the Result enum type is because Connection::open also returns a Result, and we want to simplify error handling using ? for error propagation (although this method does not have Err, it is just to simplify the process).

Then we can construct a TodoApp class using TodoApp::new().unwrap(), using unwrap() to unwrap the Ok from the enum type, which is our returned TodoApp.

Implement Various Methods for TodoApp#

Now that we can construct the class, we want to perform CURD operations on SQLite, so we need corresponding methods like get_todos, get_todo(id), new_todo(todo), update_todo(todo). There is no delete method because the table design already includes the is_delete field, indicating that our deletion will be soft deletion; hard deletion will not be implemented for now.

Query All Todos#

Using the Connection.prepare() method, this method returns a Statement, and several methods of Statement such as query_map, execute, etc., can accept parameters and pass them to the SQL statement during the query and return results.

Here we use the query_map method to get an iterator. By iterating over the iterator, we obtain a Vec<Todo>, which is an array of Todo objects, and then wrap it in a Result enum and return.

Note that methods with generics but not controlled by parameters, like the row.get method on line 6, are called using row.get::<I, T>().

Since SQLite does not have a boolean type, we use numeric values 1 or 0 to represent true or false, and we need to handle these two fields accordingly.

impl TodoApp {
    pub fn get_todos(&self) -> Result<Vec<Todo>> {
        let mut stmt = self.conn.prepare("SELECT * FROM Todo").unwrap();
        let todos_iter = stmt.query_map([], |row| {
            let done = row.get::<usize, i32>(2).unwrap() == 1;
            let is_delete = row.get::<usize, i32>(3).unwrap() == 1;

            Ok(Todo {
                id: row.get(0)?,
                label: row.get(1)?,
                done,
                is_delete,
            })
        })?;
        let mut todos: Vec<Todo> = Vec::new();

        for todo in todos_iter {
            todos.push(todo?);
        }

        Ok(todos)
    }
}

Thus, we can obtain data from SQLite, but we still need to provide commands for the frontend to call. We return to main.rs, first import the module and import Todo and TodoApp.

#![cfg_attr(
    all(not(debug_assertions), target_os = "windows"),
    windows_subsystem = "windows"
)]
mod todo;
use todo::{Todo, TodoApp};

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![
            get_todos,
        ])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

#[tauri::command]
fn get_todos() -> Vec<Todo> {
    todo!()
}

Encapsulate Tauri State

We need to use the Mutex from the Rust standard library and Tauri's state to allow our encapsulated TodoApp object to be called across processes. First, create an AppState struct for state management.

Then use the manage method of tauri::Builder to manage this state. We can then encapsulate the command to use the methods of this object to retrieve data.

#![cfg_attr(
    all(not(debug_assertions), target_os = "windows"),
    windows_subsystem = "windows"
)]
mod todo;
use todo::{Todo, TodoApp};

struct AppState {
    app: Mutex<TodoApp>,
}

fn main() {
    let app = TodoApp::new().unwrap();
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![
            get_todos,
        ])
        .manage(AppState {
            app: Mutex::from(app),
        })
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

#[tauri::command]
fn get_todos() -> Vec<Todo> {
    let app = state.app.lock().unwrap();
    let todos = app.get_todos().unwrap();
    todos
}

Return Data Serialization

After writing the command, I found an error here.

Error|658x358

This is because the returned Vec<Todo> is not a serializable type and cannot be returned to the frontend through the command. Returning to todo.rs, we add annotations to give the struct serialization capabilities.

use serde::{Serialize};

#[derive(Serialize)]
pub struct Todo {
    pub id: String,
    pub label: String,
    pub done: bool,
    pub is_delete: bool,
}

Then we can right-click on the interface to inspect, open the console, and enter await __TAURI__.invoke("get_todos"), and we should see the returned empty array.

get_todos|789x797

Invoke Parameter Deserialization

The need for serialization and deserialization is similar to web applications with separated front and back ends. The transport layer uses JSON format, but the application needs real objects, so we need to add annotations to give objects the Serialize and Deserialize interfaces.

At the same time, the invoke method can also accept a second parameter as the argument for the command call, but the parameters also need to have the ability to deserialize data from JSON format, so we add annotations.

use serde::{Deserialize};
use serde::{Serialize, Deserialize};

#[derive(Serialize)]
#[derive(Serialize, Deserialize)]
pub struct Todo {
    pub id: String,
    pub label: String,
    pub done: bool,
    pub is_delete: bool,
}

Improve CURD#

In addition to using methods from the Statement returned by Connection::prepare, we can also directly execute SQL statements from Connection. For example, to add a new todo, we can get the todo parameter from invoke and deserialize it into a Todo object, then extract the id and label and pass them to the SQL statement parameters to complete the INSERT.

pub fn new_todo(&self, todo: Todo) -> bool {
    let Todo { id, label, .. } = todo;
    match self
        .conn
        .execute("INSERT INTO Todo (id, label) VALUES (?, ?)", [id, label])
    {
        Ok(insert) => {
            println!("{} row inserted", insert);
            true
        }
        Err(err) => {
            println!("some error: {}", err);
            false
        }
    }
}

Similarly, there are update_todo, get_todo, and I won't list too much code here; just a function signature will do. The return value can be wrapped in Result or not; it should not be a big problem, depending on personal preference.

pub fn update_todo(&self, todo: Todo) -> bool {
  // more code
}
pub fn get_todo(&self, id: String) -> Result<Todo> {
  // also more code
}

Similarly, we need to add corresponding commands.

#[tauri::command]
fn new_todo(todo: Todo) -> bool {
    let app = TodoApp::new().unwrap();
    let result = app.new_todo(todo);
    app.conn.close();
    result
}

#[tauri::command]
fn update_todo(todo: Todo) -> bool {
    //to be implemented
}

#[tauri::command]
fn toggle_done(id: String) -> bool {
    //to be implemented
}

And don't forget to add them in generate_handler.

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![
            get_todos,
            new_todo,
            toggle_done,
            update_todo
        ])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Thus, we have basically completed the backend of TodoMVC. In the next part, we will use React + Jotai + some packages to complete the frontend of this application and the communication with the Rust backend~~ this part is quite simple, basically just basic React~~

Next Article Link#

Building Desktop Applications with Tauri - A TodoMVC Example (Part 2)

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.