Wagmi ב-React: הגדרת הוקים, מיגרציה ל-v2 ואופטימיזציה

אינטגרציית wagmi נשברת בחיבור ארנק ובהחלפת רשת

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

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

הכשל השני — כפילות בקשות. כמה קומפוננטות נרשמות לאותו מקור מצב, וכל אחת מפעילה בקשה משלה לצומת: יתרה, הרשאות ורשימת טוקנים נמשכות שלוש-ארבע פעמים בהחלפת רשת אחת. הצומת מגיב בהגבלת קצב פניות, הממשק — בהשהיה של כמה שניות, ובלוגים רואים סערת קריאות זהות.

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

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

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

מה משתנה אחרי הגדרה מדויקת של ספקים והוקים

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

פסילת המטמון מוגדרת במפורש — לפי החלפת כתובת, רשת או סיום עסקה, — ולכן הנתונים לא נתקעים ולא מפגרים אחרי מצב השרשרת. הגדרת Wagmi מעל viem מסירה בדיקות ידניות: הספקים מוצהרים פעם אחת, וההוקים מקבלים הקשר עקבי במקום עשרה מצבי מקום. התנהגות בזמן הרכבה מוגדרת בנפרד, כדי שניווט בין עמודים לא יפתח חיבורים מיותרים.

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

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

דרכי אינטגרציה של wagmi: השוואת אפשרויות חיבור

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

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

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

סדר העבודות: מביקורת קונפיגורציה ועד מסירת הסכמה

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

1. ביקורת שכבת החיבור. ספקים, סט רשתות וארנקים, נקודות קריאת מצב בעקיפין לקונפיג. מודדים מספר בקשות לצומת בטעינה ובהחלפת רשת — מאוחר יותר זה משמש נקודת השוואה.
2. סכמת שכבות. מפרידים קונפיגורציה, לקוח בקשות, הוקים וקומפוננטות, ומתארים קשרים ביניהם. מתאמים לפני קוד: אחרת העברת הוקים גוררת אחריה כתיבה מחדש של ממשקים.
3. הגדרת תעבורות. כתובות צומת ראשית וגיבוי, סדר מעבר בעת כשל, הגבלת ניסיונות חוזרים, מטמון לקריאה. קונפיג wagmi הופך למקום היחיד שבו חיים רשתות והפרמטרים שלהן.
4. העברת הוקים. קודם קריאה — יתרות, הרשאות, סטטוסים; אחר כך כתיבה — אישורים ושליחה. כל שלב בודקים בנפרד, והקריאה הישנה עובדת במקביל לזמן מה.
5. בדיקת תרחישים. כשל צומת, חתימה שנדחתה, החלפת חשבון או רשת באמצע פעולה, בקשות במקביל. מצפים לחזרה ברורה של הממשק במקום מסך תקוע.
6. מסירת נהלים. מפת שכבות, קונפיג עם הסברים, סדר הוספת רשת חדשה, הוראות חזרה לסכמה הקודמת.

כל תיקון נשאר בגבולות השכבה שלו — שינוי בהוק אחד כבר לא שובר חתימה במקום אחר.

מה נשאר בפרויקט: סכמות שכבות, קונפיגורציה ונהלים

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

• מפת תלויות — מה מחובר, לשם מה בדיוק, אילו חבילות קשורות זו לזו ומה אפשר לעדכן באופן עצמאי.
• סכמת שכבות — היכן חיה קונפיגורציית החיבור, היכן ההוקים, היכן התצוגה: מיד רואים מה מושפע מהחלפת ארנק או רשת.
• קונפיגורציית חיבור — רשימת רשתות וספקים, סדר עדיפות, התנהגות כשאין צומת וזמני פסק זמן.
• תיעוד הוקים — ייעוד, ערכי קלט ופלט, מטמון, תופעות לוואי ומקומות שבהם מתרחש רינדור מיותר.
• מדיניות טיפול בשגיאות — סוגי כשלים, ניסיונות חוזרים, מה המשתמש רואה, מה נכנס ללוגים ולהתראות, ומה נכבה בשקט.
• נוהל עדכון — סדר מעבר לענף מאג'ורי חדש של הספרייה, צ'קליסט בדיקות וקריטריוני חזרה לריליס הקודם.
• מתאר בדיקות — ספק מדומה וסט תרחישים שעליהם מריצים שינויים עד לפרודקשן.

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

מקרה בוחן: שכבת החיבור נכתבה מחדש והוסרו בקשות מיותרות

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

שיעור הפניות החוזרות לצומת הגיע ל-40%, וכמעט כל בקשה שלישית לתמיכה החלה ב"היתרה לא התעדכנה".

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

ההגירה לענף המאג'ורי הנוכחי בוצעה בלי לעצור שחרורים — הוקים הוחלפו מסך-מסך ושתי המימושים נשמרו זה לצד זה עד שהבדיקות התיישבו.

מה זז: שיעור הפניות החוזרות ירד מ-40% ל-7%, זמן ההתאוששות אחרי כשל צומת — מחצי שעה של החלפות ידניות לארבע דקות של מעבר אוטומטי. פניות לתמיכה בעקבות אי-סנכרון ירדו מתשעים לשתים עשרה בחודש.

סוג הכשלים גם הוא השתנה. במקום פערים בין מסכים ומצבים תקועים נשארו כשלים של חיבור חיצוני — הם נראים בלוגים מיד ולא דורשים אבחון ידני. בזה גם המשמעות המעשית של ההגירה: החיבור הפסיק להיות מקור לשגיאות אקראיות.

מה לעשות אם הפרויקט כבר על גרסה מאג'ורית ישנה

כן, מעבר לגרסה מאג'ורית חדשה של wagmi אפשר לעשות בשלבים — אבל לא עם שתי עותקים של הספרייה באותה בנייה. החבילה אחת, ושתי גרסאות מתנגשות על הקונטקסט של הספק: קומפוננטות מקבלות פעם לקוח אחד ופעם אחר, והשגיאות יוצאות צפות.

סכמה עובדת — להרים שכבה חדשה לצד הקיימת ולחבר אותה לפי מודולים או נתיבים, ולא בבת אחת על כל האפליקציה.

סדר הסגירה נקבע לפי מחיר הטעות. ראשונה הולכת הקונפיגורציה: createConfig עם תעבורות מפורשות במקום configureChains הקודם. אחריה — קריאה, useReadContract במקום הוקי קריאה ישנים: השכבה הזו כמעט לא מחזיקה מצב, ולכן עוברת בלי סיכון לתרחישי משתמש.

אחר כך כתיבה: useWriteContract יחד עם useSimulateContract — סימולציה לפני שליחת עסקה מפחיתה שיעור היפוכים וכשלים בגז, ואסור להעביר כתיבה בחבילה בלי זה. את התור סוגרים ארנק ורשת: קונקטורים בקונפיג, chain ו-useSwitchChain במקום useNetwork, שאינה קיימת בענף החדש.

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

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

ספקות טכניים: מטמון, פירוק, החלפת רשת

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

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

למה הארנק מבקש חתימה פעמיים?

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

מה לעשות באי-סנכרון אחרי החלפת רשת?

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

איך האינטגרציה מתנהגת בעת ניתוק רשת?

בקשות חוזרות בהשהיה גדלה, ובחזרת החיבור המצב נשאל מחדש מעצמו. הצבת הספק ברמה העליונה לא שוברת קומפוננטות קיימות.

נדון במשימה: מה לשלוח להערכה ולתוכנית עבודה

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

• קישור לריפוזיטורי או ארכיון של חלק הפרונטאנד: מעניינת אותנו התיקייה עם חיבור הארנקים ומבנה הספקים;
• קבצי תלויות עם גרסאות נעולות — מהם רואים על איזה ענף של הספרייה בנויה האינטגרציה הנוכחית של wagmi ומה יצטרכו לגרור אחריה;
• רשימת הרשתות הנתמכות ודרכי הגישה אליהן (צמתים ציבוריים, משלנו, גיבוי) — בלי המפתחות עצמם;
• תיאור ההוקים הנוכחיים: היכן נקראים יתרות ומצב חשבון, היכן נכתב לחוזים, איך מטופלים טעינה, שגיאה ובקשה חוזרת;
• רשימת התרחישים שכבר נשברים או מאטים: אובדן חיבור, החלפת רשת, בקשות במקביל, כניסה חוזרת;
• דרישות לרינדור בצד שרת ולמטמון, אם האפליקציה מגישה מרקאפ מוכן;
• רשימת הקבלה הנוכחית או בדיקות, אם יש.

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

הצעד הבא פשוט: שולחים את מה שיש, אנחנו מנתחים ומסכמים שיחה עניינית — מה עושים ראשון, מה אפשר לדחות, והיכן אנחנו מסתכנים.