טיפים קצרים וחדשות למתכנתים
ויו היא ספריה לפיתוח יישומי צד-לקוח מורכבים. בשבועות האחרונים אני מפרסם לאט מדריך Vue למתכנתי Front End שרוצים להתחיל לעבוד עם הספריה. עד כה פורסמו הפרקים:
אם עברתם על כל החלקים אתם כבר צריכים להבין לא רע מה כל המהומה סביב Vue וגם מסוגלים כבר לבנות יישומים בסיסיים. בפרק היום נדבר על Vue Router ונראה מהם יישומי עמוד-יחיד ואיך Vue עוזר לנו לבנות כאלה בקלות.
דרך פופולרית ליצור קוד גרוע היא ליפול במלכודת הלחץ. זה עובד ככה, את עובדת על פיצ'ר ולא בטוחה עדיין שהדרך שבחרת היא הדרך הנכונה. ואז את אומרת לעצמך:
"אני יכולה לכתוב את הפיצ'ר הזה כמו שצריך עם חלוקה נכונה לפונקציות ומחלקות ועם תיעוד ובדיקות יחידה, עם טיפול מסודר בשגיאות ועם כתיבת שאילתת SQL נכונה, אבל, אם אני בדרך הלא נכונה והכיוון הזה לא יביא אותי לפיתרון שעובד אז רק בזבזתי זמן, לכן עדיף לי לכתוב משהו מהר רק בשביל לראות שזה עובד ואחר כך אחזור לתקן".
אחרי שהכל עובד מסתבר שכבר לא כל כך קל למצוא זמן ומוטיבציה לחזור לתקן, וככה נשארים עם פיתרונות חצי אפויים.
האלטרנטיבה היא לכתוב רק קוד שאנחנו גאים בו ולפתור בעיות כשהן מופיעות - ופה יש שני יתרונות: הראשון והברור הוא שאין סיכוי להיתקע עם קוד גרוע כי הוא מראש לא נכתב. השני והיותר חשוב, הוא שלאט לאט הכתיבה של קוד טוב נהיית קלה יותר ואת לומדת לפתור בעיות טוב יותר ומהר יותר.
(נבהיר: לכתוב קוד שאנחנו גאים בו זה לא אומר לפתור את כל בעיות העולם מראש ולפני שהן מופיעות. זה בסך הכל אומר לכתוב קוד שלם, לכתוב קוד שלא יפשל במעבר לפרודקשן, שלא ייפול באינסוף מקרי קצה, ושיהיה אפשר להסתמך עליו. דוגמה לקוד רע היא להשאיר את הטיפול בשגיאות או מקרי קצה לעתיד, או לוותר על וולידציה של קלט כדי לכתוב אותה יום אחד כשיהיה זמן. אלה דברים שבלעדיהם הקוד לא באמת עובד אלא רק נראה עובד; מצד שני קוד טוב יכול לכלול Duplication ולהשאיר לעתיד החלטה על אבסטרקציה מסוימת, וכמובן שלא חייבים לממש את כל הפיצ'רים במכה אחת. כלל אצבע מועיל כאן הוא לשאול, אם מחר אני עוזב את הפרויקט ויבוא בן אדם אחר להחליף אותי, מה הוא יחשוב עליי כשיקרא את הקוד).
הם לא הולכים ביחד, והבעיה שהאיפור רק מחמיר את המצב. נפלתי במקרה על הדף הזה היום: https://docs.npmjs.com/docker-and-private-modules
זה מתוך התיעוד של npm. הדף מסביר איך ליצור קובץ .npmrc בתור Docker Image, למשל בשביל למשוך אימג' ממאגר פרטי. הם ממליצים להשתמש ב Dockerfile הבא:
FROM risingstack/alpine:3.3-v4.3.1-3.0.1
ARG NPM_TOKEN
COPY .npmrc .npmrc
COPY package.json package.json
RUN npm install
RUN rm -f .npmrc
# Add your source files
COPY . .
CMD npm start
ובתבנית הבאה עבור npmrc:
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
שימו לב לאיפור: לא כותבים את הטוקן בתוך הקוד אלא משתמשים במשתנה ומוחקים את הקובץ .npmrc אחרי שהשתמשו בו כדי להפעיל npm install. אבל כמובן שזה איפור כי אנחנו יודעים שכל פקודה שמריצים בתוך Dockerfile נשמרת בהיסטוריה של האימג'. תוכן המשתנה NPM_TOKEN יהיה גלוי לכל מי שיש לו את האימג', בדיוק כמו שהיה אם היינו פשוט שומרים את הקובץ .npmrc עם הטוקן בתוך האימג'.
בשביל המשחק לקחתי את ה Dockerfile שלהם ובניתי ממנו אימג' וגם פירסמתי אותה ב Dockerhub. תראו אם תצליחו לגלות מה הערך של NPM_TOKEN בדוגמה שלי:
https://hub.docker.com/layers/ynonp/dtest/latest/images/sha256-7eb4139557b15d6dd86cd5d9511863aaa03cb4271f3f799d701d5c80aa357575?context=explore&tab=layers.
ש: איך אני מריץ שאילתת SQL מתוך הדפדפן?
ת: אתה לא
וזה משחק שמשנה את הכל. רק אחרי שאתה רואה את הבעיה ומבין באמת את המשמעות של "צד שרת" ו"צד לקוח" אפשר להתחיל לדבר על הפיתרונות, על שליחת השאילתה לשרת ועל כל ההשלכות של גישה זו על אבטחת מידע וביצועים ומה שלא תרצו.
מגבלות טכניות הן לא משהו שצריך "לעקוף"; הן קודם כל משהו שצריך לראות. רק כשאנחנו רואים את הגבולות אנחנו במקום ליצור מערכות טובות יותר.
ספריית Vue היא ספריית JavaScript לפיתוח מבוסס קומפוננטות. היא נחשבת לאחת מספריות הפיתוח הפופולריות היום יחד עם React ו Angular. מה שמייחד את Vue הוא המאמץ של כותביה לבנות ממשק שיהיה מאוד ידידותי לאנשים חדשים ויאפשר כניסה קלה לעולם של קומפוננטות.
פרק זה הוא הפרק החמישי במדריך. אלה החלקים הקודמים:
בפרק היום נראה איך לעטוף קוד קיים בתור קומפוננטת Vue ודרך זה נלמד לסנכרן בין העולם של Vue לעולם של פיתוח JavaScript שאינו מבוסס קומפוננטות.
הקוד הבא מתאר שתי קומפוננטות, שתיהן קוראות ל useEffect:
import { useEffect, useState } from "react";
export default function Page(props) {
useEffect(function () {
document.title = "Page";
}, []);
return <Content />;
}
function Content(props) {
const [title, setTitle] = useState(document.title);
useEffect(function () {
setTitle(document.title);
}, []);
return <p>Page title = {title}</p>;
}
והשאלות:
איזה אפקט ירוץ קודם?
מה יהיה תוכן העמוד אחרי רינדור הקומפוננטה Page?
איך אפשר לשנות את סדר האפקטים ולקבל תוצאה שונה על העמוד?
יש אנשים שכותבים פרויקט צד כדי להרוויח כסף. אני מרוויח כסף כדי שאוכל לבנות פרויקט צד -- מקס רוזן, onlineornot
מקס רוזן אולי לא מרוויח עדיין כסף מ online or not, ואולי לעולם לא ירוויח, אבל כבר בינתיים הוא הספיק לכתוב מוצר פעיל עם לקוחות אמיתיים בסט הטכנולוגיות שהוא בחר, התמודד עם בעיות ביצועים שנבעו מארכיטקטורה לא נכונה ותיקן אותן והגיע ל-4 לקוחות משלמים. בדרך הוא לומד גם על טכנולוגיה, גם על שיווק, גם על כתיבה ועל עוד המון היבטים אחרים של פיתוח מוצרים. אין לי ספק שלא משנה מה יקרה עם online or not בעתיד - מקס כבר קיבל הרבה מעבר למה שהשקיע.
הדרך הנכונה להסתכל על פרויקט צד היא כמו תחביב או פעילות אקסטרה שאנחנו עושים כי זה נותן לנו משהו. לא כסף; משהו אחר. עכשיו אפשר להגיד "אין לי זמן לתחביבים", "יש לי כבר 5 כלבים וחתול שלוקחים לי את כל הזמן הפנוי" או "אני מתכנת כל היום בעבודה ומעדיף תחביבים אחרים". אין שום דבר רע בזה. אבל יש עוד דרכים להסתכל על זה:
בעבודה אני כותב דברים בטכנולוגיה X; פרויקט צד מאפשר לי לגלות טכנולוגיות חדשות.
בגלל שאני אוהב את הכלבים שלי אני נהנה לכתוב מוצרים שמשמחים אותם.
זה בטוח יותר מעניין מעוד בינג' בנטפליקס, ומשום מה כן היה לי זמן לראות את כל הסדרות האחרונות.
תחביב. שם עצם - זכר. עִסּוּק מְסֻיָּם שֶׁאָדָם עוֹסֵק בּוֹ מִתּוֹךְ חִבָּה וְעִנְיָן בִּשְׁעוֹת הַפְּנַאי מֵעֲבוֹדָתוֹ, עִסּוּק שֶׁלֹּא לְשֵׁם פַּרְנָסָה אוֹ רְוָחִים, “הוֹבִּי”: פְּלוֹנִי בַּעַל תַּחְבִּיב שֶׁל אִסּוּף בּוּלִים. הוּא עוֹסֵק בְּצִיּוּר כְּתַחְבִּיב.
.. שלוש שעות יותר מאוחר
... שבועיים יותר מאוחר
... שלושה חודשים יותר מאוחר
הרבה פעמים כשאנחנו מסתכלים על בעיה אנחנו מחפשים איזה פריימוורק פשוט שיוציא אותנו מהבוץ, ואז כשלא מוצאים מניחים שהעולם פשוט לא מספיק חכם או שהבעיה שלנו נורא מיוחדת. זה באמת המצב לפעמים אבל הרבה פעמים העובדה שכל הפיתרונות המוכנים מסובכים פשוט אומרת שהבעיה היא מסובכת. זה לא סוף העולם לפתור בעיות מסובכות, ויש שיגידו שזה אפילו כיף, אבל סיכוי טוב שהתוצאה של קידוד משהו קטן לבד לא תיגמר במשהו קטן. מצד שני בסוף התהליך יש סיכוי לא רע שתבינו הרבה יותר טוב למה כל הפיתרונות הקיימים כל כך מסובכים.
למה כתבת את השורה הזאת?
כי זאת הדרך שתמיד כתבתי כזה קוד
כי מצאתי את זה בגוגל
כי מצאתי את זה ב Stack Overflow
כי ראיתי את זה בסרט ביוטיוב
כי ראיתי מנגנון דומה במקום אחר במערכת
כי זה מה שהציע המתכנת הבכיר
כי זה מה שהציע החבר לידי
כי זה עבד
עכשיו מה יקרה אם תמחק אותה?
ואיך היה אפשר לכתוב את זה אחרת?
בשנים האחרונות אי אפשר להתעלם מהפופולריות של Frontend Frameworks ריאקטיביות. הרעיון הבסיסי הוא שבעוד שבתכנות "רגיל" כשאנחנו שמים תוצאה של ביטוי בתוך משתנה אז המשתנה מקבל את הערך החדש וזהו. אם בעתיד חלק מהאופרנדים בביטוי ישתנו זה לא ישפיע על אותו משתנה. בתכנות ריאקטיבי אנחנו שמים בתוך משתנה "ביטוי" וערכו של הביטוי מתעדכן אוטומטית כל פעם שהחלקים שלו מתעדכנים.
כדי לראות את הקושי במימוש מנגנון ריאקטיבי ב JavaScript נתבונן בקטע הקוד הבא:
const input = document.querySelector('input');
const output = document.querySelector('output');
output.value = input.value;
זה קוד לא ריאקטיבי שלוקח ערך של שדה קלט input אחד וכותב אותו לשדה output. כל מה שכתוב ברגע ריצת הקוד בשדה הראשון מועתק לשדה השני, אבל אם התוכן ישתנה בעתיד אז לא יהיה לנו שינוי מקביל בתיבת הטקסט השניה.
גירסה "ריאקטיבית" של הקוד היתה צריכה להמשיך ולעדכן את output כל פעם ש input מתעדכן. עכשיו אנחנו יכולים לכתוב קוד שיעשה את זה בעזרת אירועים:
const input = document.querySelector('input');
const output = document.querySelector('output');
input.addEventListener('input', () => {
output.value = input.value;
});
אבל לא היינו קוראים לגירסה המפורשת עם האירועים "ריאקטיבית", כי היא מפורשת מדי ומתירנית מדי. בתוך קוד האירוע אפשר לכתוב כל דבר ולא רק לשנות את הערך של output.
החלום של פריימוורקס ריאקטיביים ב JavaScript הוא לאפשר מעבר אוטומטי ושקוף מגירסת הביטוי לגירסת האירועים, בלי שנצטרך לבחור לאיזה אירוע להאזין ובלי שנצטרך למלא בעצמנו את קוד הטיפול באירוע.
התיאוריה של פריימוורק ריאקטיבי פשוטה: אם אני כול להחליף את document.querySelector ולייצר אוביקט שלי שעוטף את ה DOM Element, אני אוכל לזהות מתי מישהו מנסה לקרוא מידע משדה value שלי, ולייצר אירוע שיפעיל את הקוד הזה מחדש כל פעם שערך השדה מתעדכן. בפועל הפריימוורקים שבנו מנגנון כזה מסתבכים כל אחד במקרי קצה אחרים. הנה שתי דוגמאות פשוטות מ Vue ו MobX ואחריהן סיכום עם המלצה.