הבלוג של ינון פרק

הפקודה const מגדירה ערך בתור קבוע נכון? אז למה כל כך מסובך להשתמש בה נכון ב Node, ואיך אפשר להגדיר קבוע שקבצים בכל התוכנית יכירו אותו?

נתחיל עם מה שעובד - כל עוד אנחנו בקובץ יחיד אפשר להשתמש ב const כדי לתת שם לערך קבוע:

const MESSAGE_SIZE = 48;

ומכאן ועד סוף הקובץ לא משנה מה תעשו השם MESSAGE_SIZE תמיד יתייחס למספר הקבוע 48. אבל העסק מסתבך מהר מאוד כשאנחנו רוצים לשתף מידע בין מספר קבצים. נניח שהקובץ utils.js מגדיר הפעם את הקבוע ומייצא אותו:

// utils.js
const MESSAGE_SIZE = 48;
exports.MESSAGE_SIZE = MESSAGE_SIZE;

והקובץ app.js מייבא את הקבוע:

const { MESSAGE_SIZE } = require('./utils');
console.log(MESSAGE_SIZE);

זה עבד לא רע והדפיס 48, אבל הולך להישבר די בקלות. נסו לכתוב במקום את הקוד הבא ב app.js:

const utils = require('./utils');
utils.MESSAGE_SIZE = 999;

console.log(utils.MESSAGE_SIZE);

הקוד ידפיס 999 וגם כל קובץ אחר שיטען את הקבוע מ utils יקבל עכשיו את הערך 999. מסתבר שברגע שאנחנו עוברים להשתמש במנגנון ה exports מה שאנחנו בעצם מייצאים הוא אוביקט. המילה const לא מונעת שינויים בשדות של האוביקט וכך כל מי שרוצה יכול לשנות את ה"קבועים" שלנו.

מה אפשר לעשות? אז אומנם const לא תעזור לשמור על שדות של אוביקטים משינויים, אבל Object.freeze דווקא כן. אם נפעיל אותה לפני ה export נוכל לקבל קבועים של ממש.

החליפו את תוכן הקובץ utils.js עם הקוד הבא:

module.exports = Object.freeze({
  MESSAGE_SIZE: 48,
});

ועכשיו בלי לשנות את app אפשר להריץ אותו שוב ולקבל את ערך הקבוע 48. מספר זה לא ישתנה לא משנה מה נכתוב בקבצים שטוענים אותו.

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

הספריה Express של Node.js היא הדרך האהובה על מתכנתי Front End רבים לכתוב קוד צד שרת, וזה לא סתם. בהיותה ספריית Node אקספרס מאפשרת לשתף המון קוד בין צד השרת לצד הלקוח, כולל שילוב מאוד קל של Server Side Rendering בפריימוורקס שתומכות בזה.

אבל אקספרס היא הרבה יותר מדרך לכתוב קוד צד שרת ב JavaScript. תפיסת העולם האסינכרונית של אקספרס אומרת שקל לכתוב שרתים מאוד מהירים. תפיסת העולם המינימליסטית של הספריה אומרת שברוב המקרים קל לכתוב קוד שיגדל בצורה אופקית (כלומר שאפשר יהיה בקלות להוסיף מכונות וכך להתמודד עם עומסים).

ויש גם אתגרים כמובן- עבודה אסינכרונית כתפיסת עולם עלולה להוביל לקוד עמוס ב Callbacks שיהיה קשה לקרוא אותו. המבנה של Middlewares מציע גמישות רבה אך יכול גם לבלבל אם לא מבינים אותו עד הסוף.

ביום חמישי אני הולך להעביר שעה בשידור חי על פיתוח קוד צד-שרת באמצעות Express ו Node.JS. הוובינר מתאים גם למתכנתי Front End שאף פעם לא כתבו קוד צד שרת, גם למתכנתים שכתבו בסביבות אחרות מ Express, ואני חושב שגם אם כתבתם קצת באקספרס עדיין שווה לכם לבוא כי תוכלו לחזק את הידע. התוכנית להתחיל מההתחלה של אקספרס ולבנות פרויקט יחד אתכם מאפס ודרכו לדבר על:

1. מבנה פרויקט, כולל הפרדה בין לוגיקה עסקית לקוד ממשק Web.

2. איך לפתח נכון קוד אסינכרוני באמצעות Promises.

3. מהם Express Middlewares, למה צריך אותם ואיך הם עוזרים לנו לכתוב קוד נקי יותר בפרויקטים שלנו.

השתתפות בחינם אבל דורשת רישום מראש בקישור: https://www.tocode.co.il/workshops/56

הקלטה תהיה זמינה למנויי האתר יום-יומיים אחרי הוובינר. אם אתם באים כדאי להתקין לפני את Node כדי שתוכלו לכתוב יחד איתי את הקוד ולשאול שאלות רלוונטיות.

נתראה בחמישי, ינון

אז אתם יודעים לכתוב תוכניות Express בנוד ואולי גם ראיתם איך נראה קוד של Middleware. אבל... מה אפשר לעשות עם זה? ולמה שתרצו לכתוב אחד לתוכנית שלכם? הנה כמה רעיונות.

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

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