¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
ToCode
Ir al canal en Telegram
1 420
Suscriptores
Sin datos24 horas
+27 días
-230 días
Archivo de publicaciones
1 420
פוסט נוסטלגי: הצגת XML עם XSLT בדפדפן
לאחרונה נשמעים קולות שקוראים להפסיק לתמוך בהצגת XML באמצעות XSLT בדפדפנים וזו הזדמנות טובה להיזכר בסטנדרט שאף אחד לא משתמש בו אבל עדיין עובד בכל הדפדפנים והיה נשמע כמו רעיון טוב לפני בערך 20 שנה.
באזור שנת 2000 האינטרנט הגיע למיצוי. פיירפוקס ייוולד רק ב 2004 וכרום עוד 4 שנים אחריו ב 2008. דפדפן האינטרנט שכולם השתמשו בו נקרא Internet Explorer. גירסה 5 שלו יצאה ב 1999 וב 2001 גירסה 6 שנחשבה אלמותית. באותו הזמן מפתחים ראו באינטרנט הזדמנות ליצירת אפליקציות מבוזרות ולחבר בין מערכות שונות, בלי קשר לדפדפן. כלומר כל מערכת תשלח ותקבל קבצי מידע מסוג XML ובאמצעותם תחובר למערכות אחרות, כך שלדוגמה מערכת להזמנת טיסות תכיל שרת שישלח XML-ים עם המידע לתוכנת צד לקוח שתדע להציג את ה XML-ים האלה. וכן היתה טכנולוגיה בשם Java Applets שאפשרה לכתוב קוד Java ולהפיץ אותו באמצעות דפדפן אינטרנט.
בתוך העולם הזה היה נשמע רק הגיוני לאפשר לדפדפנים להציג קבצי XML, אך מאחר ודפדפנים ידעו להציג רק קבצי HTML ו XML הוא פורמט כללי שבו אין מגבלה על שמות התגים עלה הצורך למפות בין תגיות XML לתגיות HTML. בדוגמה של אתר הזמנת הטיסות אם כבר יש לך מערכת להזמנת טיסות שמוציאה קבצי XML לתוכנות ול Applets שרצים אצל הלקוחות, תוכל להוסיף קובץ מיפוי שיראה לדפדפן איך לעבור מקובץ נתוני הטיסות שלך ל HTML וכך גם הדפדפן יוכל להציג את המידע לפחות לקריאה.
ואיך זה נראה? האמת שדי פשוט. ניקח קובץ XML לדוגמה מאתר של ספריה שמכיל רשימה של 3 ספרים:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<librairie>
<livre>
<titre>Le Petit Prince</titre>
<auteur>Antoine de Saint-Exupéry</auteur>
<prix>8.50</prix>
</livre>
<livre>
<titre>1984</titre>
<auteur>George Orwell</auteur>
<prix>9.90</prix>
</livre>
<livre>
<titre>Harry Potter à l'école des sorciers</titre>
<auteur>J.K. Rowling</auteur>
<prix>12.00</prix>
</livre>
</librairie>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- Le résultat sera du HTML -->
<xsl:output method="html" encoding="UTF-8" indent="yes"/>
<!-- Modèle de transformation principal -->
<xsl:template match="/">
<html>
<head>
<title>Liste des livres</title>
<style>
body { font-family: Arial, sans-serif; margin: 40px; }
table { border-collapse: collapse; width: 60%; }
th, td { border: 1px solid #999; padding: 8px; text-align: left; }
th { background-color: #f2f2f2; }
</style>
</head>
<body>
<h2>Ma librairie</h2>
<table>
<tr>
<th>Titre</th>
<th>Auteur</th>
<th>Prix (€)</th>
</tr>
<!-- Boucle sur chaque livre -->
<xsl:for-each select="librairie/livre">
<tr>
<td><xsl:value-of select="titre"/></td>
<td><xsl:value-of select="auteur"/></td>
<td><xsl:value-of select="prix"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
npx local-server
1 420
הכלל הראשון של סוכני קידוד
מישהו פרסם רשימה של 10 כללים של סוכני קידוד. כבר הראשון שבהם מעורר מחלוקת:
> Your Agent is not going to have a better idea about what you want to achieve than you do. In other words, if you don’t have a clear idea about what you want, your agent won’t either.
והבעיה היא המילה what במשפט. כמפתחים חלק חשוב מהעבודה שלנו הוא לתרגם דרישות לקוח בשפה טבעית לשפת מכונה ואותו תרגום כולל קבלת החלטות וגם ניחושים לגבי העתיד. אם הלקוח שלי זיהה שטבלה מסוימת לא מציגה את הנתונים כמו שהוא רוצה לראות אותם אני כמפתח יכול לבחור אם אני רוצה לשנות רק את התצוגה באותה טבלה או לבנות תשתית לבחירת אופן התצוגה שתעזור לי גם לתקן את הטבלה וגם אולי לתקן מקומות אחרים בעתיד (אם הלקוח יבקש אותם) או לשנות את מבנה בסיס הנתונים. לכל אופציה יתרונות וחסרונות שתלויים בכל הסיטואציה של המערכת והתוכניות לעתיד. ברור שלסוכן קידוד אין את הכלים להחליט איזה משלושת האופציות היא הכי טובה לטיפול בדרישה זו.
מה שסוכן קידוד כן יודע לעשות ומאוד טוב זה לייצר רעיונות. אז באותה סיטואציה של דרישת לקוח לתקן טבלה אני יכול להיעזר בסוכן קידוד כדי לקבל מפה רחבה של האפשרויות שלי - מפה שלעולם לא הייתי מקבל מ Junior Engineer בצוות. פרומפטים לדוגמה:
> לקוח ביקש לשנות את מבנה הטבלה. אני מתלבט אם צריך לשנות רק את התצוגה או גם את הנתונים בבסיס הנתונים. הצג לי את היתרונות והחסרונות של כל גישה.
> לקוח ביקש לשנות את מבנה הטבלה ואני חושד שהוא יבקש שינויים דומים בעתיד. מפה במערכת את כל המקומות שעשויים להרוויח מיצירת תשתית גנרית לבחירת אופן תצוגה של נתונים אלה.
> לקוח ביקש לשנות את מבנה הטבלה. סרוק את כל ה Issues מהשנה האחרונה ושער מה יהיו השינויים הבאים שהלקוח יבקש על טבלה זו. נמק באמצעות דוגמאות מ Issues קודמים.
> לקוח ביקש לשנות את מבנה הטבלה. הצע 5 דרכים שונות לביצוע השינוי, החל משינוי נקודתי בתצוגה ועד שינוי גורף במבנה בסיס הנתונים.
> אני רוצה לשנות את מבנה הטבלה דרך שינוי התצוגה. למה חשוב לשים לב כשכותבים את השאילתות מבחינת ביצועים ושימוש בזיכרון?
ההצעה להתיחס לסוכן קידוד בתור Junior Engineer נכונה לפרויקטים מסוימים בעיקר פרויקטים חדשים. בפרויקטים וותיקים כשהקידוד הוא לא צוואר הבקבוק אנחנו מעדיפים להשתמש ב AI כמכונת רעיונות שמחזקת ומגבירה את החשיבה. כן הוא בהחלט יודע יותר ממני ואני שמח לסחוט כל טוקן של אינפורמציה לפני שאני ניגש לשבור את הקוד.
1 420
אבל מי יבדוק את זה?
דיברתי עם לקוח אתמול ועל הדרך גילינו באג במערכת שלהם. בלי להכיר את הקוד שמחתי לעזור "אל תדאגו אני יודע לדבר עם קופיילוט" אמרתי ותוך שעתיים היתה להם גירסה מתוקנת רצה על מכונת בדיקה. אבל כשצלצלתי בשמחה לספר להם על ההישג קיבלתי מקלחת קרה: "אתה יודע כמה פיצ'רים של AI כבר יש לנו מחכים לבדיקה?", "מי יודע איזה בעיות זה הכניס" ו"זה לא תיקון שאפשר פשוט לדחוף ללקוחות ולראות מה יקרה".
הנה עוד טייק שכתב סאם סאפרון באותו נושא:
> On one side there is a contributor who spent a few minutes fiddling with AI prompts, on the other side you have an engineer that needs to spend many hours or even days deciphering alien intelligence.
האם אנחנו סתם שמרנים או שיש פה נקודה? למה אנחנו דורשים שבן אדם יקרא ויבין את הקוד לפני שנוכל לאשר אותו למערכת? והאם אי פעם זה הולך להשתנות?
נתחיל בהווה - כל עוד AI הוזה, טועה ומניח הנחות שגויות, גם אם זה "רק" בחלק קטן מהריצה, אנחנו צריכים מוח אנושי שיוודא שמיזוג של הפיצ'ר לא שובר כלום. זה המצב כרגע בכל המודלים שאנחנו מכירים. לדעתי זה גם יהיה המצב בעתיד הנראה לעין. לכן הצעד הבא הוא להבין איך לארגן את קבוצות הפיתוח כך שיהיה לנו יותר קל להבין קוד של AI. כמה טיפים בנושא הזה:
1. החלטה מהירה אם לזרוק או לשמור - כשקוראים קוד של בן אדם אתם רוצים לתת לו ליהנות מהספק, אנחנו מניחים שהיתה מחשבה מאחורי הדברים ושווה להתאמץ כדי להבין אותה. ב AI זה לא המצב. אם הסתכלתי 5-10 דקות על קוד AI והקוד לא קוהרנטי מספיק, לא מספר את הסיפור הנכון, אפשר לזרוק אותו ולתת ל AI לייצר חדש.
2. התמקצעות והבנת הגורמים שמשפיעים על הקוד ש AI מייצר. אני רוצה ש AI יכתוב קוד שאני יכול להבין מהר. אם זה לא המצב אני צריך להתאים את מבני הקבצים, ארכיטקטורה, קבצי פרומפט ואפילו שמות של קלאסים ופונקציות כדי שדברים יתחברו.
3. אנחנו צריכים בדיקות, סביבות בדיקה, וכלים שמאפשרים לנו לראות מה קורה במערכת כשאנחנו מריצים ניסוי ולהבין מהר מה עובד ומה נשבר.
4. והכי חשוב רמה מקצועית. קוד ש AI מייצר תמיד מבוסס על רעיונות שהוא למד מהתעשייה, מספרים, מפוסטים ומקוד של אחרים. חשוב לראות מאיפה זה בא ולהבין כמה שיותר מהר אם זה הכיוון שמתאים לפרויקט שלי.
5. יכולת מיזוג בקבוצת בקרה וגידור הסיכון - אם AI כותב מיגרציה ל DB אני רוצה לתת ל-5 מפתחים לקרוא אותה לפני שאני מריץ את ה SQL. אבל אם AI משנה משהו בקוד UI אני שמח לדחוף את השינוי לקבוצת משתמשים קטנה ובהדרגה להרחיב את קבוצת הבדיקה שלי עד שזה יגיע לכולם. אם AI שולח PR שמשפיע על עשרות קבצים אני מעדיף שהארכיטקט הראשי יקרא את זה לפני שאני מוכן לשלב את השינוי, אבל בעדכון מימוש של פונקציה אחת אני מוכן לקחת סיכון יותר גדול. לא כל הפיצ'רים זהים ולכן גם האנרגיה שאני משקיע בקריאת קוד של כל פיצ'ר יכולה להיות שונה.
1 420
למה AI לא מצליח לבנות מוצרים
גיטהאב הכניסו תיבת קופיילוט במסך יצירת הריפו שלהם אז כמובן שהייתי חייב לנסות. זה עובד די טוב. זה הפרומפט שכתבתי לו:
create a twitter clone using python and django. Use only memory no persistent storage. support actions: login tweet follow / unfollow retweet public feed with latest tweets Use only HTML/CSS/JavaScript not frontend frameworkוזה הריפו שנוצר: https://github.com/ynonp/copilot-twitter-clone זה לא רע! מתכנת אנושי שהיה מקבל פרומפט כזה ומצליח לייצר כזה ריפו היה מתקבל לעבודה בקלות בהרבה חברות. אבל זה לא מוצר. מאפיין מרכזי של קוד הוא המחשבה שהושקעה בו: לאן המערכת הולכת? מי הולך להמשיך לעבוד על הקוד הזה? מה לא מופיע בפרומפט? מה יקרה אם? ואיך? קוד הוא קודם כל מערכת של אילוצים לגבי שינויים עתידיים, כל שורת קוד מכניסה לעולם תפיסת עולם ומשפיעה על מה אפשר או אי אפשר יהיה לעשות בהמשך. ו AI? הוא כל עוד מנגנון קבלת ההחלטות של ה AI הוא הסתברותי אין לו סיכוי לקבל את ההחלטות הנכונות בזמן הבנייה. הסטטיסטיקה לרעתו. ככל ש GenAI כותב את שורות הקוד יותר מהר כך אנחנו מבינים בצורה יותר ברורה שמהירות הקלדה היא לא הסיפור כאן. המפתח להנדסת תוכנה - אם אני כותב X אז בעתיד יהיה יותר קל לבנות את Z ויותר קשה לבנות את Y.
1 420
פרויקט AI חדש בקוד פתוח לתרגול שפות
מוזיקה היא דרך מצוינת ללמוד מילים חדשות בשפה זרה ולתרגל את המילים כי כשיש שיר טוב אנחנו שומעים אותו שוב ושוב. לנגלטס הוא הניסיון שלי לעשות סדר בתהליך הזה ולבנות מערכת לימוד שפה מסודרת משירים ביוטיוב. מה שהפרויקט יודע לעשות כבר היום:
1. מדביקים קישור לשיר ביוטיוב.
2. המערכת מפעילה AI כדי להוציא את המילים של השיר, לתרגם את המילים והביטויים וליצור תרגילי אוצר מילים מהתוכן.
3. דרך הממשק אפשר להקשיב לשיר בחלקים וכל פעם לתרגל חלק אחר.
אפשר לראות כאן דוגמה לשיר בערבית עם תרגום לאנגלית
https://langlets.app/courses/BsvhDWS5voU
ואחד בספרדית עם תרגום לאנגלית
https://langlets.app/courses/5R0TtX-gVHA
אם תרשמו לאתר תוכלו גם להדביק קישורים שלכם ולפעמים זה עובד.
מה הלאה
הפרויקט ממש בתחילת הדרך ויש עדיין המון דברים חסרים, אלה הדברים המרכזיים שאני רוצה להוסיף:
1. מסך "סטטוס יצירה" שמראה בצורה יפה את שיעור השפה שנוצר אחרי שמדביקים לינק (כרגע זה אסינכרוני ופשוט שולחים מייל כשהשיעור מוכן).
2. אפשרות לעריכה של התכנים שה AI יצר כדי לתקן או לשפר.
3. תרגולי שפה טובים ויצירתיים יותר (זה החלק הכי קשה לדעתי כי צריך להבין איך יהיה הכי כיף ללמוד ולתרגל שירים בשפה זרה).
4. דרך קלה לשתף שיעורים שיצרתי עם חברים.
5. אפליקציה לאייפון ואנדרואיד.
הפרויקט כולל המון עבודה עם AI וכבר לימד אותי הרבה על כתיבת פרומפטים, עבודה עם מודלים, מה AI יכול ולא יכול לעשות. כמו שכתבתי בפתיחה אם אתם יודעים לכתוב קוד, חושבים שהרעיון מדליק ורוצים לעזור לקדם אותו כתבו לי הודעה ואשמח להכניס אתכם לעניינים.
את קוד הפרויקט המלא תוכלו למצוא בגיטהאב שלו בקישור הזה:
https://github.com/ynonp/langlets-rails
1 420
אלמנט Activity ב React
אז React 19.2 הוסיפו אלמנט חדש שהרבה אנשים אוהבים בשם Activity. האם באמת צריך אותו? בואו נראה מה הוא עושה ואתן לכם להחליט עד סוף הפוסט.
אלמנט Activity עושה שני דברים, הראשון הוא הגדרת כלל העיצוב display: none לכל הילדים שלו כדי שהם עדיין יישארו בחיים אבל לא יופיעו על המסך. בממשקי טאבים מנגנון כזה יכול לעבוד טוב יותר ממחיקה מוחלטת של האלמנט כי כשרק משנים את ה display האלמנט עדיין שומר על ה state שלו וכל המידע ב DOM נשמר, אז אם יש לנו טופס באחד הטאבים ועוברים לטאב אחר וחוזרים הטופס עדיין ישמור על הערכים שנכתבו בו. נשים לב שגם לפני ריאקט 19.2 בנינו מנגנונים כאלה ופשוט הגדרנו לבד את כלל העיצוב display: none כשמשתמשים ניווטו בין טאבים.
הכח השני של Activity, והוא הדבר החדש שבגללו נכנסה קומפוננטה חדשה לריאקט הוא מחיקה של האפקטים והרצת פונקציות הניקוי של כל האפקטים וה Cleanup Refs. מצד אחד מנגנון זה עוזר אם יש לנו בתוך עץ הקומפוננטות של אחד הטאבים אפקטים שאין בהם צורך ביציאה מהטאב - לדוגמה אולי יש אלמנט שמשתמש במצלמה אז הגיוני לסגור את המצלמה כשעוברים טאב. בדוגמאות בתיעוד הם מדברים על נגן וידאו שכדאי לעצור לפני שיוצאים מהטאב. מצד שני אם האפקט שלכם מקשיב לאירועים מ Web Socket ומעדכן את ה UI אז כיבוי האפקט מפסיק את ההאזנה לאירועים וכך כשנחזור לטאב נצטרך לבצע עדכון יזום.
הנה דוגמה קטנה ל Activity בפעולה עם כמה הודעות debug כדי להבין איך זה עובד. אפשר להדביק אותה בכל יישום next 16:
'use client';
import { useState, useRef, useEffect, Activity } from "react";
function refChanged(el: any) {
console.log(\set ref\);
return () => {
console.log(\unset ref\)
}
}
function ActivityDemo() {
useEffect(() => {
console.log(\start effect\)
return () => {
console.log(\stop effect\)
}
}, [])
return (
<p ref={refChanged}>hello world</p>
)
}
export default function Home() {
const [visible, setVisible] = useState(true);
return (
<div>
<input type="checkbox" checked={visible} onChange={() => setVisible(v => !v)} />
<Activity mode={visible ? "visible" : "hidden"}>
<ActivityDemo />
</Activity>
</div>
);
}
1 420
קומיט בלי פוש (או - מתי ליצור את הענף)
הרבה מקומות עובדים עם גיט בשיטת עבודה דומה. בשביל להתחיל לעבוד על פיצ'ר יוצרים ענף, עושים קומיטים לאותו ענף, כשהפיצ'ר מוכן שולחים PR ובסוף אחרי המיזוג מוחקים את הענף. אני מבין למה זו גישה פופולרית:
1. שקיפות - כולם רואים את הענפים והעבודה של כולם.
2. גיבוי - אפשר לעשות push אחרי כל קומיט וכך הנתונים מגובים לשרת.
3. שיתוף פעולה - אני יכול במהלך העבודה לבקש עזרה מחבר או חברה, הם ימשכו את הענף שלי ישימו תיקון וידחפו.
יצירת ענף בתחילת העבודה על פיצ'ר עוזרת לשמור על סדר עבודה ומועילה במיוחד כשאנחנו רק מתחילים לעבוד עם גיט.
אבל זו רק דרך אחת לעבוד. בחיים מותר לגוון, במיוחד אם אתם קצת יותר מיומנים עם גיט. לדוגמה אם אני לא צריך לשתף את העבודה ורק חוקר רעיון, אני יכול לחכות עם יצירת הענף ועם ה push. אני מקודד על המכונה שלי, עדיין עושה קומיטים רגיל בכל צעד ואחרי שהפיצ'ר עובד אני מפעיל rebase כדי למחוק חלק מהקומיטים ולשנות הודעות של אחרים ורק אז יוצר את הענף ודוחף. בצורה כזאת כל האחרים בצוות רואים היסטוריה יותר ברורה של קומיטים. כל עוד לא דחפתי הרבה יותר קל לשנות או לזרוק קומיטים בלי לדאוג שאולי מישהו כבר משך את הקומיטים האלה.
דרך אפילו יותר טובה היא ליצור את הענף אבל לחכות עם הדחיפה שלו ושל הקומיטים. כשדוחפים ענף פעם ראשונה גיט מתלונן ודורש שניצור את הענף בצורה מפורשת בשרת:
fatal: The current branch test has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin test
To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.
1 420
איך לזוז יותר לאט
שלוש רמות של לימוד מחומר כתוב או AI:
1. השלמה אוטומטית - זה כשאני מבקש מה AI לכתוב את הקוד בשבילי ישר בתוך ה IDE ולהסביר מה הוא כתב, או כשאני מתחיל לכתוב ומשתמש בטאב כדי להשלים את המימושים.
2. העתקה - זה כשאני מבקש מה AI לכתוב את הקוד בתוך מסך הצ'ט או כשאני קורא מדריך כתוב בחלון אחד וכותב את אותו הקוד לבד מאפס בחלון ה IDE שלי (לא העתק-הדבק, ממש מקליד). פה כבר לקחתי צעד משמעותי קדימה מבחינת רמת הלימוד. אני לא בטוח למה אבל ההקלדה עצמה דורשת רמת הבנה יותר מעמיקה מ Copy/Paste.
3. שינויים קטנים - מדרגה שלישית זה כשאני משנה דברים קטנים בקוד או בהנחות היסוד שלו. לדוגמה אני מבקש מ AI לכתוב דוגמה לקומפוננטה בריאקט ואז הולך ל IDE ובונה את הקומפוננטה ב next.js או מחליף שפת תכנות וכותב את הקומפוננטה לבד ב Reagent שזה הריאקט ל ClojureScript. או אם אני לומד Machine Learning אני יכול לקרוא מדריך ב pytorch ולכתוב את דוגמת הקוד בעצמי ב C++ ב libtorch או ב torch-rb ברובי. כתיבת הקוד מחדש בסביבה קצת שונה דורשת רמה יותר גבוהה של הבנה ומכריחה אותנו לחזור ל AI ולשאול שאלות הבהרה על חלקים בטקסט, מה שעוד ממשיך ומחזק את ההבנה.
כשהמטרה היא ללמוד לעומק איך דברים עובדים יותר לאט זה יתרון.
1 420
"version": "d114e02a9a610c261738bf4254648a71b3fce993",
"encryptHistory": true,
"clearHistory": false
}
1 420
וזה מסיים את הקומפוננטה הראשונה שלנו.
בשביל לראות את העמוד נלך לפי הכללים של ריילס. בקובץ
config/routes.rb אני מוצא את השורה:
get 'inertia-example', to: 'inertia_example#index'
app/controllers/inertia_example_controller.rb אני מוצא את ההגדרה:
class InertiaExampleController < ApplicationController
def index
render inertia: 'InertiaExample', props: {
name: params.fetch(:name, 'World'),
}
end
end
app/javascript/components בתוכה שם את הקובץ Counter.tsx ובו התוכן:
import { useState } from 'react'
export default function Counter() {
const [count, setCount] = useState(0)
return (
<div className="flex flex-col items-center justify-center h-screen bg-gray-100">
<h1 className="text-3xl font-bold mb-4">Counter: {count}</h1>
<div className="space-x-4">
<button
onClick={() => setCount(count - 1)}
className="px-4 py-2 bg-red-500 text-white rounded hover:bg-red-600 transition"
>
-
</button>
<button
onClick={() => setCount(count + 1)}
className="px-4 py-2 bg-green-500 text-white rounded hover:bg-green-600 transition"
>
+
</button>
<button
onClick={() => setCount(0)}
className="px-4 py-2 bg-gray-500 text-white rounded hover:bg-gray-600 transition"
>
Reset
</button>
</div>
</div>
)
}
import Counter from '@/components/Counter';
<Counter />
<Counter />
<Counter />
config/routes.rb כדי שיכיל את שני הנתיבים:
get 'inertia-example', to: 'inertia_example#index', as: :home
get 'inertia-about', to: 'inertia_example#about', as: :about
inertia_example_controller.rb לתוכן הבא:
* frozen_string_literal: true *
class InertiaExampleController < ApplicationController
def index
render inertia: 'InertiaExample', props: {
name: params.fetch(:name, 'World'),
about_path:,
}
end
def about
render inertia: 'About', props: {
home_path:,
}
end
end
app/javascript/pages/About.tsx עם התוכן הבא:
import { Link } from '@inertiajs/react'
export default function About({
home_path
}: {
home_path: string,
}) {
return (
<div>
<Link href={home_path}>Back home</Link>
</div>
)
}
InertiaExample.tsx ומוסיף גם לו את הלינק:
export default function InertiaExample({ name, about_path }:
{ name: string,
about_path: staring }) {
return (
<>
<Head title="Inertia + Vite Ruby + React Example" />
<div className={cs.root}>
<Link href={about_path}>About Us</Link>
{
"component": "About",
"props": {
"errors": {},
"home_path": "/inertia-example"
},
"url": "/inertia-about",