Зарем не би било одлично ако целиот код со кој работиме е напишан на начин да е целосно јасно што прави? И дa можеме лесно да направиме промени без да го скршиме? Звучи добро, но не е така лесно да се направи. За да дојдеме до тоа ниво, треба малку да го смениме нашиот начин на размислување.
Апликациите во React растат многу брзо. Проектот добива се повеќе компоненти, кодната база расте, и токму кога мислите дека завршивте со компонента и заборавате на тоа, постојат барања за промена на истата. Го анализирате кодот на таа компонента, се обидувате да разберете што имал на ум авторот, дури и ако авторот сте вие и се сопнувате на услов за кој немате идеја зошто е ставен таму.
Се обидувате да разберете зошто тој услов е таму и која употреба може да ја активира таа патека, а тоа трае некое време. Може ли да се избегне сето тоа? Да, барем делумно. Како React девелопер, со или без искуство, секојдневно се среќаваме со овие ситуации. Што можеме да направиме за да го подобриме квалитетот на кодот и да ги направиме нашите компоненти повеќекратно употребливи и одржливи?
Подобрете го именувањето
Именувањето може да го подобрите со анализа на тоа како библиотеките што ги користите го именувале и дизајнирале API што го трошите. Понекогаш имаме тенденција да користиме имиња кои се премногу описни, а вие (најверојатно) нема да видите такви случаи во библиотеките што ги користите. Кога ги именуваме функциите или променливите, ги поставуваме овие прашања:
● Кое би било најинтуитивно (наместо најописно) име за ова?
● Дали постои стандард? Ако секој ја именува променливата „i“, а јас ја именувам „x“, тоа може да биде збунувачко
● Дали е јасно што претставува?
● Колку информации можам да извлечам од контекстот во кој се наоѓа мојата променлива? Ако е јасно дека променливата е поврзана со контекстот во кој се наоѓа, нема потреба да се повторуваат тие информации во името на променливата. (User.id наместо User.userId)
● Едноставноста и интуитивноста на името го прават кодот читлив. Лесниот за читање код е и полесен за разбирање, а со тоа и полесен за одржување.
Примери:
filterWhenTimeUpdates() → filter()
Кога ажурирањето на времето е настан на кој ќе одговориме со повикување на функцијата за филтрирање. Во кодот може да биде нешто како ова:
useEffect(filter, [time]); Што јасно кажува дека ќе го активираме филтерот секогаш кога ќе се ажурира времето
shouldFetchNewData → shouldFetch
Веројатно нема да имате случај кога преземате стари податоци
hourOfDay → hour
Автоматски би ставиле еден час во контекст на денот
allComments → comments
Се користи со исто значење како и само коментари. Обично, кога низите се филтрираат, низата не ја мутираме.
useLayout({ useLayout({
columns, columns,
rows, → rows,
spacing spacing
}); }, [columns, spacing]);
Можеме да ја позајмиме идејата од вградени React hooks и да ги дизајнираме нашите custom hooks на ист начин. Може да пренесеме листа на зависности од нашиот custom hook како посебен параметар. На овој начин, во едната компонента може да се активира овој hook само на Mount, додека во другата компонента може да се активира секогаш кога податоците од колоната или редовите се менуваат. Бидејќи ја предаваме листата на зависности како посебен параметар на ист начин како што прават вградените hooks, за React девелоперите ќе биде интуитивно каква беше нашата намера.
Не ставајте (многу) логика во JSX
Компонентата ќе биде полесна за одржување доколку делот JSX или Презентацискиот дел на компонентата содржи што е можно помалку логика. Ако имавме потреба од рефакторирање или модифицирање на компонентата поради некоја причина, би можеле да го сториме тоа многу побрзо ако најголемиот дел од логиката доаѓа од делови што не се во JSX на апликацијата.
Reuse Selector pattern idea
Ако сте работеле со Redux, веројатно сте слушнале за Selector pattern. Овој pattern го намалува напорот што треба да го вложиме кога се менува структурата на податоците. Селекторот е едноставна функција што прима некои податоци и враќа само (избран) дел од тие податоци.
Структурите на податоците имаат тенденција да се менуваат во раните денови на развој. Кога тоа ќе се случи, ако го користиме селекторот наместо да пристапуваме директно до податоците во нашите компоненти, треба да направиме само една промена. Таа промена би била внатре во селекторот. Ако не го користевме селекторот, ќе мораше да направиме промени на секое место до каде се пристапуваше директно до податоците.
Што ако правиме нешто слично насекаде во нашите компоненти?
Ако не зависиме од структурата на податоците или од изворот од каде потекнуваат тие податоци, секоја промена што ќе се случи ќе биде лесна за спроведување. Целта е да се направат промени само на едно место.
Како можеме да го постигнеме ова?
Можеме да напишеме селектори и / или да користиме деструктурирање на предмети и низи. Забележете дека ова зафаќа повеќе меморија, но кодот станува полесен за одржување.
Коментирајте го вашиот код
Веројатно прочитавте дека коментарите се лоши и дека кодот треба да биде само-документирачки. Мислиме дека кодот не може да каже сè. Постојат толку многу ситуации кога немаме идеја ЗОШТО програмерот напишал некое парче код. Да не мешаме со ШТО прави кодот затоа што можеме да го читаме и разбереме. Она што не можеме да го знаеме е кои случаи на употреба ги имал во предвид девелоперот кога е напишан кодот. Можеби ќе скршиме нешто ако го измениме тој код. Може да има некои деловни правила што не можат да се објаснат со код или барем лицето кое го напишало кодот не успеало да го стори тоа. Ако авторот на кодот оставил коментари зошто тоа парче код е таму, тоа ќе го заштеди нашето време. Проблемот со коментарите е што тие обично не се одржуваат. Луѓето го модифицираат кодот, а не коментарот. Значи, коментарот завршува со лажни изјави. Одржувањето на коментарите е уште еден совет. Застоен коментар може да биде полош од тоа да нема коментар ако ве доведе во заблуда.
Вадење
Кога компонентата има повеќе од неколку стотици редови код, станува потешко да се прочита (претпочитамe да ја чувамe под 300 реда код). Почесто отколку што се случува кај помалите компоненти, редоследот на дефинирање на работите лесно се меша. Полесно е да се одржуваат логички единици кога компонентата е прилично мала. Kолку е поголема компонентата, толку поразреден ќе стане кодот.
Како можете да обезбедите вашите компоненти да останат мали? Со вадење! Можете да извлечете кориснички функции, прилагодени куки, нови компоненти, константи, декларации за типови и / или mock data за да ги одделите датотеките.
Организирање
Воспоставете правила кога станува збор за организирање код. Бидете сигурни дека секој директориум и секоја датотека се организирани на ист начин. Стремете се кон постојаност. Организираниот и конзистентен код ќе ги зголеми вашите перформанси бидејќи нема да мора да прелистувате низ целата датотека за да пронајдете нешто, ќе знаете точно каде да побарате на прво место.
Овие совети секогаш можеме да ги примениме во компонентите на React и да ги олесниме одржувањето и повторната употреба.
Quantox Technology е меѓународно позната компанија за аутсорсинг и развој на веб и мобилни апликации. Ние работиме според стандардите ISO 9001 во сите наши 10 канцеларии во 4 различни земји. Врвен и квалитетен пристап кон бизнисот нè доведе до над 120 успешно завршени проекти.
Одговорното однесување и грижата за клиентите и за вработените се наши основни вредности и нешто што ќе игра сè поважна улога во скоро секоја индустрија, во годините што доаѓаат.
Неодамна, Quantox Technology ја отвори својата канцеларија во Македонија. Имаме силен тим на React девелопери од неколку земји, бидејќи развиваме многу проекти во оваа технологија.
Ние сме посветени на правење клучни чекори за понатамошен раст во иднина.
Дали сакате да се сте дел нашиот тим?
https://quantox.com/careers?q_lang=mk