وقتی می‌خواهید یک نرم‌افزار دسکتاپ برای مدیریت بیماران، حسابداری، انبارداری یا هر کاربرد تجاری دیگری بسازید، ظاهر برنامه فقط یک موضوع تزئینی نیست. رابط کاربری مستقیماً روی سرعت کار، میزان خطای کاربران و حتی هزینه آموزش کارکنان تأثیر می‌گذارد. برای مثال، در یک نرم‌افزار مدیریت کلینیک، اگر جست‌وجوی بیمار، ثبت پذیرش و مشاهده نوبت‌ها در جای مناسبی قرار نگیرند، اپراتور مجبور می‌شود برای انجام کارهای ساده بارها بین صفحات مختلف جابه‌جا شود. این مشکل را نمی‌توان صرفاً با انتخاب رنگ‌های زیبا حل کرد؛ شما به یک ساختار منظم، کامپوننت‌های قابل استفاده مجدد و الگوی طراحی مشخص نیاز دارید.
ترکیب Tauri، React، TypeScript و Tailwind CSS می‌تواند چنین بستری را فراهم کند. Tauri امکان ساخت برنامه دسکتاپ با استفاده از فناوری‌های وب را می‌دهد، React برای مدیریت رابط‌های تعاملی مناسب است، TypeScript به کاهش خطاهای برنامه‌نویسی کمک می‌کند و Tailwind CSS سرعت پیاده‌سازی استایل‌ها را افزایش می‌دهد. بر اساس مستندات رسمی Tauri، این فریم‌ورک می‌تواند از رابط‌های ساخته‌شده با فناوری‌های مختلف وب استفاده کند و منطق سمت سیستم را با Rust پیاده‌سازی کند.
در این مقاله، مرحله‌به‌مرحله بررسی می‌کنیم که چگونه این ابزارها را کنار هم قرار دهید و یک رابط کاربری حرفه‌ای، قابل نگهداری و مناسب نرم‌افزارهای واقعی بسازید.
آشنایی با Tauri و نقش Tailwind CSS
Tauri چگونه رابط کاربری را نمایش می‌دهد؟
Tauri را بهتر است یک پوسته دسکتاپ برای برنامه‌های مبتنی بر فناوری وب بدانید. شما رابط کاربری را با HTML، CSS و JavaScript یا فریم‌ورک‌هایی مانند React می‌سازید و Tauri آن را در WebView سیستم‌عامل نمایش می‌دهد. در بخش بک‌اند نیز می‌توانید از Rust برای کارهایی مانند خواندن فایل‌ها، اجرای عملیات پایگاه داده و پردازش اطلاعات استفاده کنید. این معماری باعث می‌شود مجبور نباشید برای ساخت رابط کاربری از ابتدا سراغ فناوری‌های اختصاصی ویندوز بروید؛ در عوض، از ابزارهایی استفاده می‌کنید که در توسعه وب نیز کاربرد دارند.
نکته مهم این است که Tauri خودش جایگزین CSS یا React نیست. مسئولیت Tauri فراهم‌کردن محیط اجرای دسکتاپ و ارتباط کنترل‌شده با قابلیت‌های سیستم است، در حالی که React ساختار و رفتار رابط را مدیریت می‌کند و Tailwind CSS مسئول استایل‌دهی است. بنابراین، اگر دکمه‌ای در برنامه شما اندازه نامناسب دارد یا جدول اطلاعات از پنجره بیرون می‌زند، معمولاً باید مشکل را در ساختار React، قوانین CSS یا نحوه چیدمان اجزا بررسی کنید، نه در کد Rust. طبق مستندات رسمی، Tauri در زمان ساخت، فایل‌های فرانت‌اند را به‌صورت دارایی‌های برنامه بسته‌بندی می‌کند؛ به همین دلیل، فرانت‌اند باید به‌درستی ساخته و مسیر خروجی آن تنظیم شده باشد.
چرا Tailwind CSS برای برنامه‌های دسکتاپ مناسب است؟
Tailwind CSS یک فریم‌ورک CSS مبتنی بر کلاس‌های کاربردی است. به‌جای اینکه برای هر عنصر یک کلاس اختصاصی تعریف کنید و سپس به فایل CSS دیگری بروید، می‌توانید ویژگی‌هایی مانند فاصله، رنگ، اندازه متن، حاشیه و نحوه چیدمان را مستقیماً روی عنصر مشخص کنید. برای نمونه، عبارت className="flex items-center gap-3 rounded-xl bg-white p-4 shadow-sm" یک ظرف انعطاف‌پذیر با فاصله مناسب بین اجزا، گوشه‌های گرد و پس‌زمینه سفید ایجاد می‌کند. این روش هنگام ساخت داشبوردها، فرم‌های طولانی و جدول‌های اطلاعاتی کاربرد زیادی دارد، زیرا بسیاری از تغییرات را بدون رفت‌وآمد میان چندین فایل انجام می‌دهید.
البته نباید تصور کنید که استفاده از Tailwind به‌تنهایی رابط حرفه‌ای تولید می‌کند. اگر رنگ‌ها، فاصله‌ها، اندازه فونت‌ها و رفتار اجزا بدون قاعده انتخاب شوند، نتیجه می‌تواند به مجموعه‌ای از صفحه‌های ناهماهنگ تبدیل شود. راهکار بهتر این است که از همان ابتدا یک سیستم طراحی کوچک تعریف کنید، کامپوننت‌های تکراری را استخراج کنید و کلاس‌های Tailwind را در جای مناسب به کار ببرید. مستندات رسمی Tailwind نیز بر تولید CSS از روی کلاس‌های شناسایی‌شده در فایل‌های پروژه تأکید دارد؛ بنابراین، این ابزار هنگام ساخت خروجی نهایی تنها به کلاس‌های قابل شناسایی در منابع پروژه متکی است.
Tailwind CSS
+1
آماده‌سازی پروژه Tauri با React و TypeScript
برای پیاده‌سازی رابط کاربری، فرض می‌کنیم پروژه شما با Tauri 2، React، TypeScript و Vite ساخته شده است. این انتخاب به شما اجازه می‌دهد کدهای رابط کاربری را از منطق بک‌اند جدا نگه دارید و در صورت نیاز، ساختار برنامه را توسعه دهید. اگر پروژه از قبل ساخته شده است، نیازی نیست آن را از ابتدا ایجاد کنید؛ کافی است نسخه Tailwind و پیکربندی فعلی Vite را بررسی کنید. یک اشتباه رایج این است که توسعه‌دهنده بدون توجه به نسخه موجود، دستورات نصب نسخه‌های قدیمی Tailwind را اجرا می‌کند و سپس با فایل‌های تنظیماتی غیرضروری یا ناسازگار مواجه می‌شود.
نصب Tailwind CSS نسخه ۴ با Vite
در نسخه ۴، روش پیشنهادی مستندات رسمی Tailwind برای پروژه‌های Vite استفاده از افزونه اختصاصی @tailwindcss/vite است.
Tailwind CSS
+1
اگر در پوشه اصلی پروژه قرار دارید، دستور زیر را اجرا کنید:
npm install tailwindcss @tailwindcss/vite
سپس فایل vite.config.ts را بررسی کنید. در پروژه‌ای که از افزونه React استفاده می‌کند، تنظیمات می‌تواند به شکل زیر باشد:
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import tailwindcss from "@tailwindcss/vite";
export default defineConfig({
plugins: [
react(),
tailwindcss(),
],
clearScreen: false,
server: {
port: 1420,
strictPort: true,
watch: {
ignored: ["**/src-tauri/**"],
},
},
});
در این مثال، افزونه React مسئول پردازش فایل‌های React است و افزونه Tailwind فرایند تولید CSS را انجام می‌دهد. تنظیم strictPort نیز مانع آن می‌شود که Vite در صورت اشغال بودن پورت موردنظر، بی‌صدا به پورت دیگری منتقل شود. این موضوع در پروژه Tauri اهمیت دارد، زیرا نشانی سرور توسعه باید با تنظیمات برنامه هماهنگ باشد. اگر پروژه شما از قبل تنظیمات متفاوتی دارد، آن‌ها را کورکورانه جایگزین نکنید؛ تنظیمات موجود را با این نمونه تطبیق دهید.
تنظیم فایل‌های اصلی استایل
پس از نصب، فایل CSS اصلی پروژه را باز کنید؛ برای مثال، src/index.css. در Tailwind نسخه ۴، واردکردن فریم‌ورک معمولاً به یک دستور نیاز دارد:
@import "tailwindcss";
حالا مطمئن شوید این فایل در نقطه ورود فرانت‌اند وارد شده است. برای نمونه، در src/main.tsx می‌توانید چنین ساختاری داشته باشید:
import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";
import "./index.css";
ReactDOM.createRoot(
document.getElementById("root")!
).render(
);
اگر فایل CSS را وارد نکنید، نصب موفق پکیج‌ها به معنی فعال‌شدن استایل‌ها نیست. همچنین، دستورهای نسخه سوم مانند @tailwind base و @tailwind utilities را نباید بدون بررسی نسخه در پروژه نسخه چهارم کپی کنید. در نسخه چهارم، شیوه ورود CSS تغییر کرده و افزونه Vite نیز مسیر پیشنهادی متفاوتی دارد.
Tailwind CSS
+1
برای آزمایش اولیه، این کد را در کامپوننت اصلی قرار دهید:
export default function App() {
return (
نرم‌افزار مدیریت کلینیک
رابط کاربری با Tauri و Tailwind CSS
); }
اگر پس‌زمینه خاکستری، عنوان سبزآبی و فاصله‌های تعیین‌شده را مشاهده کردید، مسیر پایه استایل‌دهی فعال است. در صورت نمایش‌ندادن این تغییرات، ابتدا ورود فایل CSS، تنظیمات Vite و خطاهای ترمینال را بررسی کنید.
طراحی ساختار اصلی رابط کاربری
ساخت Layout و منوی کناری
در یک نرم‌افزار دسکتاپ، بهتر است اجزای ثابت مانند سربرگ، منوی کناری و ناحیه محتوای اصلی در یک Layout مشترک قرار بگیرند. فرض کنید نرم‌افزار کلینیک شما بخش‌های داشبورد، بیماران، پذیرش، پرونده‌ها، خدمات و گزارش‌ها را دارد. اگر برای هر صفحه سربرگ و منوی جداگانه بسازید، با تغییر کوچک در ظاهر برنامه مجبور خواهید شد چندین فایل را اصلاح کنید. این کار هم زمان توسعه را افزایش می‌دهد و هم احتمال ناهماهنگی صفحات را بالا می‌برد.
ساختار پیشنهادی می‌تواند چنین باشد:
src/
├── components/
│ ├── ui/
│ │ ├── Button.tsx
│ │ ├── Input.tsx
│ │ └── DataTable.tsx
│ ├── layout/
│ │ ├── Header.tsx
│ │ └── Sidebar.tsx
│ └── AppLayout.tsx
├── pages/
│ ├── Dashboard.tsx
│ ├── Patients.tsx
│ ├── Reception.tsx
│ └── Reports.tsx
├── index.css
└── main.tsx
در این ساختار، پوشه ui برای اجزای عمومی و پوشه layout برای اجزای ساختاری است. صفحه بیماران نباید مسئول ساخت دوباره منوی کناری باشد؛ این وظیفه بر عهده Layout است. چنین جداسازی‌ای زمانی ارزش خود را نشان می‌دهد که تعداد صفحات افزایش پیدا کند یا بخواهید ظاهر کل برنامه را تغییر دهید.
یک نمونه ساده برای Layout:
import { Outlet } from "react-router-dom";
import Sidebar from "./layout/Sidebar";
import Header from "./layout/Header";
export default function AppLayout() {
return (
); }
نکته فنی مهم، استفاده از min-w-0 و min-h-0 در چیدمان‌های Flex است. بدون این تنظیمات، فرزندان ممکن است حداقل اندازه ذاتی خود را حفظ کنند و باعث شوند جدول یا محتوای صفحه از محدوده مورد انتظار بیرون بزند. همچنین overflow-hidden روی پوسته اصلی و overflow-y-auto روی ناحیه محتوا کمک می‌کند اسکرول صفحه در جای درستی قرار بگیرد.
تعریف رنگ‌ها، فونت‌ها و طراحی یکپارچه
در یک رابط حرفه‌ای، رنگ‌ها نباید در هر کامپوننت به‌صورت تصادفی انتخاب شوند. بهتر است پالت مشخصی داشته باشید؛ مثلاً رنگ اصلی برای دکمه‌های مهم، رنگ خنثی برای پس‌زمینه، رنگ قرمز برای خطا و رنگ سبز برای وضعیت‌های موفق. در نرم‌افزارهای درمانی، این تفکیک باید به تشخیص سریع وضعیت‌ها کمک کند، نه اینکه صرفاً ظاهر جذابی ایجاد کند.
در Tailwind نسخه ۴ می‌توانید توکن‌های طراحی را در فایل CSS تعریف کنید:
@import "tailwindcss";
@theme {
--font-sans: "Vazirmatn", sans-serif;
--color-primary: #087f73;
--color-primary-dark: #05665d;
--color-primary-light: #b9f1e9;
--color-app-bg: #f5f7f6;
--color-app-text: #101716;
--color-app-muted: #6b7c77;
--color-danger: #c94b5a;
--color-warning: #b7791f;
}
پس از تعریف این متغیرها، می‌توانید از کلاس‌هایی مانند bg-primary، text-app-text و bg-app-bg استفاده کنید. به این ترتیب، اگر بعداً تصمیم بگیرید رنگ اصلی را تغییر دهید، به‌جای جست‌وجوی ده‌ها کد رنگ در فایل‌های مختلف، یک توکن مرکزی را اصلاح می‌کنید.
برای فونت فارسی نیز باید فایل‌های فونت را به‌درستی در پروژه قرار دهید و با @font-face معرفی کنید. صرف تعریف نام فونت در متغیرهای CSS، فونت را به پروژه اضافه نمی‌کند. برای مثال:
@font-face {
font-family: "Vazirmatn";
src: url("/fonts/Vazirmatn-Regular.woff2")
format("woff2");
font-weight: 400;
font-style: normal;
font-display: swap;
}
@font-face {
font-family: "Vazirmatn";
src: url("/fonts/Vazirmatn-Bold.woff2")
format("woff2");
font-weight: 700;
font-style: normal;
font-display: swap;
}
مسیر فایل‌ها باید با محل واقعی فونت‌ها هماهنگ باشد. اگر فونت را در پوشه عمومی Vite قرار داده‌اید، مسیر بالا می‌تواند مناسب باشد؛ اما اگر در پوشه دیگری قرار دارد، مسیر را اصلاح کنید.
ساخت کامپوننت‌های قابل استفاده مجدد
طراحی دکمه‌ها، ورودی‌ها و فرم‌ها
یکی از تفاوت‌های کد آزمایشی با یک پروژه حرفه‌ای، نحوه مدیریت اجزای تکراری است. اگر در پانزده صفحه از برنامه دکمه ثبت، ویرایش و حذف دارید، تعریف استایل هر دکمه به‌صورت مستقل انتخاب مناسبی نیست. بهتر است یک کامپوننت Button بسازید که نوع، اندازه، وضعیت غیرفعال و در صورت نیاز آیکون را دریافت کند. به این ترتیب، ظاهر و رفتار دکمه‌ها در کل برنامه یکسان می‌ماند و تغییرات بعدی ساده‌تر می‌شوند.
برای مثال، کامپوننت زیر چند نوع دکمه و سه اندازه را پشتیبانی می‌کند:
import type { ButtonHTMLAttributes } from "react"; type ButtonProps = ButtonHTMLAttributes & { variant?: "primary" | "secondary" | "danger"; size?: "sm" | "md" | "lg"; }; const variants = { primary: "bg-primary text-white hover:bg-primary-dark", secondary: "border border-slate-200 bg-white text-slate-700 hover:bg-slate-50", danger: "bg-danger text-white hover:opacity-90", }; const sizes = { sm: "px-3 py-1.5 text-xs", md: "px-4 py-2 text-sm", lg: "px-5 py-3 text-base", }; export default function Button({ variant = "primary", size = "md", className = "", type = "button", ...props }: ButtonProps) { return (); }
نکته‌ای که نباید نادیده بگیرید، مقدار پیش‌فرض type="button" است. دکمه‌ای که داخل فرم قرار می‌گیرد، در HTML ممکن است به‌صورت پیش‌فرض رفتار ارسال فرم داشته باشد؛ این رفتار برای دکمه لغو یا بازکردن پنجره انتخاب مناسب نیست. با تعیین نوع پیش‌فرض و استفاده از type="submit" فقط برای دکمه ارسال، رفتار فرم قابل پیش‌بینی‌تر می‌شود.
برای ورودی‌ها نیز بهتر است برچسب، پیام راهنما و خطا را در یک کامپوننت استاندارد قرار دهید. ورودی شماره ملی بیمار، شماره تلفن و نام خانوادگی می‌توانند ظاهر یکسانی داشته باشند، اما اعتبارسنجی آن‌ها باید بر اساس نوع داده انجام شود. استفاده از type="text" برای شماره ملی معمولاً بهتر از type="number" است، زیرا شماره ملی یک شناسه است، نه کمیتی که قرار باشد روی آن عملیات ریاضی انجام دهید؛ ضمن اینکه صفرهای ابتدای مقدار نباید حذف شوند.
ساخت جدول اطلاعات و صفحه‌بندی
جدول در برنامه‌های اداری و درمانی یکی از مهم‌ترین بخش‌های رابط کاربری است. فهرست بیماران ممکن است صدها یا هزاران رکورد داشته باشد، بنابراین نمایش تمام اطلاعات در یک جدول طولانی و بدون صفحه‌بندی تصمیم درستی نیست. همچنین اگر ستون‌ها عرض مشخص نداشته باشند یا محتوای متنی بسیار طولانی باشد، جدول می‌تواند چیدمان کل پنجره را خراب کند. طراحی مناسب باید امکان مرتب‌سازی، جست‌وجو، صفحه‌بندی و مشاهده وضعیت هر رکورد را فراهم کند.
یک ظرف ساده برای نمایش جدول می‌تواند به شکل زیر باشد:
type Patient = {
id: number;
firstName: string;
lastName: string;
nationalCode: string;
phoneNumber: string;
};
type Props = {
patients: Patient[];
};
export default function PatientTable({ patients }: Props) {
return (
{patients.map((patient) => ( ))}
نام |
نام خانوادگی |
کد ملی |
شماره تماس |
|---|---|---|---|
{patient.firstName} |
{patient.lastName} |
{patient.nationalCode} |
{patient.phoneNumber} |
); }
در این نمونه، overflow-x-auto اجازه می‌دهد جدول در پنجره‌های کوچک‌تر به‌صورت افقی پیمایش شود، بدون اینکه کل رابط کاربری از محدوده خارج شود. ویژگی min-w-[700px] نیز حداقل عرضی برای خوانایی ستون‌ها در نظر می‌گیرد. استفاده از key یکتا در ردیف‌های React ضروری است تا React بتواند تغییرات فهرست را به‌درستی مدیریت کند.
اما این جدول هنوز قابلیت مرتب‌سازی و صفحه‌بندی ندارد. برای پیاده‌سازی واقعی، بهتر است وضعیت صفحه جاری، تعداد کل رکوردها و تعداد رکوردهای هر صفحه را مشخص کنید. اگر داده‌ها از SQLite و بک‌اند Rust دریافت می‌شوند، صفحه‌بندی باید در کوئری پایگاه داده انجام شود، نه اینکه تمام رکوردها دریافت و سپس فقط بخشی از آن‌ها در رابط نمایش داده شود. در غیر این صورت، با افزایش حجم اطلاعات، مصرف حافظه و زمان پردازش افزایش می‌یابد.
طراحی واکنش‌گرا و بهینه‌سازی تجربه کاربری
مدیریت فضای پنجره و اسکرول
در طراحی سایت معمولاً درباره نمایش در موبایل و دسکتاپ صحبت می‌کنیم؛ اما در برنامه دسکتاپ نیز ابعاد پنجره همیشه ثابت نیست. ممکن است کاربر پنجره را کوچک کند، از نمایشگر دیگری استفاده کند یا برنامه را کنار یک نرم‌افزار دیگر قرار دهد. بنابراین، استفاده از اندازه‌های ثابت برای تمام بخش‌ها می‌تواند مشکلات جدی ایجاد کند. بهتر است از Flexbox، Grid، محدودیت‌های منطقی عرض و ارتفاع و قابلیت‌های واکنش‌گرای Tailwind استفاده کنید.
برای مثال، در یک صفحه داشبورد می‌توانید کارت‌های آماری را با Grid نمایش دهید:
تعداد بیماران
۱٬۲۴۰
نوبت‌های امروز
۴۸
در این نمونه، در عرض‌های کوچک کارت‌ها زیر یکدیگر قرار می‌گیرند، در عرض‌های متوسط دو ستون تشکیل می‌شود و در نمایشگرهای بزرگ چهار ستون در دسترس خواهد بود. البته نقاط شکست باید با حداقل اندازه پنجره و نیازهای واقعی برنامه هماهنگ شوند؛ صرفاً استفاده از تعداد زیاد کلاس‌های واکنش‌گرا نشانه طراحی بهتر نیست.
برای پنجره‌های دسکتاپ، مدیریت اسکرول به‌اندازه چیدمان اهمیت دارد. اگر سربرگ و منوی کناری ثابت هستند، بهتر است اسکرول اصلی را به ناحیه محتوا محدود کنید. همچنین برای جدول‌های بزرگ، اسکرول افقی داخل خود جدول معمولاً تجربه بهتری از اسکرول افقی کل برنامه ایجاد می‌کند. این جزئیات کوچک باعث می‌شوند کاربران در استفاده روزمره کمتر سردرگم شوند.
پشتیبانی از زبان فارسی و رابط راست‌چین
برای نرم‌افزاری که مخاطبان آن فارسی‌زبان هستند، راست‌چین‌کردن رابط فقط به معنی قرار دادن متن در سمت راست نیست. جهت فرم‌ها، ترتیب آیکون‌ها، نمایش شماره‌ها، چیدمان منو و رفتار ستون‌های جدول نیز باید بررسی شود. بهتر است جهت کلی سند را از ابتدا مشخص کنید:
این تنظیم باید در فایل HTML اصلی پروژه اعمال شود. سپس می‌توانید برای عناصر خاص، مانند شماره تلفن یا کد ملی، جهت متفاوتی تعیین کنید:
شماره تماس در این مثال، برچسب فارسی راست‌چین است و مقدار شماره تلفن از چپ به راست نمایش داده می‌شود. استفاده از inputMode="tel" نیز می‌تواند در دستگاه‌های دارای صفحه‌کلید مجازی، صفحه‌کلید مناسب‌تری پیشنهاد دهد؛ هرچند در یک برنامه دسکتاپ ویندوزی معمولاً صفحه‌کلید فیزیکی در دسترس است.
برای آیکون‌ها نیز باید جهت معنایی آن‌ها را در نظر بگیرید. آیکون فلش بازگشت، حرکت بعدی یا قبلی و دکمه‌های جابه‌جایی ممکن است در رابط راست‌چین به رفتار متفاوتی نیاز داشته باشند. در نهایت، تاریخ‌ها و اعداد را هم جداگانه بررسی کنید؛ جهت نمایش متن به‌تنهایی تضمین نمی‌کند که رشته‌های ترکیبی فارسی و انگلیسی همیشه به شکل دلخواه دیده شوند.
اتصال رابط کاربری به بک‌اند Rust
دریافت داده‌ها و مدیریت وضعیت
تا اینجا رابط کاربری را طراحی کرده‌ایم، اما در یک نرم‌افزار واقعی، اطلاعات نباید صرفاً داخل آرایه‌های ثابت در React نگهداری شوند. برای مثال، فهرست بیماران باید از پایگاه داده SQLite دریافت شود و عملیات ثبت یا ویرایش نیز به لایه داده متصل باشد. در Tauri، می‌توانید یک دستور Rust تعریف کنید و آن را از فرانت‌اند با API مربوط به invoke فراخوانی کنید.
Tauri
+1
فرض کنیم دستور get_patients_list در بک‌اند Rust تعریف شده و فهرست بیماران را برمی‌گرداند. در فرانت‌اند می‌توانید از الگوی زیر استفاده کنید:
import { useEffect, useState } from "react";
import { invoke } from "@tauri-apps/api/core";
type Patient = {
id: number;
firstName: string;
lastName: string;
nationalCode: string;
};
export default function Patients() {
const [patients, setPatients] = useState([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
useEffect(() => {
let cancelled = false;
async function loadPatients() {
try {
setLoading(true);
setError(null);
const result = await invoke(
"get_patients_list"
);
if (!cancelled) {
setPatients(result);
}
} catch (err) {
if (!cancelled) {
setError(String(err));
}
} finally {
if (!cancelled) {
setLoading(false);
}
}
}
void loadPatients();
return () => {
cancelled = true;
};
}, []);
if (loading) {
return
در حال دریافت اطلاعات...
; } if (error) { return (
دریافت اطلاعات با خطا مواجه شد: {error}
); } return (
فهرست بیماران
{patients.map((patient) => (
{patient.firstName} {patient.lastName} ))}); }
این نمونه فرض می‌کند دستور Rust یک آرایه از بیماران برمی‌گرداند. اگر دستور واقعی شما خروجی صفحه‌بندی‌شده‌ای مانند { data, total, page, perPage, totalPages } دارد، نوع TypeScript و نحوه دسترسی به داده‌ها باید متناسب با همان ساختار تعریف شود. همچنین نام فیلدهای Rust و TypeScript باید با شیوه سریال‌سازی انتخاب‌شده هماهنگ باشند.
استفاده از cancelled در این مثال از به‌روزرسانی وضعیت کامپوننت پس از پاک‌سازی Effect جلوگیری می‌کند، اما درخواست Rust را متوقف نمی‌کند. این تمایز مهم است: لغو به‌روزرسانی رابط کاربری با لغو واقعی عملیات بک‌اند یکسان نیست. اگر چند درخواست هم‌زمان دارید، باید برای جلوگیری از نمایش پاسخ‌های قدیمی، ترتیب و اعتبار نتایج را نیز مدیریت کنید.
در نهایت، برای استفاده از این دستور باید آن را در برنامه Tauri ثبت کرده باشید. همچنین، بهتر است دسترسی به پایگاه داده، اعتبارسنجی ورودی‌ها و مدیریت خطاها در لایه Rust انجام شود؛ Tailwind CSS صرفاً ظاهر رابط را کنترل می‌کند و مسئول امنیت یا صحت عملیات داده نیست.
رفع خطاهای رایج و بهینه‌سازی عملکرد
هنگام استفاده از Tailwind CSS در Tauri، بسیاری از مشکلات از خود فریم‌ورک ناشی نمی‌شوند، بلکه به پیکربندی، نحوه تولید CSS یا ساختار کامپوننت‌ها مربوط هستند. شناخت این موارد کمک می‌کند به‌جای تغییر تصادفی کدها، علت اصلی مشکل را پیدا کنید.
|
مشکل |
علت احتمالی |
راهکار |
|---|---|---|
|
کلاس‌های Tailwind اعمال نمی‌شوند |
فایل CSS وارد نشده یا افزونه Vite فعال نیست |
تنظیمات |
|
ظاهر نسخه توسعه با خروجی نهایی متفاوت است |
کلاس‌ها در منابع شناسایی نشده‌اند یا فایل دیگری در خروجی وجود ندارد |
خروجی Build و مسیر فایل‌های CSS را بررسی کنید |
|
جدول از پنجره بیرون می‌زند |
عرض محتوا کنترل نشده است |
از |
|
منو و محتوای صفحه اسکرول نامناسب دارند |
ارتفاع Flexbox یا محل اسکرول درست تعریف نشده است |
|
|
فونت فارسی نمایش داده نمی‌شود |
مسیر فونت یا تعریف |
فایل فونت و مسیر نهایی آن را بررسی کنید |
|
رابط با تغییر اندازه پنجره به‌هم می‌ریزد |
استفاده بیش از حد از اندازه‌های ثابت |
از Flexbox، Grid و اندازه‌های منعطف استفاده کنید |
جلوگیری از مشکلات کلاس‌های پویا
یکی از خطاهای مهم در Tailwind این است که کلاس را با رشته‌های پویا می‌سازید و انتظار دارید ابزار ساخت آن را همیشه تشخیص دهد. برای مثال، کد زیر انتخاب مناسبی نیست:
const className = `bg-${color}-500`;
اگر مقدار color در زمان اجرا تغییر کند، ممکن است کلاس تولیدشده در CSS نهایی وجود نداشته باشد. راه بهتر این است که کلاس‌های مجاز را به‌صورت کامل و صریح تعریف کنید:
const statusClasses = {
success: "bg-emerald-100 text-emerald-700",
warning: "bg-amber-100 text-amber-700",
danger: "bg-rose-100 text-rose-700",
} as const;
سپس بر اساس وضعیت، یکی از مقادیر این شیء را به کامپوننت بدهید. این روش علاوه بر سازگاری بهتر با فرایند تولید CSS، کنترل وضعیت‌های مجاز را نیز ساده‌تر می‌کند. در پروژه‌های بزرگ، این الگو برای رنگ وضعیت نوبت‌ها، پیام‌های خطا و نشانگرهای وضعیت بیماران بسیار کاربردی است.
بهینه‌سازی عملکرد رابط
Tailwind به‌خودی‌خود جایگزین بهینه‌سازی React یا پایگاه داده نیست. اگر در هر تغییر فیلتر، هزاران رکورد از SQLite دریافت شوند یا یک کامپوننت سنگین بارها بدون نیاز بازپردازش شود، صرف استفاده از کلاس‌های کاربردی مشکل را حل نمی‌کند. برای چنین مواردی باید صفحه‌بندی سمت پایگاه داده، مدیریت مناسب وضعیت، جلوگیری از درخواست‌های غیرضروری و در صورت لزوم مجازی‌سازی ردیف‌های جدول را بررسی کنید.
همچنین، در زمان توسعه از دستورات متناسب با پروژه استفاده کنید و برای خروجی نهایی فرایند Build را اجرا کنید. در پروژه Tauri، فایل‌های تولیدشده توسط Vite باید با تنظیم frontendDist در پیکربندی Tauri هماهنگ باشند؛ در غیر این صورت ممکن است برنامه در حالت توسعه درست اجرا شود، اما نسخه بسته‌بندی‌شده نتواند دارایی‌های فرانت‌اند را پیدا کند.
Tauri
+1
سوالات متداول
۱. آیا می‌توان از Tailwind CSS نسخه ۴ در Tauri 2 استفاده کرد؟
بله. Tailwind CSS نسخه ۴ با پروژه‌های مبتنی بر Vite قابل استفاده است. روش پیشنهادی، نصب tailwindcss و @tailwindcss/vite، فعال‌کردن افزونه در فایل vite.config.ts و واردکردن tailwindcss در فایل CSS اصلی است.
۲. آیا برای طراحی رابط کاربری Tauri باید CSS بلد باشیم؟
بله، آشنایی با اصول CSS ضروری است. Tailwind بسیاری از ویژگی‌های رایج را از طریق کلاس‌های آماده در اختیارتان قرار می‌دهد، اما برای درک Flexbox، Grid، مدیریت اسکرول، جهت راست‌چین و رفتار واکنش‌گرا همچنان به دانش CSS نیاز دارید.
۳. آیا Tailwind CSS باعث افزایش حجم فایل اجرایی Tauri می‌شود؟
Tailwind در زمان ساخت، CSS موردنیاز را تولید می‌کند و به‌طور معمول تمام کتابخانه جاوااسکریپتی جداگانه‌ای را برای اجرای کلاس‌ها به برنامه اضافه نمی‌کند. حجم نهایی به CSS تولیدشده، تصاویر، فونت‌ها، کدهای فرانت‌اند و سایر دارایی‌های برنامه وابسته است. بنابراین، نمی‌توان بدون بررسی خروجی Build درباره حجم نهایی فایل اجرایی عدد دقیقی اعلام کرد.
۴. برای ساخت نرم‌افزار فارسی با Tauri، چگونه رابط را راست‌چین کنیم؟
جهت کلی سند را با lang="fa" و dir="rtl" مشخص کنید، فونت فارسی مناسب را بارگذاری کنید و برای مقادیری مانند شماره تلفن و کد ملی، در صورت نیاز جهت مستقل تعیین کنید. سپس منوها، آیکون‌های جهت‌دار، فرم‌ها و جدول‌ها را در عمل بررسی کنید تا ترتیب اجزا با انتظار کاربران فارسی‌زبان هماهنگ باشد.
۵. آیا می‌توان با Tailwind CSS یک سیستم طراحی مشترک برای تمام صفحات ساخت؟
بله. تعریف توکن‌های رنگ و فونت در @theme، ساخت کامپوننت‌هایی مانند Button، Input و DataTable و استفاده از Layout مشترک، پایه مناسبی برای سیستم طراحی فراهم می‌کند. در پروژه‌های بزرگ‌تر می‌توانید این ساختار را با مستندات کامپوننت‌ها، قواعد نام‌گذاری و آزمون‌های رابط کاربری کامل‌تر کنید.
