Server Actions ב-Next.js 14 ומעלה מאפשרים לכם להריץ קוד על השרת ישירות מתוך קומפוננטות React, בין אם מדובר בקומפוננטות לקוח או שרת. במקום להגדיר API route ואז לקרוא לו מתוך הקומפוננטה, אתם יכולים פשוט לכתוב את הלוגיקה בתוך הקומפוננטה, ו-Next.js תוודא שהקוד ירוץ על השרת.
תארו לעצמכם את התרחיש הבא: משתמשי האפליקציה שלכם רוצים ליצור פוסט חדש (ממש כמו בפייסבוק), וברגע שהם לוחצים על "פרסם", אתם רוצים לשלוח את הנתונים האלו מן הסתם לשרת וכמובן לשמור את הנתונים האלה במסד הנתונים. בדרך המסורתית הייתם צריכים לבצע כמה שלבים:
ליצור API route: בתהליך המסורתי, הייתם מגדירים endpoint בשרת (כמו /api/create-post) שיקבל את הנתונים מהטופס, ויטפל בלוגיקה של שמירת הנתונים במסד הנתונים. זה דורש הגדרת קובץ חדש, כתיבת לוגיקה לקבלת הבקשה, ולבסוף שמירת הנתונים (ואולי עוד כמה דברים בדרך).
לכתוב בקשת fetch: בתוך הקומפוננטה שלכם בצד הלקוח, הייתם צריכים לכתוב בקשת fetch או להשתמש ב-Axios (או כל כלי אחר) כדי לשלוח את הנתונים ל-endpoint שיצרתם.
עם Server Actions, אתם יכולים לדלג על הצורך בהגדרת API route ובשליחת בקשות fetch. במקום זאת, אתם מגדירים פונקציה בצד השרת (Server Action) שתטפל בשמירת הנתונים. את הפונקציה הזו תוכלו להגדיר בקובץ נפרד ולהשתמש בה בתוך קומפוננטות צד לקוח או צד שרת. הנה דוגמה:
// src/serverActions/post/createPost.ts
'use server'
export async function createPost(postData) {
// Simulate a server-side database interaction for post creation
await collection.insertOne(postData);
return { message: 'Post created' };
}
// src/app/SomePage.tsx
'use client'
import { useState } from 'react';
export default function MyComponent() {
const [message, setMessage] = useState('');
const handleSubmit = async (event) => {
event.preventDefault();
const { title, content } = event.target;
const result = await createPost({
title: title.value,
content: content.value
});
setMessage(result.message);
};
return (
<form onSubmit={handleSubmit}>
<input name="title" placeholder="Title" />
<textarea name="content" placeholder="Content" />
<button type="submit">Submit</button>
{message && <p>{message}</p>}
</form>
);
}
אנו מגדירים Server Actions באמצעות ה-Directive 'use server': זה מסמן ל-Next.js שהפונקציה createPost צריכה לרוץ על השרת ולא בדפדפן.
כשמדובר ב-Server Actions, חשוב לזכור שהקוד רץ בצד השרת, ולכן יש כמה עקרונות שחשוב לקחת בחשבון. ראשית, שליפת נתונים ברינדור ראשוני: אם הקומפוננטה דורשת נתונים עם טעינתה הראשונה, כדאי לבצע את השליפה הזו בצד השרת, לפני הרינדור, ולהעביר את הנתונים כ-props ל-client component.
export default async function PostManagement() {
const response = await fetch('http://localhost:3001/posts');
const data = await response.json() as IPost[];
return (
<div>
<ClientComponent data={data} />
</div>
);
}
שנית, אפשר לשלב Server Actions עם events כמו onSubmit או onClick. כך הקומפוננטה יכולה להפעיל את ה-Server Action בהתאם לפעולות המשתמש, ולהגיב לאינטראקציות שונות.
Server Actions מאפשרים לכם לכתוב קוד שרץ על השרת ישירות מתוך הקומפוננטות שלכם. לדוגמה, אם אתם רוצים לשמור נתונים של פוסט חדש במסד הנתונים לאחר שמשתמש לוחץ על כפתור "פרסם", אתם יכולים לכתוב את כל הלוגיקה הזו בתוך הקומפוננטה עצמה, בלי צורך ליצור API route נפרד. זה הופך את העבודה למהירה ופשוטה יותר.
כשמשתמשים ב-Server Actions, אתם מפחיתים את הצורך להריץ קוד JavaScript בצד הלקוח (כלומר בדפדפן). בדרך כלל, כשאתם רוצים לשלוח נתונים מהלקוח לשרת, כמו במקרה של טופס שבו משתמש שולח פוסט חדש, אתם משתמשים בבקשת fetch שנעשית דרך JavaScript.
השימוש ב-Server Actions מבטל את הצורך הזה, כי הקוד שרץ על השרת מתבצע ישירות מתוך הקומפוננטה ב-React. כתוצאה מכך, הדפדפן צריך להריץ פחות קוד, וזה יכול להוביל לטעינה מהירה יותר של הדפים ולשיפור בביצועים של האתר.
במצבים שבהם JavaScript לא נטען במלואו או כבוי בצד הלקוח, אפליקציות שמשתמשות ב-Server Actions יכולות להמשיך לתפקד בצורה תקינה. למשל, אם משתמש מנסה לשלוח טופס וה-JavaScript בדפדפן שלו לא פועל, השרת עדיין יכול לטפל בפעולה הזו דרך ה-Server Actions, כי היא מתבצעת על השרת ולא בדפדפן. זה הופך את האפליקציה לעמידה יותר ומבטיח שהיא תפעל בצורה טובה גם בתנאים פחות אופטימליים.
Server Actions מתאימים יותר לפעולות פשוטות כמו שמירת נתונים או שליחה לשרת. אם אתם צריכים לנהל הרבה לוגיקה בצד הלקוח, ייתכן שהשיטה המסורתית של API routes תהיה מתאימה יותר.
בפרויקטים גדולים, השימוש ב-Server Actions יכול לטשטש את הגבולות בין הקוד שרץ על השרת לקוד שרץ על הלקוח, מה שעלול להקשות על ניהול הקוד בצורה ברורה ומסודרת.
אני אשתמש ב-Server Actions בעיקר למשימות פשוטות עם מינימום לוגיקה, כמו הוספת To-Do פשוט לרשימה. עם זאת, אפילו במקרים כאלה אני אעדיף להשתמש בשיטה המסורתית ולהפריד בין השרת ללקוח וליצור endpoint ייעודי משלו. הגישה הזו מאפשרת לי לשמור על מבנה קוד ברור ומאורגן וכמובן על הפרדה מוחלטת בין הלוגיקה בצד השרת לצדו של הלקוח.