Jak na Angular 5 multi-country / multi-feature komponenty? rubrika: Programování: JavaScript
2
hajek.raven
Zdravím,
máme produkt, kde máme krokovací komponentu (na každém kroku je folmulář a po kliknutí na tlačítko "další" se validuje).
Krokovací komponenta je napsána solidně, s tou jsme spokojeni.
Problém je ale v tom, že když se dostaneme na krok 3, komponenta která tento krok obsluhuje má 1500 řádků v template a asi 1200 v ts.
To je z důsledku, že se v prvních dvou krocích udělají podmínky, díky kterým se struktura kroku tři, hodně mění. Navíc se některé části mění i na základě země, ze které je uživatel.
1) Jak byste k tomuto přistupovali?
2) Jak byste přistupovali obecně z pohledu OOP architektury k tomu, když máte opravdu hodně bussiness pravidel a zároveň nechcete mít hodně duplicitního kódu v komponentách (některé komponenty se liší na základě bussiness pravidel málo, některé úplně)?
8
Občan
prvně bych kompozicí rozdělil těch 1500/1200 na více komponent. To není jen o SoC, 1200 řádků už zní, že toho komponenta má na starosti příliš, ale i tom, že change detector na tohle není stavěn. Což navazuje na to, že business logiku lze úplně odebrat z komponent do servisní vrstvy. Až na kořenovou komponentu je dobré mít komponenty naprosto hloupé, bez logiky, jen transformující data z atributů do HTML podoby. Ona pak se pak duplicita omezí přirozeně.
Komentáře
-
harrison314
:
suhlasim urcite by som to rozbil aby klesla komplexita danej komponenty
—
16.5.2018
-
hajek.raven
:
Tohle jsem zkoušel, ale nevím jak to uchopit. Teď máme 7 zemí (v každé to je lehce jiné) a v každé zemi je ta komponenta opět lehce jiná na základě podmínek z předchozích kroků (6 možností). Kdybych to uplně rozdělil, tak mám teď 7x6=42 komponent. Plánujeme do konce roku přidat minimálně dalších 10 zemí. To bych se z toho potom zbláznil.
Bohužel tohle je asi moc konkrétní problém, který bez kódu vyřešit nelze, ale ten sdílet bohužel nemůžu.
—
17.5.2018
-
harrison314
:
Skor som to myslel tak, robit znovupouzitelne komponenty menesej granulatity a tie pouzivat vo vetsich logickych celkoch.. Toereticke rienie moze byt generator komponent.
—
17.5.2018
-
Občan
:
Otázka je dost obecně položená. Půjde konkrétní rozdíly mezi zeměmi. Ty můžou být kdekoliv v datech, logice i v šablonách. A často bývá prospěšný si dát ten marast a napsat všechny šablony, než hledat abstrakci v datech.
—
17.5.2018
-
gooday
:
souhlasím s @Občan a @harrison314 - všechno rozdělit na menší komponenty a nebát se (zdánlivých) duplicit - to, že šablony některých komponent jsou pak 'skoro' stejné neznamená, že slouží k tomu samému. Za mě můžu říct, že tyhlety 'akademické' rozvahy, jak to všechno správně seskládat dohromady nám značně ulehčuje redux (resp. Ngrx) - je to sice dvakrát víc kódu, ale člověka to donutí si nejdřív připravit datovou vrstvu a její proměny přes akce a ve výsledku pak z toho krásně vyplyne, jak si ty výsledný chytrý a blbý komponenty poskládat a je to všechno přehledný a uklizený.
—
18.5.2018
-
VirtualSkiper
:
@hajek.raven Opravdu muze byt nejrychlejsi zalozit pro kazdou subkomponentu vlastni jazykovou (respektive country) variantu. Porad se budes lip orientovat v nejake adresarove strukture, nez kdyz se budes placat v tisicich radkach kodu. Izolujes zakladni subkomponentu, rozkopirujes to a pro kazdou zemi a budes resit jenom exceptions. Kdyz budes chtit byt hodne fancy muzes tu master komponentu extendovat, ale kdyz to 7x (klidne i 10x) nakopirujes pod sebe bude se ti lip psat, cist a udrzovat. Lazy loading vyresi zbytek, na serveru bude kodu vic, ale fyzicky se nacte jenom to co bude treba.
—
20.5.2018
-
hajek.raven
:
Děkuji za komentáře. Asi nyní použiji nakopírování. Poté při refaktoru to nechám na formBuilderu s custom controlkami.
—
22.5.2018
Pro zobrazení všech 2 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře