\n\/\/ \u010cesto nepotreban re-render: novi objekt na svaki render\n<UserCard style={{ padding: 10 }} \/>\n\n\/\/ Bolje: definirajte objekt izvan komponente ili koristite useMemo\nconst cardStyle = { padding: 10 };\n<UserCard style={cardStyle} \/>\n<\/pre><\/div>\n\n\n2. Ne pretjerujte s useEffect-om<\/h2>\n\n\n\n
useEffect<\/code> je jedan od naj\u010de\u0161\u0107e zloupotrijebljenih hookova. Mnogi ga koriste za sinkronizaciju state-a koji se mogao izra\u010dunati direktno tijekom rendera, \u0161to stvara nepotrebne dodatne render cikluse i bugove koji su te\u0161ki za debug.<\/p>\n\n\n\n\/\/ Lo\u0161e: state koji ovisi o drugom state-u, sinkroniziran kroz effect\nconst [fullName, setFullName] = useState("");\nuseEffect(() => {\n setFullName(`${firstName} ${lastName}`);\n}, [firstName, lastName]);\n\n\/\/ Bolje: derived state se ra\u010duna direktno\nconst fullName = `${firstName} ${lastName}`;\n<\/pre><\/div>\n\n\nuseEffect<\/code> rezervirajte za stvarnu sinkronizaciju s vanjskim sustavima – API pozivi, event listeneri, subscriptions, manipulacija DOM-om izvan Reacta. Ako se ne\u0161to mo\u017ee izra\u010dunati iz postoje\u0107ih props-a ili state-a tijekom rendera, nemojte to stavljati u effect.<\/p>\n\n\n\n3. Podignite state samo onoliko visoko koliko treba (state colocation)<\/h2>\n\n\n\n
\u010cesta gre\u0161ka je staviti sav state na vrh komponentnog stabla “da bude dostupan svima”, \u0161to uzrokuje da svaka promjena state-a re-renderira veliki dio aplikacije.<\/p>\n\n\n\n
Pravilo je jednostavno: state treba \u017eivjeti \u0161to bli\u017ee komponentama koje ga koriste. Ako samo jedna komponenta koristi neki podatak, taj state pripada njoj, ne roditelju tri razine iznad.<\/p>\n\n\n
\n\/\/ Lo\u0161e: state za otvaranje modala \u017eivi u root komponenti\nfunction App() {\n const [isModalOpen, setIsModalOpen] = useState(false);\n return (\n <>\n <Header \/>\n <ProductList \/>\n <Footer onContactClick={() => setIsModalOpen(true)} \/>\n {isModalOpen && <ContactModal onClose={() => setIsModalOpen(false)} \/>}\n <\/>\n );\n}\n\n\/\/ Bolje: state je lokaliziran u Footer komponenti koja ga koristi\nfunction Footer() {\n const [isModalOpen, setIsModalOpen] = useState(false);\n return (\n <>\n <button onClick={() => setIsModalOpen(true)}>Kontakt<\/button>\n {isModalOpen && <ContactModal onClose={() => setIsModalOpen(false)} \/>}\n <\/>\n );\n}\n<\/pre><\/div>\n\n\n4. Koristite key prop ispravno – nikad index kao zamjenu za ID<\/h2>\n\n\n\n
key<\/code> prop poma\u017ee Reactu da prepozna koji se element u listi promijenio, dodao ili uklonio. Kori\u0161tenje array indexa kao key-a izgleda bezopasno, ali stvara probleme \u010dim se redoslijed liste promijeni – input vrijednosti, animacije i lokalni state komponenti mogu se “zalijepiti” na pogre\u0161ne stavke.<\/p>\n\n\n\n\/\/ Rizi\u010dno: index kao key\n{items.map((item, index) => (\n <TodoItem key={index} item={item} \/>\n))}\n\n\/\/ Sigurno: stabilan, jedinstven identifikator\n{items.map((item) => (\n <TodoItem key={item.id} item={item} \/>\n))}\n<\/pre><\/div>\n\n\nIndex kao key je prihvatljiv samo ako je lista stati\u010dna, nikad se ne sortira, filtrira ili mijenja redoslijed – \u0161to je u praksi rijetko.<\/p>\n\n\n\n
5. Razbijajte velike komponente prema odgovornosti, ne prema veli\u010dini<\/h2>\n\n\n\n
Komponenta od 400 linija nije nu\u017eno problem zbog du\u017eine, nego zbog toga \u0161to vjerojatno radi previ\u0161e stvari – dohva\u0107a podatke, upravlja formom, prikazuje UI i obra\u0111uje logiku validacije, sve u jednoj funkciji.<\/p>\n\n\n\n
Korisno pitanje: “Ako obja\u0161njavam \u0161to ova komponenta radi, koristim li rije\u010d ‘i’?” Ako da (“dohva\u0107a podatke i<\/strong> prikazuje listu i<\/strong> upravlja filterima”), vjerojatno je vrijeme za podjelu – bilo na manje komponente, bilo izdvajanjem logike u custom hookove.<\/p>\n\n\n\n\/\/ Umjesto jedne velike komponente\nfunction ProductsPage() {\n \/\/ dohva\u0107anje podataka, filtriranje, sortiranje, prikaz - sve ovdje\n}\n\n\/\/ Razdvojite odgovornosti\nfunction ProductsPage() {\n const { products, isLoading } = useProducts();\n const { filters, setFilter } = useProductFilters();\n const visibleProducts = useFilteredProducts(products, filters);\n\n return (\n <>\n <ProductFilters filters={filters} onChange={setFilter} \/>\n <ProductList products={visibleProducts} isLoading={isLoading} \/>\n <\/>\n );\n}\n<\/pre><\/div>\n\n\n6. Custom hookovi su za logiku, ne samo za “DRY”<\/h2>\n\n\n\n
Custom hookovi se \u010desto koriste samo da se izbjegne ponavljanje koda, ali njihova prava vrijednost je u tome \u0161to omogu\u0107uju da se UI komponenta fokusira isklju\u010divo na prikaz, dok hook nosi logiku – dohva\u0107anje podataka, pretplate, lokalni state s pravilima.<\/p>\n\n\n
\nfunction useDebouncedValue(value, delay) {\n const [debouncedValue, setDebouncedValue] = useState(value);\n\n useEffect(() => {\n const timeout = setTimeout(() => setDebouncedValue(value), delay);\n return () => clearTimeout(timeout);\n }, [value, delay]);\n\n return debouncedValue;\n}\n<\/pre><\/div>\n\n\nOvaj hook se mo\u017ee testirati neovisno o UI-u, ponovno koristiti u bilo kojoj komponenti i \u010dini kod komponente koja ga koristi puno \u010ditljivijim.<\/p>\n\n\n\n
React.memo<\/code>, useMemo<\/code> i useCallback<\/code> nisu ne\u0161to \u0161to se “uvijek treba koristiti” – svaki od njih ima svoj tro\u0161ak (memorija, usporedba ovisnosti). Kori\u0161teni bez razloga, mogu kod u\u010diniti te\u017eim za \u010ditanje bez stvarne koristi.<\/p>\n\n\n\nMemoizacija ima smisla kada:<\/p>\n\n\n\n
\n- Komponenta radi skupu kalkulaciju koja se ne mora ponavljati na svaki render<\/li>\n\n\n\n
- Komponenta je dio liste s puno stavki i re-renderira se \u010desto<\/li>\n\n\n\n
- Funkcija se proslje\u0111uje kao prop komponenti omotanoj u
React.memo<\/code>, gdje bi nova referenca poni\u0161tila smisao memoizacije<\/li>\n<\/ul>\n\n\n\n\/\/ Ima smisla: skupa kalkulacija\nconst sortedData = useMemo(() => expensiveSort(data), [data]);\n\n\/\/ Vjerojatno nepotrebno: jednostavna operacija\nconst fullName = useMemo(() => `${first} ${last}`, [first, last]);\n<\/pre><\/div>\n\n\nPravilo: prvo napi\u0161ite jednostavan kod, zatim mjerite (Profilerom), pa optimizirajte tamo gdje stvarno postoji problem.<\/p>\n\n\n\n
8. TypeScript nije opcija – smanjuje broj bugova prije nego se dogode<\/h2>\n\n\n\n
Tipovi za props, state i API odgovore hvataju cijelu kategoriju gre\u0161aka (pristup nepostoje\u0107em polju, pogre\u0161an tip podatka, zaboravljeni opcionalni prop) u trenutku pisanja koda, prije nego do\u0111u do produkcije.<\/p>\n\n\n
\ntype ProductCardProps = {\n product: {\n id: string;\n name: string;\n price: number;\n imageUrl?: string;\n };\n onAddToCart: (productId: string) => void;\n};\n\nfunction ProductCard({ product, onAddToCart }: ProductCardProps) {\n return (\n <div>\n <h3>{product.name}<\/h3>\n <p>{product.price} \u20ac<\/p>\n <button onClick={() => onAddToCart(product.id)}>Dodaj u ko\u0161aricu<\/button>\n <\/div>\n );\n}\n<\/pre><\/div>\n\n\nPosebno u Next.js projektima, gdje se podaci \u010desto dohva\u0107aju s WordPress REST API-ja ili drugih izvora, jasno tipiziran odgovor sprje\u010dava da se gre\u0161ka u strukturi podataka pojavi tek kad korisnik klikne na praznu stranicu.<\/p>\n\n\n\n
9. U\u010ditavanje podataka: izbjegavajte “waterfall” zahtjeve<\/h2>\n\n\n\n
\u010cesta zamka u komponentama koje dohva\u0107aju podatke u useEffect<\/code>-u je kreiranje lanca zahtjeva – jedan API poziv \u010deka drugi, koji \u010deka tre\u0107i, premda nemaju stvarnu ovisnost.<\/p>\n\n\n\n\/\/ Lo\u0161e: sekvencijalni zahtjevi koji se mogu paralelizirati\nuseEffect(() => {\n fetchUser().then((user) => {\n fetchOrders(user.id).then((orders) => {\n fetchRecommendations(user.id).then(setRecommendations);\n });\n });\n}, []);\n\n\/\/ Bolje: paralelni zahtjevi gdje je to mogu\u0107e\nuseEffect(() => {\n fetchUser().then((user) => {\n Promise.all([\n fetchOrders(user.id),\n fetchRecommendations(user.id),\n ]).then(([orders, recommendations]) => {\n setOrders(orders);\n setRecommendations(recommendations);\n });\n });\n}, []);\n<\/pre><\/div>\n\n\nU Next.js App Routeru, dio ovih problema se rje\u0161ava na razini servera kroz paralelno dohva\u0107anje podataka u Server Componentima, \u0161to dodatno smanjuje vrijeme do prvog prikaza sadr\u017eaja.<\/p>\n\n\n\n
10. Pi\u0161ite testove za logiku, ne za implementaciju<\/h2>\n\n\n\n
Testovi koji provjeravaju interne detalje implementacije (npr. “je li state varijabla X jednaka Y”) puknu na svaku refaktorizaciju, \u010dak i ako se pona\u0161anje aplikacije nije promijenilo. Korisniji su testovi koji provjeravaju pona\u0161anje iz perspektive korisnika.<\/p>\n\n\n
\n\/\/ Manje korisno: testira implementaciju\nexpect(component.state.isOpen).toBe(true);\n\n\/\/ Korisnije: testira pona\u0161anje\nfireEvent.click(screen.getByText("Otvori meni"));\nexpect(screen.getByRole("menu")).toBeVisible();\n<\/pre><\/div>\n\n\nOvakav pristup (npr. uz React Testing Library) zna\u010di da testovi i dalje prolaze \u010dak i ako promijenite interni state management, dok god krajnje pona\u0161anje ostaje isto.<\/p>\n\n\n\n
Zaklju\u010dak<\/h2>\n\n\n\n
Bolji React developer ne zna\u010di developer koji znade vi\u0161e hookova ili sintakti\u010dkih trikova – zna\u010di developer koji razumije za\u0161to se ne\u0161to doga\u0111a (re-render, re-fetch, re-render lanca), gdje treba \u017eivjeti odgovornost (state colocation, custom hookovi) i kada optimizacija stvarno donosi vrijednost. Ovi principi posebno dolaze do izra\u017eaja u produkcijskim Next.js projektima, gdje performanse, SEO i odr\u017eivost koda direktno utje\u010du na poslovni rezultat.<\/p>\n\n\n\n
FAQ<\/h2>\n\n\n\n
Treba li svaki projekt koristiti TypeScript?<\/strong> Za projekte koji rastu, imaju vi\u0161e developera ili se dugoro\u010dno odr\u017eavaju, TypeScript se isplati od prvog dana – tro\u0161kovi pisanja tipova su mnogo manji od tro\u0161ka debugiranja gre\u0161aka u produkciji.<\/p>\n\n\n\nJe li useEffect lo\u0161?<\/strong> Ne, ali se \u010desto koristi za stvari koje useEffect ne treba rje\u0161avati. Pravilo je: koristite ga za sinkronizaciju s vanjskim sustavima (API, DOM, subscriptions), a ne za izra\u010dunavanje vrijednosti iz postoje\u0107eg state-a.<\/p>\n\n\n\nKada je vrijeme za podjelu velike komponente?<\/strong> Kada komponenta radi vi\u0161e od jedne stvari – dohva\u0107a podatke, upravlja formom i prikazuje kompleksan UI istovremeno. Podjela prema odgovornosti olak\u0161ava testiranje, \u010ditanje i ponovnu upotrebu.<\/p>\n\n\n\nKoliko memoizacija stvarno utje\u010de na performanse?<\/strong> Ovisi o veli\u010dini aplikacije i broju re-rendera. Najbolji pristup je profilirati prije i poslije – u manjim aplikacijama razlika je \u010desto neprimjetna, dok u velikim listama i kompleksnim formama mo\u017ee biti zna\u010dajna.<\/p>\n\n\n\n
\n\n\n\nAko razvijate Next.js aplikaciju ili dashboard i \u017eelite da kod bude brz, \u010ditljiv i lako pro\u0161iriv, MasteryMesh mo\u017ee pomo\u0107i s razvojem ili tehni\u010dkim auditom postoje\u0107eg projekta. Kontaktirajte nas<\/a> ili pogledajte na\u0161u uslugu Web aplikacije<\/a>.<\/p>\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
React je jednostavan za pokrenuti, ali te\u0161ko ga je raditi dobro. Ve\u0107ina developera nau\u010di osnove…<\/p>\n","protected":false},"author":1,"featured_media":488,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[6],"tags":[],"class_list":["post-487","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development"],"_links":{"self":[{"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/posts\/487","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/comments?post=487"}],"version-history":[{"count":1,"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/posts\/487\/revisions"}],"predecessor-version":[{"id":489,"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/posts\/487\/revisions\/489"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/media\/488"}],"wp:attachment":[{"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/media?parent=487"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/categories?post=487"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/masterymesh.com\/blog\/wp-json\/wp\/v2\/tags?post=487"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}