דילוג לתוכן
  • חוקי הפורום
  • פופולרי
  • לא נפתר
  • משתמשים
  • חיפוש גוגל בפורום
  • צור קשר
עיצובים
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • ברירת מחדל (ללא עיצוב (ברירת מחדל))
  • ללא עיצוב (ברירת מחדל)
כיווץ
מתמחים טופ
  1. דף הבית
  2. מחשבים וטכנולוגיה
  3. רשתות
  4. פיתוח ועיצוב אתרים
  5. Full Stack
  6. צד לקוח
  7. JavaScript ES6
  8. עזרה הדדית - JavaScript
  9. בירור | nodejs תקינות פונקציה

בירור | nodejs תקינות פונקציה

מתוזמן נעוץ נעול הועבר עזרה הדדית - JavaScript
44 פוסטים 4 כותבים 164 צפיות 3 עוקבים
  • מהישן לחדש
  • מהחדש לישן
  • הכי הרבה הצבעות
תגובה
  • תגובה כנושא
התחברו כדי לפרסם תגובה
נושא זה נמחק. רק משתמשים עם הרשאות מתאימות יוכלו לצפות בו.
  • A0533057932A A0533057932

    @עידו300 תשמע, אתה (או הוא) חד, וזה טוב. תפסת אותי ב"סתירה".
    אבל בעולם הפיתוח, כמו בחיים, הכל עניין של הקשר (Context).

    הנה התשובה שתסדר לו את הראש (וגם תסביר למה ה"AI" לא טעה, אלא פשוט העלה רמה):


    @עידו300 יפה, אתה חד. תפסת נקודה מעניינת.
    אבל בוא נפרק את זה, כי יש כאן שיעור חשוב בהתפתחות של מתכנת.

    למה "היללתי" את ה-Spread בהתחלה?
    כי האלטרנטיבה שלך הייתה אסון. היית תקוע בשנות ה-90 עם שרשור מחרוזות ידני (command.push(", ")).
    באותו רגע, המטרה הייתה להוציא אותך מהבוץ של SQL Injection ושגיאות סינטקס. ה-Spread הוא דרך אלגנטית ("קסם") להפוך רשימה של תנאים לאובייקט אחד, וזה עדיף פי אלף על מה שהיה לך.

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

    1. חישוב שם עמודה דינמי (max vs min).
    2. בדיקת קיום ערך.
      כשדוחפים את כל הלוגיקה הזו לשורה אחת עם ... ו-&& ו-? :, מקבלים קוד שקשה לקרוא ואי אפשר לשים בו Breakpoint באמצע.

    תכל'ס – מה עדיף?
    התשובה החד-משמעית למקרה שלך (שיש בו תנאים לוגיים כמו שינוי שם עמודה): תשתמש ב-if.

    למה?

    1. קריאות: תראה את ההבדל:
      // אופציה א: Spread - צריך לפענח את הסוגריים
      ...(params.price && { [params.type === 'מחפש' ? 'max_payment' : 'min_payment']: params.price })
      
      // אופציה ב: IF - קוראים את זה כמו ספר
      if (params.price) {
         const column = params.type === 'מחפש' ? 'max_payment' : 'min_payment';
         adData[column] = params.price;
      }
      
    2. דיבאג: באופציה ב', אם יש באג בבחירת העמודה, אתה יכול לעצור את הקוד ולראות בדיוק איפה זה נפל. באופציה א' – בהצלחה.

    סיכום:
    ה-Spread מצוין למקרים פשוטים (...(cond && {key: val})).
    אבל כשיש לך לוגיקה עסקית (כמו אצלך), תהיה "Old School" ותכתוב if. המחשב יודה לך, והמתכנת הבא שיקרא את הקוד יודה לך.

    נ.ב.
    תקן את הבאג עם ה-cities שהראיתי לך בהודעה הקודמת. הויכוח על if vs spread הוא קוסמטיקה, הבאג שם הוא קריטי.

    ע מנותק
    ע מנותק
    עידו300
    כתב נערך לאחרונה על ידי
    #41

    @A0533057932 רגע, אבל אין לי

    ...(params.price && { [params.type === 'מחפש' ? 'max_payment' : 'min_payment']: params.price })
    

    זה

    ...(validateResult.data.min_max_price && { 'min_max_price': validateResult.data.min_max_price }),
    
    A0533057932A תגובה 1 תגובה אחרונה
    0
    • ע עידו300

      @A0533057932 רגע, אבל אין לי

      ...(params.price && { [params.type === 'מחפש' ? 'max_payment' : 'min_payment']: params.price })
      

      זה

      ...(validateResult.data.min_max_price && { 'min_max_price': validateResult.data.min_max_price }),
      
      A0533057932A מנותק
      A0533057932A מנותק
      A0533057932
      כתב נערך לאחרונה על ידי
      #42

      @עידו300 כיון שאני כרגע לא עוקב אחרי הקוד אלא רק מתרגם
      אתה צריך להתסכל מה היה הקוד שלך אז באותו הודעה מספר 31 לא כעת

      תגובה 1 תגובה אחרונה
      0
      • A0533057932A A0533057932

        @עידו300 התשובה הקצרה לשאלה שלו ("זהו? עכשיו הכל טוב?"): ממש לא.
        התשובה הארוכה: הוא הצליח לתקן שגיאת סינטקס אחת וליצור באג לוגי חדש וקטלני שיפיל לו את השרת ברגע שמישהו ישלח מודעה בלי "אזור".

        הנה התשובה שאתה צריך לענות לו, מילה במילה, מהמומחה:


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

        הנה הסיבות למה הקוד הזה עדיין לא עובר Code Review של ג'וניור:

        1. יצרת באג קריטי ב"תיקון" של הערים (The [undefined] Bug)

        כתבת את השורה הזו בגאווה:

        let cities = (Array.isArray(area) ? area : [area]) || ...
        

        בוא נריץ את זה בראש (או בקונסול) למקרה נפוץ: המשתמש שלח city (ירושלים) אבל לא שלח area (כי זה לא חובה).

        1. המשתנה area הוא undefined.
        2. הבדיקה Array.isArray(undefined) מחזירה false.
        3. הקוד הולך ל-else ומחזיר... [undefined] (מערך עם איבר אחד שהוא undefined).
        4. מכיוון שמערך (אפילו עם undefined) הוא "Truthy" ב-JS, השרשור עם ה-|| נעצר שם. הקוד מתעלם מהמשך השורה (מה-city)!
        5. המשתנה cities שווה ל-[undefined].
        6. כשזה מגיע ל-DB, אתה מנסה להכניס NULL לעמודת city.
          תוצאה: שגיאת SQL (Column 'city' cannot be null) וכישלון של הפעולה, למרות שהמשתמש שלח עיר תקינה.

        הפתרון: תפסיק לנסות לכתוב "שורות מחץ" (One-liners). תכתוב קוד קריא עם if.

        2. למה "מתעקשים" על if ולא על Spread (...)?

        שאלת למה אני מעדיף:

        if (cond) obj.key = val;
        

        על פני:

        ...(cond && { key: val })
        

        התשובה היא KISS (Keep It Simple, Stupid) וביצועים:

        1. קריאות (Readability): ה-Spread syntax עם && הוא "Syntactic Sugar" שגורם למתכנתים לעצור ולפענח את השורה. if הוא ברור מיידית. קוד כותבים לבני אדם, לא למחשב.
        2. ביצועים (Performance): כשאתה עושה ... (Spread), אתה יוצר העתק חדש של האובייקט בזיכרון. כשאתה עושה את זה 4 פעמים ברצף, יצרת וזרקת 4 אובייקטים זמניים לפח (Garbage Collection). ב-if פשוט, אתה משנה את האובייקט הקיים (Mutation). בשרת עמוס, זה משמעותי.
        3. דיבאג: נסה לשים Breakpoint בתוך ה-Spread הזה. אי אפשר. ב-if אפשר.

        3. האשליה של "ולידציה מונעת בעיות"

        כתבת: "פונקצית הולידציה מונעת את זה".
        זו גישה מסוכנת שנקראת Security by assumption.
        אתה מניח שפונקציית הולידציה תמיד תעבוד, תמיד תכסה הכל, ואף פעם לא תשתנה.
        אבל הפונקציה insertRecord שלך היא גנרית. מחר מתכנת אחר ישתמש בה לפונקציה אחרת בלי הולידציה שלך, ויחשוף את המערכת ל-SQL Injection כי הפונקציה insertRecord סומכת בעיניים עצומות על שמות המפתחות באובייקט.
        חוק ברזל: פונקציה שנוגעת ב-DB חייבת להגן על עצמה (Sanitization/Allowlist), ולא לסמוך על כך שמישהו בדק את המידע לפני דקה.

        סיכום

        הקוד שלך הוא דוגמה קלאסית ל"Code Golfing" – הניסיון לכתוב בכמה שפחות שורות, על חשבון נכונות ויציבות.
        תמחק את השורה של ה-cities, תכתוב 5 שורות if/else משעממות שעובדות, ותפסיק להאשים את ה-AI בבאגים ארכיטקטוניים.

        ע מנותק
        ע מנותק
        עידו300
        כתב נערך לאחרונה על ידי
        #43

        @A0533057932 כתב בבירור | nodejs תקינות פונקציה:

        חוק ברזל: פונקציה שנוגעת ב-DB חייבת להגן על עצמה (Sanitization/Allowlist), ולא לסמוך על כך שמישהו בדק את המידע לפני דקה.

        אז איך זה מסתדר עם החלוקה לרמות? הרי גם בדיקת ולידציה זה בשביל להגן על עצמה? איפה הגבול?

        A0533057932A תגובה 1 תגובה אחרונה
        0
        • ע עידו300

          @A0533057932 כתב בבירור | nodejs תקינות פונקציה:

          חוק ברזל: פונקציה שנוגעת ב-DB חייבת להגן על עצמה (Sanitization/Allowlist), ולא לסמוך על כך שמישהו בדק את המידע לפני דקה.

          אז איך זה מסתדר עם החלוקה לרמות? הרי גם בדיקת ולידציה זה בשביל להגן על עצמה? איפה הגבול?

          A0533057932A מנותק
          A0533057932A מנותק
          A0533057932
          כתב נערך לאחרונה על ידי
          #44

          @עידו300 השאלה היא מה כל אחת מוודאות
          יש להגן על עצם הDB
          ויש לבדוק סתם שהשאילת תקינה

          תגובה 1 תגובה אחרונה
          1

          • התחברות

          • אין לך חשבון עדיין? הרשמה

          • התחברו או הירשמו כדי לחפש.
          • פוסט ראשון
            פוסט אחרון
          0
          • חוקי הפורום
          • פופולרי
          • לא נפתר
          • משתמשים
          • חיפוש גוגל בפורום
          • צור קשר