פשוט מחקתי מאות שורות קוד שכתבתי אתמול והחלפתי אותן ב-32 שורות קוד חדש. זה היה עבור תכונה עבור   , המשמשת לציון אם שמע מתנגן. TheOpenPresenter  כל כמה זמן, הייתי עובד על פונקציונליות שנראית די פשוטה ליישום. במקרה זה, אני רק צריך להציג את הסמל הזה כאשר השמע מתנגן.   פשוט מספיק. כל אחד מאלה הוא סצנה המכילה מספר תוספים. לכל תוסף יש מאפיין משלו כמו   . נוכל למזג את הערכים בין התוספים, ואם הדגל נכון, נוכל להציג את הסמל. isPlaying  בניית פתרון  הבעיה העיקרית היא איך לגשת לנתונים האלה. תראה, נוכל לגשת ישירות לנתונים. אבל לכל תוסף יכול להיות סכימה משלו. בעוד שחלק מהפלאגינים עשויים להיות בעלי מאפיין   פשוט, חלק אחרים עשויים להזדקק למשהו מסובך יותר כדי לייצג את סטטוס המשחק שלו. isPlaying  פשוט, למה לא לאפשר לפלאגין לרשום התקשרות חוזרת/פונקציה שמחזירה את המצב?  זהו אותו דפוס שבו משתמש TheOpenPresenter עבור רבים מהפלאגינים שלו. ובזמן שאנחנו בזה, אנחנו יכולים להפשט את זה לאובייקט   . אז אם אי פעם נצטרך מדינה אחרת, נוכל להוסיף אותה כאן. כך זה עשוי להיראות עבור הפלאגין: SceneState   // The pattern we use for plugins serverPluginApi.onPluginDataCreated(pluginName, onPluginDataCreated); serverPluginApi.onPluginDataLoaded(pluginName, onPluginDataLoaded); serverPluginApi.registerRemoteViewWebComponent( pluginName, remoteWebComponentTag, ); // Example of how the new API might look like serverPluginApi.registerSceneState( pluginName, (_, rendererData) => { return { audioIsPlaying: !!rendererData.find((x) => x.isPlaying), } }, );  טיפול בשרת  שימו לב שהקוד למעלה מטופל בשרת. הסיבה לכך היא ש-TheOpenPresenter מורכב מ-3 רכיבים נפרדים:  השלט - היכן מוצג חיווי האודיו הזה  The Renderer - מנגן את האודיו  השרת - מחבר בין השניים  באופן אידיאלי, עלינו לטפל בזה ב-frontend (מרוחק) כדי שלא נוסיף עומס נוסף לשרת. עם זאת, רישום פונקציה זו עשוי להיות מבולגן. החזית שלנו משתמשת בארכיטקטורת מיקרו-חזית העמוסה ברכיבי אינטרנט.  האזור האדום למטה הוא מעטפת React. השטח הירוק נטען באמצעות רכיבי אינטרנט ומנוהל על ידי כל תוסף.   שימו לב שסמל השמע ממוקם בצד שמאל של המעטפת. כיצד אנו מספקים את הפונקציה שאנו צריכים למעטפת? אנחנו יכולים לכלול פונקציית JS בחבילת רכיבי האינטרנט אבל זה נשמע כמו בלגן בטווח הארוך.  טיפול זה בשרת נראה כמו הדרך הנכונה לעשות זאת.  אינסטלציה של הנתונים דרך  לאחר שהוחלט, הגיע הזמן ליישום. יש כמה דברים לעשות:  צור את ה-API של הפלאגין  ספק את הנתונים האלה ל-frontend  צרוך ועדכן את ממשק המשתמש  יישום  אני לא אשעמם אותך בפרטים אז הנה סקירה כללית. ה-API לא היה ממש פשוט מכיוון שהנתונים שלנו יכולים להיות די מבלבלים. בקיצור: סצנה יכולה לכלול מספר תוספים. ויכולים להיות מעבדים מרובים, כל אחד צופה בסצנה בצורה שונה. אז לפלאגין יכולים להיות מעבדים מרובים שמציגים אותו בדרכים שונות. אבל עם קצת מניפולציה של נתונים, הבעיה נפתרה.   צריכת ועדכון ממשק המשתמש  צריכת הערך הייתה פשוטה. שקלתי להשתמש בפרוטוקול המודעות של Yjs כדי לספק את הנתונים מכיוון שהם בזמן אמת והמסגרת כבר קיימת. כך נשמרת המדינה. עם זאת, הכללת נתונים אלה מהשרת היא בעיה משלו. אז החלטתי להשתמש במקום זאת ב-GraphQL - הפרוטוקול שבו אנו משתמשים עבור כל השאר בפלטפורמה.  אז כל מה שאנחנו צריכים לעשות הוא להתקשר לנקודת הקצה, להאזין לה באמצעות המנוי של GraphQL, ולהראות את הסמל לפי הצורך. נַעֲשָׂה.   מתן נתונים אלה ל-frontend  למרבה המזל, אנו משתמשים   מה שהופך את הרחבת סכימת GraphQL לפשוטה למדי. אנחנו יכולים גם להפוך אותו למנוי פשוט על ידי הוספת   לסכימת GraphQL. לאחר מכן הוא יצפה בנושא ויעדכן את הערך בכל פעם שנתקשר ל-   בנושא זה. לְדוּגמָה: ב-Postgraphile @pgSubscription pg_notify   await pgPool.query( `select pg_notify('graphql:sceneState:${id}','{}');`, [], );  מניפולציה של הנתונים הייתה מעצבנת אבל רק קצת סבלנות וזה נעשה!  החלק האחרון בפאזל הוא קריאה   כשצריך. pg_notify  לשם כך, אנו יכולים להוסיף מאזין למדינה (Yjs) ולהתקשר להודעה בכל פעם שמשהו משתנה:   state.observeDeep(async () => { // Call pg_notify here });  הדבר היחיד שנותר לעשות הוא שיפורי ביצועים. כרגע, הפונקציה נקראת עבור כל שינוי קטן, היא גם מתעדכנת ל-frontend. אנו יכולים לחשב את המצב המתקבל ולהשוות אם משהו משתנה לפני דחיפה של העדכון.  פתרון טוב יותר  עכשיו הפתרון הזה בהחלט עובד. אבל שנאתי שאנחנו מקשיבים לכל שינוי. זה מיותר ואני לא בטוח איך הביצועים יסתכמו. האם יש פתרון טוב יותר?  אז צעדתי אחורה לשנייה והגיע רעיון:  מה דעתך שנלך ליסודות ונשתמש בנתונים מ-Yjs?  הבעיה הייתה שכל תוסף עשוי להשתמש בדרכים שונות כדי לציין סטטוס הפעלה. אז היינו צריכים דרך לדעת איך לחשב את המצב שנוצר בעצמנו. אבל במקום לאפשר למשתמש להעביר פונקציה,  למה לא לשמור מאפיין שהוא יכול להשתמש בו כדי לציין זאת?  במקום להעביר פונקציה לחישוב המצב, כל תוסף יכול להגדיר את המצב השמור ישירות לצד הנתונים הקיימים שלו עם מאפיינים כמו   . הם יכולים להשתמש בערך זה ישירות, או שהם יכולים לשמור אותו מסונכרן עם המאפיינים הקיימים שלהם, כך: __audioIsPlaying   const onRendererDataLoaded = ( rendererData, ) => { watchYjs( // Watch the isPlaying property (x) => x.isPlaying, () => { // And if it changes, sync the __audioIsPlaying property rendererData.set("__audioIsPlaying", rendererData.get("isPlaying")); }, ); };  מוחק קוד ישן  השיטה החדשה מבריקה. אין מאזין נוסף, אין API נוסף, רק נכס שמור פשוט.  העלות? ובכן, כבר כתבתי 95% מהיישום הראשון 🫣     "זה יהיה כל כך חבל למחוק את זה כשעבדתי על זה כל כך הרבה זמן. כל השאר מושלם מלבד הדבר האחד הזה!" - המוח שלי  זו לא הפעם הראשונה שלי. גם לא שני או שלישי. הפעם זה היה רק כמה שעות של עבודה. ככל שלוקח יותר זמן ליישם, כך קשה יותר להרפות. אבל אם אנחנו לא צריכים להיות מחוברים לשרתים, אנחנו גם לא צריכים להיות מחוברים לקוד שאנחנו כותבים.  ברור שהיישום השני טוב יותר. זה מהיר יותר, פחות חלקים נעים, פחות משטח API ופחות קוד לתחזוקה.   הוסיף 289 שורות חדשות ואילו   הוסיף רק 32 שורות חדשות. היישום הראשון היישום השני   אז מה הלקח שצריך ללמוד?  ובכן, אולי תמצא קודם את הפתרון הפשוט ביותר. אבל לפעמים אנחנו לא מגיעים לפתרון הטוב ביותר רק על ידי חשיבה על זה. אם זה המקרה,   . ואולי תכתוב פוסט בבלוג כדי שתפיק מזה משהו! אל תאהב את הקוד שלך ואל תפחד לזרוק אותו  אם קראת עד כאן, אולי תרצה לנסות   ! זוהי מערכת מצגות בקוד פתוח המאפשרת לך לשלוט בכל אחד מהמסכים שלך מרחוק. את TheOpenPresenter  הצג מצגות, הפעל סרטונים, השתמש כלוחות מחוונים ועוד רבים נוספים. התוכנה עדיין בשלב מוקדם מאוד בפיתוח כפי שניתן לראות מפוסט זה, אך היא יציבה מספיק לשימוש קבוע. אני אישית משתמש בו למפגשים שלי מדי שבוע.  כל שאלה, תשאל. או אל תהסס לדווח על בעיות   . בריפו של Github

2022 - HackerNoon Contributor of the Year - Developer

Read My Stories

Nominated for 2022 - HackerNoon Contributor of the Year - Developer

האודיו הזה מופק בשפת המקור של הסיפור!

התאהבתי בקוד שלי, ואז הייתי צריך להרוג אותו

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/18/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/20/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/14/2024)

ברכות עונות מ-HackerNoon: Boost Stories עם תרגומים, דיבור לטקסט ועוד

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/18/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/20/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/14/2024)

ברכות עונות מ-HackerNoon: Boost Stories עם תרגומים, דיבור לטקסט ועוד

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps