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

ואז מצאתי את המשפט הבא בתיעוד של Redux Toolkit:

With RTK Query, you usually define your entire API definition in one place. This is most likely different from what you see with other libraries such as swr or react-query, and there are several reasons for that. Our perspective is that it's much easier to keep track of how requests, cache invalidation, and general app configuration behave when they're all in one central location in comparison to having X number of custom hooks in different files throughout your application.

בתרגום וקיצור הם אומרים שהם בנו את RTK Query כי הרבה יותר קל לנהל תקשורת כשכל הקוד שמתעסק בה נמצא במקום אחד.

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

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