JavaScript Interop

הסקירה

קריאת מתודה של JavaScript מתוך קוד ClojureScript מפעילה ישירות פונקציות שמובנות באוספים של השפה. הפונקציות היציבות הרשמיות שחשופות לשימוש חיצוני מוגבלות מאוד, וכוללות רק את indexOf ואת lastIndexOf עבור אוספים סדרתיים. אתם מעבירים להן אוסף שעונה לתנאי sequential, ערך לחיפוש, ואינדקס התחלתי אופציונלי. אם הערך נמצא, תקבלו את המיקום שלו במספר שלם, ואם לא, הפונקציה מחזירה 1-. החיפוש בברירת המחדל רץ מתחילת האוסף בראשונה, או מסופו באחרונה. המנגנון הזה עובד ישירות מול המנוע של הדפדפן או הסביבה שבה אתם רצים, בלי שכבות תיווך כבדות.

זה לא עובד על קסמים.

היכולת להריץ קוד חיצוני נשענת על מנגנון תמיכת המודולים של המהדר, שמסומן באתר הרשמי כגרסת אלפא. המהדר Google Closure ממיר מודולים נפוצים של JavaScript לתוך מודולים פנימיים שלו, כדי לכלול אותם בתוך מיטוב הקוד ולחסוך הגדרות externs ידניות. כדי לחבר ספרייה חיצונית לפרויקט, אתם מוסיפים אותה בהגדרת foreign-libs בקובץ התצורה. שם תצטרכו לציין את נתיב הקובץ, השם שהוא מספק תחת מפתח provides, וסוג המודול תחת module-type. המערכת תומכת בשלושה סוגים רשמיים, שהם CommonJS, AMD וכן ECMAScript 6, לפי הערכים המתאימים בהגדרות הקומפילציה.

התאמת מודולים ומגבלות המהדר

אחרי שהגדרתם מודול חיצוני תחת provides עם שם מסוים, אתם מייבאים אותו אל תוך מרחב השמות בקוד שלכם באמצעות דרישת require רגילה. השימוש בו זהה לשימוש בספריות המובנות מתוך Google Closure Library, כמו קריאה לפונקציות חיבור או חיסור דרך הכינוי שבחרתם. זה שווה את זה רק אם ספריות הקוד שלכם עומדות בדרישות הנוקשות של Google Closure. המהדר דורש עמידה בהגבלות מחמירות ברמות האופטימיזציה simple וגם advanced. אם המודול שכתבתם לא עומד בדרישות האלה, המהדר יכשיל את הבנייה של כל הפרויקט.

המחיר קופץ בסיבוכיות.

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

בעיות תאימות וסביבת ריצה

מודולים שנכתבו עבור Node.js מעמידים בעיה גדולה נוספת שהתיעוד מפרט בבירור. המפרט של Node.js מאפשר מזהי מודולים שאינם נתיב יחסי או מוחלט בתוך פקודת require, בניגוד לתקן CommonJS הסטנדרטי שעליו נבנה המהדר. בגלל ההבדל הזה, Google Closure מתקשה לפענח תלויות של חבילות Node.js טיפוסיות, ולעיתים קרובות אינו מסוגל להמיר אותן כלל. לא הייתי משתמש בזה לפרויקט שמסתמך בכבדות על חבילות מודרניות מתוך המערכת האקולוגית של npm ללא בדיקת תאימות מוקדמת. כל חבילה חיצונית דורשת בדיקה נפרדת מול רמות המיטוב הגבוהות.

תמיכה בעברית אינה מוזכרת.

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

• מחיר שימושלא צוין באתר
• סטטוס מודוליםמוגדר כגרסת אלפא
• אופטימיזציית קודכולל Google Closure