ToCode - Telegram kanali @tocodeil statistikasi va tahlili

1 418

https://www.tocode.co.il/blog/2025-03-next-objections

1 418

ניסוי Next - טעינת מידע אחרי עליית העמוד עם use קשה מאוד להבין את ריאקט היום מחוץ לקונטקסט של next. כתבתי כאן על הסירבול בפונקציה use בגלל הצורך להעביר את ה Promise מבחוץ והבעיה ביצירת Promise מתוך קומפוננטות. עכשיו בואו נראה את הסיפור במשקפיים הנכונות של next ונראה למה בשימוש מלא של הפיצ'ר אין שום בעיה. הבעיה עם קומפוננטות אסינכרוניות נתבונן בקומפוננטה הבאה:

import { slowlyGetCwd } from "../actions/demo"

export default async function Main() {
  const cwd = await slowlyGetCwd();
  return (
    <div>
      <p>Page content</p>
      <div>Server runs from: <pre>{cwd}</pre></div>
    </div>
  )
}

ובפונקציית צד השרת שמתאימה לה:

'use server';

import {setTimeout} from 'node:timers/promises';

export async function slowlyGetCwd() {
  await setTimeout(3000);
  return process.cwd();
}

מה שקורה כשהעמוד עולה השרת מפעיל את הפונקציה, מחכה 3 שניות ורק אז מסיים לייצר את ה HTML ושולח אותו לדפדפן. ב-3 שניות האלה הגולש פשוט מחכה לתשובה שרת ולא רואה כלום על העמוד. לפעמים זאת התנהגות הגיונית, אולי באמת אנחנו טוענים מידע מאוד בסיסי מבסיס הנתונים ואין מה להראות עד שהמידע הזה מגיע, אבל לפעמים זו המתנה מיותרת - אולי אני מחכה לטעון תמונת פרופיל של המשתמש מאיזה אתר צד שלישי ורק בגלל ההמתנה לתמונה הזאת משתמש צריך לחכות ולא לקבל את המידע שכן יש לי מוכן בשבילו. איך use פותר את הבעיה פונקציית use החדשה בריאקט 19 מאפשרת גם גישה ל Context API וגם המתנה ל Promises. אותנו מעניין לנסות את השימוש השני בה: אם פונקציית use מקבלת Promise אז הקומפוננטה לא תתרנדר, יוצג במקומה "תחליף" מתוך בלוק ה Suspense הקרוב ביותר, ורק כשה Promise תהיה מוכנה אז הקומפוננטה תופיע. ב Next אנחנו יכולים להעביר Promise בתור Prop מקומפוננטת צד שרת לקומפוננטת צד לקוח, ולכן נוכל להשתמש במנגנון כדי לשלוח מידע לדפדפן אחרי שהעמוד נטען. זה יעבוד כך: 1. קומפוננטת צד שרת מפעילה פעולה אסינכרונית שלוקחת זמן. 2. הקומפוננטה מעבירה את ה Promise לסיום התהליך בתור Prop לקומפוננטת צד לקוח. 3. קומפוננטת צד לקוח מפעילה use על ה Promise. 4. כשה Promise מסתיים בצד השרת, השרת שולח לדפדפן את המשך העמוד ב Streaming. זה גורם ל Promise בצד הלקוח להסתיים וכך ריאקט יכול לרנדר את קומפוננטת צד הלקוח עם המידע שהגיע מהשרת. דוגמה: קבלת מידע אחרי שהעמוד נטען בואו נחליף את קומפוננטת Main שכתבנו בקומפוננטה עם use. תחילה גירסת ה client component של Main:

'use client';
import {use} from 'react';

export default function Main({
  cwdPromise
}: {
  cwdPromise: Promise<string>,
}) {
  const cwd = use(cwdPromise)
  return (
    <div>
      <p>Page content</p>
      <div>Server runs from: <pre>{cwd}</pre></div>
    </div>
  )
}

ועדכון page.tsx כדי לייצר את ה Promise, להעביר אותו כ prop ולהגדיר את התוכן שיוצג בזמן הטעינה:

import Head from "./components/head"
import Main from "./components/main"
import { slowlyGetCwd } from "./actions/demo"
import { Suspense } from "react";

export default function Home() {
  const getCwd = slowlyGetCwd();
  
  return (
    <div>
      <Head />
      <Suspense fallback={<p>Loading Main</p>}>
        <Main cwdPromise={getCwd} />
      </Suspense>
    </div>
  )
}

התוצאה: העמוד נטען מיד אבל במקום Main מוצג התוכן Loading Main. אחרי 3 שניות תוכן ה Fallback מוחלף בתוכן האמיתי של Main עם התוצאה של הפונקציה האיטית בצד השרת.

1 418

https://www.tocode.co.il/blog/2025-03-next-use-promise

1 418

https://www.tocode.co.il/blog/2025-02-nextjs-clientside-router

1 418

אנלוגיית הלגו והבעיה שלנו עם תכנון רופא שצריך לטפל בחולה יודע להסתכל על אלפי חולים שסבלו בעבר מאותם תסמינים, לנתח את הבעיה ולבחור את הטיפול הטוב ביותר. אדריכל שצריך לתכנן גשר יודע להסתכל על אלפי גשרים שנבנו בעבר ולבחור את שיטת הבניה הטובה ביותר לגשר החדש. כן הוא יוכל לחדש בקצוות, אבל הבסיס בנוי על רעיונות שעובדים אלפי שנים. ואנחנו? אנחנו בונים בלגו ובלי חוברת הדרכה. כמתכנתים אנחנו מאוד טובים בבניית ספריות קטנות, אנחנו משתפים אותן בגיטהאב או בין פרויקטים. אנחנו גם יודעים לדבר על "עקרונות" או "רעיונות" של קוד נקי. אבל מאחר ואין שתי מערכות זהות אין לנו אוסף של מערכות שנבנו בעבר ללמוד מהן. יותר מזה, הטכנולוגיה משתנה כל כך מהר שאפילו אם אני בונה את אותו פרויקט שנה אחרי שנה הקוד יראה אחרת. אז מה הפלא שכל פרויקט תוכנה לוקח יותר זמן ועובד פחות טוב ממה שרצינו? הכניסה של ה AI מעניינת. עכשיו יש לנו פועל אוטומטי שמוכן לבנות את אבני הלגו הבסיסיות בשבילנו הרבה יותר מהר ממה שאי פעם הצלחנו. האם זה הולך להפוך את החיים שלנו לצפויים יותר? אני לא בטוח. זה לא מקרי ש AI לא מצליח להפוך "סיפור לקוח" לסידרה של משימות פשוטות עם הערכות זמנים מדויקות לכל משימה. האתגר שלו הוא עדיין גם האתגר שלנו, ופיתוח אבני לגו טובות יותר או מגוונות יותר זה לא החלק המעניין כאן.

1 418

https://www.tocode.co.il/blog/2025-02-design-to-code

1 418

הי חברים וחברות סקר זריז אני עובד על ריענון קורס ריאקט להתאים אותו לריאקט 19, נקסט וכל מה שקורה היום אשמח לשמוע מכם - איזה דברים בעולם של ריאקט הייתם שמחים למצוא בקורס?

1 418

ניסוי ויו: הצפנת זיגזג כתבתי פה בעבר על הספר סודות ההצפנה לילדים שכתבה סתיו אלבר כשהספר עוד היה רעיון בהדסטארט. היום הספר גמור ואני באמצע הקריאה עם הילדים הפרטיים שלי שמאוד נהנים ממנו בינתיים. בשביל המשחק ובעקבות השראה מהספר חשבתי לממש את אחת ההצפנות הפרימיטיביות מהדוגמאות של סתיו בקוד Vue. מה זה הצפנת זיגזג ההצפנה נקראת הצפנת זיגזג או באנגלית Rail fence cipher וזהו מצפין שבסך הכל משנה את סדר האותיות במילה באופן הבא: כותבים את המילה מלמטה למעלה לרוחב הדף עד לגובה מסוים שנקרא המפתח, ואז ממשיכים את הכתיבה כלפי מטה עד שמגיעים לשורת ההתחלה ואז שוב עולים למעלה. עם מספיק אותיות הצורה שמתקבלת נראית כמו זיגזג. בסוף לוקחים את הטקסט שכתוב מלמעלה למטה וזו ההודעה המוצפנת. אפשר לשחק עם ההצפנה בניסוי ויו שכתבתי כאן: <iframe src="https://railsfencecipher-vue.vercel.app" height="600" width="800" /> או אונליין בקישור: https://railsfencecipher-vue.vercel.app ובקוד הניסוי בגיטהאב: https://github.com/ynonp/railsfencecipher-vue סקירת קוד הצפנה ופיענוח הקובץ שמטפל בהצפנה ופיענוח הוא:

import _ from 'lodash';

export function encrypt(msg: string, key: number) {
  const height = key;
  const groupSize = height * 2 - 2;
  
  const positions = msg.split('').map((ch, idx) => {
    const indexInGroup = idx % groupSize;
    const rowFromBottom = (indexInGroup < height) ? (indexInGroup + 1) : height - (indexInGroup + 1 - height);
    const rowFromTop = height - (rowFromBottom - 1);

    return {
      ch,
      column: idx + 1,
      row: rowFromTop,
      style: { gridArea: \${rowFromTop} / ${idx + 1}\ }
    }
  })

  const message = _.sortBy(positions, 'row').map(p => p.ch).join('');
  return {
    positions,
    message,
  }
}

export function decrypt(msg: string, key: number) {
  const {positions} = encrypt(msg, key);
  const sortedPositions = _.sortBy(positions, 'row');
  const positionsWithEncryptedMessage = sortedPositions.map((p, index) => ({...p, ch: msg[index]}));
  return {
    positions: positionsWithEncryptedMessage,
    message: _.sortBy(positionsWithEncryptedMessage, 'column').map(p => p.ch).join('')
  }
}

בגדול לוקחים את ההודעה ורצים בלולאה על כל התווים, בכל תו מעלים ב-1 את אינדקס העמודה ומשנים את אינדקס השורה לפי הבדיקה באופרטור הטרנרי, אם הוא בחלק הראשון של הזיגזג מעלים את אינדקס השורה ואם הוא בחלק השני של הזיגזג מורידים את מספר השורה. בשביל הפיענוח אפשר להשתמש באותה פונקציית הצפנה כדי לחשב את צורת הזיגזג ואחרי זה בלולאה נוספת ממלאים את הריבועים באותיות האמיתיות. מחשבות על ניסויים ו AI צריך להגיד, נהניתי מהניסוי. הוא עזר לי להבין טוב יותר את הרעיון של צופן זיגזג. לא היה לי ספק שיש כבר אנשים שמימשו את זה לפניי באינטרנט ואכן לא צריך יותר מכמה שניות בגוגל כדי להגיע להמון מימושים והסברים על צופן זה, כמו שגוגל יודע. ברור גם שמנועי AI מסוגלים לבנות את הקוד הרבה יותר מהר ממה שאני כתבתי ואפילו לייצר תוצאה יפה יותר. הנה זו הגירסה של קלוד לאותו מצפין: https://claude.site/artifacts/6a2f527f-8bc8-43d5-b837-3996a9c6392c מתוך הפרומפט: > create an online rails fence cipher / decipher tool ואז מגיעים לשאלה - אם הכל כבר קיים בשביל מה לבנות את זה? ואם קלוד יודע לבנות את המצפין בשניה וחצי למה לא לקחת את המימוש שלו? ובכלל איך נראה העתיד שלי כמתכנת כשקלוד עושה כל דבר יותר מהר? התשובה שלי כרגע היא שהידע התיאורטי והידע המעשי קשורים אחד לשני, ואנחנו צריכים להתאמן על שניהם כדי להיות מסוגלים לבנות את המוצרים הבאים. ככל שעובר הזמן עם ה AI המגבלות שלו מתבהרות. זה לא מפריע לי לכתוב קוד שקלוד היה יכול לכתוב מהר יותר בשביל ללמוד נושא, כי ניסוי מעשי הוא עדיין הדרך הטובה ביותר ללמוד. ממילא העבודה אמיתית שאני עושה - פיתוח ותיקון מערכות אמיתיות, היא מחוץ ל Context Window של כל AI שראיתי או שאני יכול לדמיין.

1 418

https://www.tocode.co.il/blog/2025-02-vue-rail-fence-cipher

1 418

חכמים מדי בזמן ששברתי את הראש כדי להבין למה המייל האוטומטי של הפוסט לא נשלח אתמול שמעתי מהצד של המוח קול מהעבר. עזוב ניסיתי להשתיק אותו, זה לא קשור, זה בטח בגלל השינוי שהוספתי ל Headers של המייל יום קודם, משהו שם לא נדחף כמו שצריך. ״אתה יודע מה הבעיה שלכם?״ אמר לי פעם מנהל חכם, ״אתם חכמים מדי. מרוב שאתם רואים בעיות אתם לא מצליחים להתקדם״. לא רציתי להסכים איתו. הייתי בטוח שאנחנו רואים בעיות אמיתיות, שקוד צריך להיות נכון לפני שהוא עובד, שרק כתיבה נכונה ומסודרת מייצרת מערכות נכונות, ורק אני יודע מה זה נכון ומסודר. אני חוזר לדבג את התקלה של המייל שלא נשלח. אצלי בפיתוח הכל עובד אז אני מנסה להריץ את התהליך ידנית ומקבל את הודעת השגיאה:

Template contains unsupported operations

רגע מה פתאום unsupported oprations? ומי בכלל דיבר על טמפלייטס? אבל מהר מאוד דברים מתחילים להתחבר. הפונקציה send_bulk_email של SES יודעת לקבל פרמטרים כדי לקסטם את האימייל לכל נמען בנפרד. פרמטרים בגוף המייל נכתבים בתוך סוגריים מסולסלים כפולים, ואצלי בפוסט היתה דוגמה בדיוק של סוגריים מסולסלים כפולים. האם SES חושב בטעות שתוכן המייל שלי דורש החלפת תבנית? האם הוא חושב שהסוגריים שבפוסט מגדירים פרמטרים? ואם זה המצב מה המשמעות של unsupported operations. ״כשאני צריך לבנות פיצ'ר אני משתמש בכלים שאני מכיר. אם צריך אני מוכן גם לסטות מהאיפיון, ובלבד להגיע למשהו שעובד בזמן עליו התחייבתי. אני לא עושה הערכות זמנים, אני קובע זמנים, והפיתוח מתאים לזמן שקבעתי. אתם נכנסים למשימה כמו לעבודת מחקר: מחפשים איך דברים צריכים לעבוד ומנסים לממש את זה. אין סיכוי לעמוד בזמנים ככה״. אני מנסה לתקן. מה הבעיה, זה רק להוסיף לוכסן הפוך לפני הסוגריים המסולסלים ההפוכים לפני ששולחים אותו לפונקציה של AWS, אבל שום דבר בתוכנה לא יכול להיות כל כך פשוט. ל AWS לא אכפת מהלוכסן ההפוך שלי והוא ממשיך להתלונן על התבנית שמכילה פעולות שאינן נתמכות. עכשיו אני כבר שומע בבירור את הקול מהעבר ומבין שהבעיה שלי הרבה יותר עמוקה. בואו נסכם: 1. יש שתי דרכים לשלוח אימייל ב AWS. אפשר לשלוח מייל בודד בפרוטוקול SMTP או לשלוח ערימה של אימיילים בקריאת פונקציה אחת דרך ה API של AWS. ברור שהקריאה האחת מהירה ויעילה יותר. יותר מזה, אני באמת צריך התאמה אישית של המייל לכל נמען כי בכל מייל יש קישור להסרה מרשימת התפוצה והקישור שונה לכל נמען. 2. הבעיה - בזמן הפיתוח לא ידעתי כלום על SES, לא הכרתי את המגבלות שלו. ערבבתי בין פרויקט מחקרי לפרויקט פיתוח, ובחרתי באפשרות שנראתה נכונה למרות שהיא לקחה זמן פיתוח ארוך בהרבה. 3. המכה - אפילו אחרי שהקוד הנכון עבד, ובגלל שלא הכרתי מספיק טוב את SES לא ידעתי שהוא רגיש לתווים שנראים כמו משתנים להחלפה אבל בעצם אינם כאלה. אני עדיין לא יודע אם ה API של SES יכול לפתור את הבעיה הזאת או איך להשתמש בו כדי להחליף משתנה במקום אחד (קישור להסרה מהרשימה) אבל להתעלם מדברים שנראים כמו משתנים במקומות אחרים. 4. מה עדיף - אחרי שראיתי את כל זה עדכנתי את הקוד כדי לשלוח את המייל דרך SMTP. כן זה לוקח יותר זמן אבל ממילא התהליך רץ ברקע. ל AWS לא אכפת לקבל אפילו אלפי מיילים ב SMTP והקוד בצד שלי יצא הרבה יותר פשוט וקצר. יותר מזה, אם בעתיד ארצה לעבור לשירות מייל מתחרה השינוי היחיד שיידרש הוא בהגדרות ולא בקוד, כי אני לא נעול על API ספציפי של SES. האם יום אחד זה יישבר? אולי. אבל זאת בהחלט בעיה שלא היה צריך לפתור מראש. מתכנתים חכמים (שאינם חכמים מדי) יודעים לבחור טכנולוגיות משעממות כשהן פותרות את הבעיה מספיק טוב.

1 418

https://www.tocode.co.il/blog/2025-02-too-smart

1 418

טיפ רובי - החלפת טקסט מתוך Hash פונקציית gsub של רובי מחליפה טקסטים בתוך מחרוזות. היא פועלת על מחרוזת, מקבלת ביטוי רגולארי אותו צריך למצוא במחרוזת וטקסט להחלפה ושמה את הטקסט להחלפה במקום הביטוי הרגולארי. עד לפה לא מלהיב כלל. דברים מתחילים להיות מעניינים כשבמקום טקסט אנחנו מעבירים בתור פרמטר Hash עם מספר מפתחות להחלפה. המקרה הפשוט הפונקציה gsub יודעת לקבל ביטוי רגולארי וטקסט להחלפה ומחליפה כל מופע של הביטוי הרגולארי בטקסט. זה נראה ככה:

> 'hello big world'.gsub(/ /, '-')
 => "hello-big-world"

מעניין לגלות שברובי אפשר להעביר במקום טקסט להחלפה Hash עם מספר טקסטים להחלפה, ואז אחרי התאמה של הביטוי הרגולארי הפונקציה תחפש ב Hash מפתח עם תוכן הטקסט שהתאים לביטוי ואם היא מוצאת היא תחליף את הטקסט בערך שמופיע ב Hash, כלומר:

 > 'hello big world...'.gsub(/\W/, {' ' => '-', '.' => '!'})
 => "hello-big-world!!!"

החלפת טוקנים הפיצ'ר הזה ממש חמוד כי הוא מאפשר לכתוב בקלות מנגנון טמפלייטס, כלומר קוד שיקבל טקסט ויחליף מילים שמורות בערך שלהן מתוך ה Hash. לדוגמה שימו לב לקוד הזה:

3.1.1 :034 > text = 'name: {{name}}, email: {{email}}, phone: {{phone}}'
 => "name: {{name}}, email: {{email}}, phone: {{phone}}"
3.1.1 :035 > data = {'{{name}}' => 'ynon', '{{email}}' => 'testmail', '{{phone}}' => '0521111111' }
 => {"{{name}}"=>"ynon", "{{email}}"=>"testmail", "{{phone}}"=>"0521111111"}
3.1.1 :036 > text.gsub(/{{\w+}}/, data)
 => "name: ynon, email: testmail, phone: 0521111111"

מה עוד אפשר טיפ אחרון לפונקציה הזאת קשור לביטוי הרגולארי עצמו. נשים לב שבדוגמה האחרונה המפתחות ב Hash היו עטופים בסוגריים מסולסלים כפולים, כדי שיתאימו לטקסט שהביטוי הרגולארי תפס. לפעמים יהיה לנו כבר Hash עם מפתחות שלא בדיוק מתאימים לטקסט אותו אנחנו מצפים לתפוס לדוגמה:

data = {'name' => 'ynon', 'email' => 'testmail', 'phone' => '0521111111' }
 => {"name"=>"ynon", "email"=>"testmail", "phone"=>"0521111111"}

במצב כזה אפשר להפעיל map כדי לשנות את שמות המפתחות ואז to_h כדי לחזור ל Hash, אבל אולי יותר קל לתקן את הביטוי הרגולארי. בעזרת Lookarounds אני יכול לכתוב ביטוי שיחפש את סימני הסוגריים המסולסלים הכפולים אבל לא "יתפוס" אותם וכך ההתאמה תהיה רק מול המילה עצמה (name, email או phone):

3.1.1 :044 > text.gsub(/(?<={{)\w+(?=}})/, data)
 => "name: {{ynon}}, email: {{testmail}}, phone: {{0521111111}}"

1 418

https://www.tocode.co.il/blog/2025-02-ruby-gsub-hash

1 418

ללמוד טכנולוגיה חדשה בשביל פרויקט? חבר שואל - יש לי פרויקט flask שמשתמש ב Psycopg ואני צריך לשכתב את רוב הקוד שעובד עם בסיס הנתונים. שווה לי ללמוד SQLAlchemy בשביל זה? קל לראות למה לא: 1. הפרויקט כאן. יש לו דדליין. אתה כבר יודע לעבוד עם Psycopg אבל אין לך מושג איך עובדים עם SQLAlchemy, ואפילו אם עשית טוטוריאל או שניים אין לך מושג איזה בעיות יהיו שם. חבל לבזבז פרויקט טוב רק בגלל שבא לך ללמוד משהו חדש. 2. המטרה בלימוד היא להבין. כשאתה צריך לבנות מערכת אין לך זמן לקרוא את כל התיעוד, להקשיב להרצאות, להיכנס לקוד הספריה ולנסות לשבור דברים כדי לראות איך זה עובד. חבל לבזבז לימוד טוב רק בגלל שעכשיו צריך לשכתב קוד ישן. כשאנחנו מפרידים בין הלימוד לפיתוח שני הצדדים מרוויחים. בצד הלימוד אנחנו לא ממהרים לסיים פרויקט ויכולים לכתוב ולמחוק ולשבור ולבנות POC-ים קטנים עד שנהיה בטוחים איך דברים עובדים. בצד הפיתוח אנחנו יכולים לתת הערכות זמנים מדויקות כי אנחנו עובדים עם טכנולוגיות שאנחנו מכירים. עבודה מקצועית אומרת שעלינו להסתכל על טובת הלקוח, ולפיתוח וללימוד יש שני לקוחות שונים: הלקוח של פרויקט הפיתוח הוא הבוס שלך בעבודה; הלקוח של הלימוד הוא אתה עצמך. שני פרויקטים. שני לקוחות. שני עולמות.

1 418

https://www.tocode.co.il/blog/2025-02-rewrite-with-sqlalchemy

1 418

הרבה יותר משניים דן אברמוב כותב על שני ריאקטים, הריאקט שרץ על השרת והריאקט שרץ בדפדפן, ועל התפקידים השונים של כל אחד מהם. אני חושב שהוא עושה לעצמו הנחה. יש הרבה יותר משניים: 1. האם את ספריית תצוגה לצד לקוח, שנועדה לעזור לצוותים גדולים לתחזק אתרים עם יותר מדי קוד JavaScript? 2. האם את ספריית Full Stack שנועדה לעזור למפתחים להעלות מהר יותר פרויקטים לאוויר? 3. האם את מנסה לעזור לי לכתוב אתרים שעובדים מהר יותר (ההבטחה של Single Page Apps), או מנסה לגרום לי לכתוב קוד "נכון" גם אם זה עולה בזמני טעינה ופגיעה בביצועים? 4. האם את מעודדת שיתוף קוד בין פרויקטים או חדשנות ושינוי (שיבואו תמיד על חשבון היכולת להשתמש בקוד ישן שמצאתי ברשת) ? 5. האם את ספריית צד לקוח שאני יכול להכניס לכל פרויקט או ספריית Full Stack שדורשת קוד מיוחד בצד השרת על מנת לעבוד בצורה מיטבית? עמוד הבית של התיעוד של ריאקט כולל את ההבטחה: > Whether you work on your own or with thousands of other developers, using React feels the same. It is designed to let you seamlessly combine components written by independent people, teams, and organizations. ואני רוצה לקחת אותם ברצינות, אבל יודע שפרויקטי ריאקט שאני ראיתי לא "הרגישו אותו דבר". פרויקט צד-לקוח שמשתמש ב Redux ומחזיק את הלוגיקה והפעולות מחוץ לריאקט, ירגיש מאוד שונה מפרויקט שמעביר את כל עומס העבודה לקומפוננטות וישתמש ב react-query כדי למשוך מידע מהשרת ולשמור אותו בקונטקסט, ושני אלה ירגישו שונה מפרויקט שמשתמש ב Zustand, Valtio או Jotai. פרויקט שמשתמש ב Shadcn ו Tailwind ירגיש מאוד שונה מפרויקט שמשתמש ב Styled Components. ועוד לא דיברנו על next לעומת remix לעומת redwood לעומת tanstack start. עכשיו שקורס Vue מאחוריי התחלתי לארגן מחדש את קורס ריאקט. האקוסיסטם של ריאקט תמיד היה מבולגן ובשנים האחרונות זה רק מחמיר. זה לא מה שיהרוג את ריאקט, אבל זה כן משהו שצריך להיות מאוד מודעים אליו כשלומדים ריאקט או כשנכנסים לעבוד על פרויקט.

1 418

https://www.tocode.co.il/blog/2025-02-more-than-two

1 418

הרבה יותר משניים דן אברמוב כותב על שני ריאקטים, הריאקט שרץ על השרת והריאקט שרץ בדפדפן, ועל התפקידים השונים של כל אחד מהם. אני חושב שהוא עושה לעצמו הנחה. יש הרבה יותר משניים: 1. האם את ספריית תצוגה לצד לקוח, שנועדה לעזור לצוותים גדולים לתחזק אתרים עם יותר מדי קוד JavaScript? 2. האם את ספריית Full Stack שנועדה לעזור למפתחים להעלות מהר יותר פרויקטים לאוויר? 3. האם את מנסה לעזור לי לכתוב אתרים שעובדים מהר יותר (ההבטחה של Single Page Apps), או מנסה לגרום לי לכתוב קוד "נכון" גם אם זה עולה בזמני טעינה ופגיעה בביצועים? 4. האם את מעודדת שיתוף קוד בין פרויקטים או חדשנות ושינוי (שיבואו תמיד על חשבון היכולת להשתמש בקוד ישן שמצאתי ברשת) ? 5. האם את ספריית צד לקוח שאני יכול להכניס לכל פרויקט או ספריית Full Stack שדורשת קוד מיוחד בצד השרת על מנת לעבוד בצורה מיטבית? עמוד הבית של התיעוד של ריאקט כולל את ההבטחה: > Whether you work on your own or with thousands of other developers, using React feels the same. It is designed to let you seamlessly combine components written by independent people, teams, and organizations. ואני רוצה לקחת אותם ברצינות, אבל יודע שפרויקטי ריאקט שאני ראיתי לא "הרגישו אותו דבר". פרויקט צד-לקוח שמשתמש ב Redux ומחזיק את הלוגיקה והפעולות מחוץ לריאקט, ירגיש מאוד שונה מפרויקט שמעביר את כל עומס העבודה לקומפוננטות וישתמש ב react-query כדי למשוך מידע מהשרת ולשמור אותו בקונטקסט, ושני אלה ירגישו שונה מפרויקט שמשתמש ב Zustand, Valtio או Jotai. פרויקט שמשתמש ב Shadcn ו Tailwind ירגיש מאוד שונה מפרויקט שמשתמש ב Styled Components. ועוד לא דיברנו על next לעומת remix לעומת redwood לעומת tanstack start. עכשיו שקורס Vue מאחוריי התחלתי לארגן מחדש את קורס ריאקט. האקוסיסטם של ריאקט תמיד היה מבולגן ובשנים האחרונות זה רק מחמיר. זה לא מה שיהרוג את ריאקט, אבל זה כן משהו שצריך להיות מאוד מודעים אליו כשלומדים ריאקט או כשנכנסים לעבוד על פרויקט.

1 418

https://www.tocode.co.il/blog/2025-02-more-than-two

1 418

היום למדתי: תווים מצחיקים במשתני סביבה אנחנו יודעים להגדיר קובץ .env עם משתני הסביבה של הפרויקט בפורמט הזה:

API_KEY=abcdefg

ואחרי זה לקרוא את משתני הסביבה באמצעות:

console.log(process.env.API_KEY);

הסיפור נהיה מעניין כשאנחנו מוסיפים תווים מיוחדים לערכים של משתני הסביבה, לדוגמה:

API_KEY=abcd$e$fgh#abc123

ניסיון רגיל ב next.js לטעון קובץ env כזה ישאיר את משתנה הסביבה בלי החלק שאחרי הסולמית. ואל תדאגו שום הודעת שגיאה לא תופיע על המסך. אפשר (רצוי) להקיף את משתנה הסביבה במרכאות:

API_KEY="abcd$e$fgh#abc123"

אבל זה לא מספיק. עכשיו אנחנו מאבדים את האותיות שאחרי הדולרים כי next חושב שאלה משתנים. עליהם נצטרך לשמור בנפרד עם לוכסן הפוך:

API_KEY="abcd\$e\$fgh#abc123"

שימו לב ששימוש בגרש בודד לא יעזור כאן, אלא רק יזיק. ב next הגרש הבודד מפוענח כמו גרשיים והכל עדיין עובד, אבל אם תנסו לטעון את קובץ ה .env מתוך bash הגרש הבודד יגרום ללוכסן ההפוך להיכנס בעצמו לערך, כלומר הקוד הזה ב bash:

source .env

עובד עם מרכאות ו Backslash כמו שכתבתי, אבל לא עובד אם במקום מרכאות יהיה גרש בודד.