Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: frW 23. 09. 2016, 22:46:40
-
Ahojte, co ma podle vas větší budoucnost a vyplatí se začít učit?
-
Angular2 má lepší budoucnost, tedy až někdy bude hotový. React je horší, ale funguje teď.
-
Angular2 má lepší budoucnost, tedy až někdy bude hotový. React je horší, ale funguje teď.
Co by si React-u vytkl?
-
Co by si React-u vytkl?
Šablony nejsou pořádně oddělené od kódu, chybí two-way binding, s TypeScriptem či Web Components to funguje dost omezeně.
-
Co by si React-u vytkl?
Šablony nejsou pořádně oddělené od kódu, chybí two-way binding, s TypeScriptem či Web Components to funguje dost omezeně.
To, že šablony nejsou oddělené od kódu je výhoda.
Šablony samy o sobě jsou zlo. Reálně jsou to data pro univerzální builder, ale tváří se jako program, je to mix deklarativního a procedurálního přístupu, což je samo o sobě špatné.
Neoddělení šablon od kódu způsob nevede na iluzorní šablonovou modularitu, ale na modularitu kódu. Oddělení vede na dvoukoljenou modularitu, což znesnadňuje následnou údržbu, musíte dvakrát hledat místo, které je třeba upravit. Vznikají neúmyslné vazby mezi logicky nesouvisejícími moduly.
Z praktického hlediska údržby není dobré sdílet šablony napříč aplikací, mnohem lepší je aplikaci skládat z funkčních komponent (šablona + chování a tyto aspekty komponenty držet na jednom místě pohromadě).
Sdílení šablon komponentami je porušení principu zapouzdření. Vede na vedlejší zobrazovací efekty při úpravách.
-
React má náročné vytváření šablon, komplikovaný two way binding. Agular vynucuje používání svých subkomponent, které nemají s modelováním dat a zobrazením nic společného. Oba frameworky jsou bloated a těžko se učí a používají. React kvůli svému virtuálnímu dom a šablonám v javascriptu. Angular kvůli svému zbytečnému ekosystému.
Zkuste raději vue, nebo knockout.
-
Šablony nejsou pořádně oddělené od kódu
Jak by sis to představoval? Jak víc by to mělo být oddělené, než to je teď? A co by si tím získal?
... s TypeScriptem či Web Components to funguje dost omezeně.
Můžeš to rozvést? Na jaké omezení jsi narazil?
-
Šablony nejsou pořádně oddělené od kódu
Jak by sis to představoval? Jak víc by to mělo být oddělené, než to je teď? A co by si tím získal?
Já bych docela uvítal mít možnost psát templaty pomocí čistě js struktur. Ne tak ukecaně jako je to teď
React.createElement(....).
Nebo případně psát šablony odděleně ve speciálním jazyku, ale nutnost kompilace jsx souborů se mi moc nelíbí.
React má náročné vytváření šablon, komplikovaný two way binding. Agular vynucuje používání svých subkomponent, které nemají s modelováním dat a zobrazením nic společného. Oba frameworky jsou bloated a těžko se učí a používají. React kvůli svému virtuálnímu dom a šablonám v javascriptu. Angular kvůli svému zbytečnému ekosystému.
Zkuste raději vue, nebo knockout.
Vue.js vypadá pěkně. Ale radši si počkám. Zásadně nepoužívám technologie mladší než 2 roky pro aplikace, které se nemají po roce zahodit.
https://twitter.com/hipsterhacker/status/628986199814881280?lang=cs
https://twitter.com/hipsterhacker/status/736004234940846081?lang=cs
-
To, ze se Angular spatne uci a pouziva, muze napsat jen clovek, ktery nezvladne dat dohromady ani Hello world. Doporucovani mrtveho Knouckoutu, ktery nic neumi, je pak uplne mimo.
-
Šablony samy o sobě jsou zlo. Reálně jsou to data pro univerzální builder, ale tváří se jako program, je to mix deklarativního a procedurálního přístupu, což je samo o sobě špatné.
Před pár lety bylo zlo míchání js a html. Za pár let bude zlo zase něco jiného. Na oddělených šablonách nevidím nic špatného. Záleží na tom co děláte.
-
To, ze se Angular spatne uci a pouziva, muze napsat jen clovek, ktery nezvladne dat dohromady ani Hello world. Doporucovani mrtveho Knouckoutu, ktery nic neumi, je pak uplne mimo.
Co knockout neumí?
-
Co knockout neumí?
Knockout je knihovnicka pro bindovani dat; Angular je plnohodnotny framework. Ta otazka snad ani nemuze byt myslena vazne.
-
Co knockout neumí?
Knockout je knihovnicka pro bindovani dat; Angular je plnohodnotny framework. Ta otazka snad ani nemuze byt myslena vazne.
To není dobrá odpověď. Co konkrétně chybí? Je problém použít knockout třeba v kombinaci s jquery?
-
Šablony samy o sobě jsou zlo. Reálně jsou to data pro univerzální builder, ale tváří se jako program, je to mix deklarativního a procedurálního přístupu, což je samo o sobě špatné.
Před pár lety bylo zlo míchání js a html. Za pár let bude zlo zase něco jiného. Na oddělených šablonách nevidím nic špatného. Záleží na tom co děláte.
No ono to jen vypadá jako míchání html a js, ale ve skutečnosti je to jen js. Tagům z HTML v JSX odpovídají objekty a metody napsané v js. A jen vzhledem k tomu, že mezi nimi je vztah 1:1, je možno vytvořit syntaktický cukr v podobě JSX. Ale není nutné ho používat.
Ale HTML je vůbec nešťastné řešení, které se prosadilo. Nasměrovalo naši civilizaci někam, odkud už není návratu. Změní to až nasazení AI, kdy si prohlížeč přečte mnoho HTML zdrojů a sám z nich sestaví vlastní výstup. To ovšem lidem vezme schopnost samostatného experimentu a radost z nalezení nového zdroje.
Z přístupu na internet zmizí dobrodružství, které je v něm stále přítomné, možnost, že objevíte něco, co vás překvapí.
-
A co se na tom chceš učit ? Za den umíš jeden další den druhý, pokud u toho sleduješ i seriály tak to trvá dva dny.
-
IT není tesařina kde se něco naučíš a stačí ti to do důchodu, tady má většina informací životnost 4-5 let.
-
To, že šablony nejsou oddělené od kódu je výhoda.
Šablony samy o sobě jsou zlo. Reálně jsou to data pro univerzální builder, ale tváří se jako program, je to mix deklarativního a procedurálního přístupu, což je samo o sobě špatné.
Neoddělení šablon od kódu způsob nevede na iluzorní šablonovou modularitu, ale na modularitu kódu. Oddělení vede na dvoukoljenou modularitu, což znesnadňuje následnou údržbu, musíte dvakrát hledat místo, které je třeba upravit. Vznikají neúmyslné vazby mezi logicky nesouvisejícími moduly.
Z praktického hlediska údržby není dobré sdílet šablony napříč aplikací, mnohem lepší je aplikaci skládat z funkčních komponent (šablona + chování a tyto aspekty komponenty držet na jednom místě pohromadě).
Sdílení šablon komponentami je porušení principu zapouzdření. Vede na vedlejší zobrazovací efekty při úpravách.
Doporučuji si nastudovat, co znamená Model-View-Controller a proč ho každý druhý UI framework znovu a znovu vynalézá už čtyřicet let (což je v IT neuvěřitelně dlouhá doba).
Šablony (views) se mezi komponentami (controller) nesdílí. Smysl rozdělení je přesně opačný. Sdílí se jedna komponenta pro více šablon. Třeba jednu šablonu generující HTML a druhou JSON.
-
To, že šablony nejsou oddělené od kódu je výhoda.
Šablony samy o sobě jsou zlo. Reálně jsou to data pro univerzální builder, ale tváří se jako program, je to mix deklarativního a procedurálního přístupu, což je samo o sobě špatné.
Neoddělení šablon od kódu způsob nevede na iluzorní šablonovou modularitu, ale na modularitu kódu. Oddělení vede na dvoukoljenou modularitu, což znesnadňuje následnou údržbu, musíte dvakrát hledat místo, které je třeba upravit. Vznikají neúmyslné vazby mezi logicky nesouvisejícími moduly.
Z praktického hlediska údržby není dobré sdílet šablony napříč aplikací, mnohem lepší je aplikaci skládat z funkčních komponent (šablona + chování a tyto aspekty komponenty držet na jednom místě pohromadě).
Sdílení šablon komponentami je porušení principu zapouzdření. Vede na vedlejší zobrazovací efekty při úpravách.
Doporučuji si nastudovat, co znamená Model-View-Controller a proč ho každý druhý UI framework znovu a znovu vynalézá už čtyřicet let (což je v IT neuvěřitelně dlouhá doba).
Šablony (views) se mezi komponentami (controller) nesdílí. Smysl rozdělení je přesně opačný. Sdílí se jedna komponenta pro více šablon. Třeba jednu šablonu generující HTML a druhou JSON.
View != Šablona, View lze realizovat i bez šablony.
A znáte framework, který zakazuje použít šablonu v komponentě, jiným komponentám?
-
Urcite Angular! React je sracka
-
Ale HTML je vůbec nešťastné řešení, které se prosadilo. Nasměrovalo naši civilizaci někam, odkud už není návratu. Změní to až nasazení AI, kdy si prohlížeč přečte mnoho HTML zdrojů a sám z nich sestaví vlastní výstup. To ovšem lidem vezme schopnost samostatného experimentu a radost z nalezení nového zdroje.
Proč je to nešťastné? Protože se nepoužívají sémantické značky a id a class jsou většinou pouze pro určení stylů?
-
Ale HTML je vůbec nešťastné řešení, které se prosadilo. Nasměrovalo naši civilizaci někam, odkud už není návratu. Změní to až nasazení AI, kdy si prohlížeč přečte mnoho HTML zdrojů a sám z nich sestaví vlastní výstup. To ovšem lidem vezme schopnost samostatného experimentu a radost z nalezení nového zdroje.
Proč je to nešťastné? Protože se nepoužívají sémantické značky a id a class jsou většinou pouze pro určení stylů?
Protože žádný prohlížeč, jen s deklarativním schématem, jakým je HTML nevystačí, a proto se to muselo obcházet různými obezličkami, jako css a javascript. Jediná výhoda HTML byla, že se to dalo jednoduše prohledávat a na základě této možnosti vytvořit vyhledávače, takže nešťastné řešení z hlediska proggramování, bylo šťastné z hlediska kulturních inovací.
-
Ale HTML je vůbec nešťastné řešení, které se prosadilo. Nasměrovalo naši civilizaci někam, odkud už není návratu. Změní to až nasazení AI, kdy si prohlížeč přečte mnoho HTML zdrojů a sám z nich sestaví vlastní výstup. To ovšem lidem vezme schopnost samostatného experimentu a radost z nalezení nového zdroje.
Proč je to nešťastné? Protože se nepoužívají sémantické značky a id a class jsou většinou pouze pro určení stylů?
Protože žádný prohlížeč, jen s deklarativním schématem, jakým je HTML nevystačí, a proto se to muselo obcházet různými obezličkami, jako css a javascript. Jediná výhoda HTML byla, že se to dalo jednoduše prohledávat a na základě této možnosti vytvořit vyhledávače, takže nešťastné řešení z hlediska proggramování, bylo šťastné z hlediska kulturních inovací.
Oddělení stylu od obsahu je podle vás špatně? Bez javascriptu se dá vystačit docela dobře, případně se dá používat jen jako doplněk.
-
Doporučuji si nastudovat, co znamená Model-View-Controller a proč ho každý druhý UI framework znovu a znovu vynalézá už čtyřicet let (což je v IT neuvěřitelně dlouhá doba).
Šablony (views) se mezi komponentami (controller) nesdílí. Smysl rozdělení je přesně opačný. Sdílí se jedna komponenta pro více šablon. Třeba jednu šablonu generující HTML a druhou JSON.
Hups!
Šablony nejsou Views. Komponenty nejsou Controllers.
Nebo teda u někoho možná i jo, ale já třeba šablony používám pro generování modelu, pro různé transformace, prostě, hmm, vytvořím si na něco šablonu. Podobně, komponenty mám zafixováno od toho, že se dají komponovat. Kontroler od toho aby kontroloval, rozhodoval, zpracoval vstup a rozhodl co dál...
Ale třeba to má někdo jinak.
-
React je template systém, Angular je framework...
je třeba zahrnout další věci, jako stav aplikace... jsou blázni, kteří v Angular2 používají Flux architekturu...
Jinak abych zmínil i něco užitečného... Angular 2 má na gitu 1147 issue... a co jsem tak zkoušel, tak hello world v Angular 2 má cca 800KB. Počkal bych, až bude méně bugů, až bude fungovat ngc, až bude angular2-bootsrap fungovat s ngc...
-
Ale HTML je vůbec nešťastné řešení, které se prosadilo. Nasměrovalo naši civilizaci někam, odkud už není návratu. Změní to až nasazení AI, kdy si prohlížeč přečte mnoho HTML zdrojů a sám z nich sestaví vlastní výstup. To ovšem lidem vezme schopnost samostatného experimentu a radost z nalezení nového zdroje.
Proč je to nešťastné? Protože se nepoužívají sémantické značky a id a class jsou většinou pouze pro určení stylů?
Protože žádný prohlížeč, jen s deklarativním schématem, jakým je HTML nevystačí, a proto se to muselo obcházet různými obezličkami, jako css a javascript. Jediná výhoda HTML byla, že se to dalo jednoduše prohledávat a na základě této možnosti vytvořit vyhledávače, takže nešťastné řešení z hlediska proggramování, bylo šťastné z hlediska kulturních inovací.
Oddělení stylu od obsahu je podle vás špatně? Bez javascriptu se dá vystačit docela dobře, případně se dá používat jen jako doplněk.
Bez javascriptu se vystačit nedá, proto taky vznikl, aby UX internetových aplikací mělo vlastnosti desktopových aplikací. Dá se vystačit bez html a css a DOM vytvářet v javascriptu.
Co bylo motivací k oddělení obsahu a stylu? Možnost na jednom místě měnit vzhled stejných prvků všude. Nic jiného. Tedy aby bylo možno pohodlně měnit vzhled daného obsahu bez nutnosti zasahovat do samotného obsahu.
U šablon je špatně možnost měnit obsah jednotlivých komponent globálně, čehož se dosáhne, když se šablona nebo její část sdílí napříč komponenty. A je to stejně špatně jako měnit obsah proměnných globálně.
Komponenta by měla být zapouzdřená, struktura obsahu (generovaného ze šablony) by měla mít lokální charakter, tak aby když změníte šablonu komponenty se to nepřeneslo jinam.
Struktura stránky má být sestavena ze zapouzdřených komponent, které spolu komunikují, a ne důmyslným propojením šablon, jak se to často děje.
-
Angular 2.x je zoufalý pokus dohnat React. Bohužel za cenu lpění na principech z Angular 1.0. Vzniklo z toho něco poměrně nešťastného. React je čistčí, nezatížený zbytečnostma. V praxi je mezi nimi zásadní rozdíl zejména v rychlosti při práci s větším množstvím dat. React to zvládá lépe (byl tak navržen). Samo, můžete stránkovat, optimalizovat atd... Od toho je tady React.
PS: Ať už se naučíš jedo nebo druhé, práci bezproblémů najdeš. Jinými slovy, nauč se technologii, která je Ti sympatičtějíš.
-
Angular 2.x je zoufalý pokus dohnat React. Bohužel za cenu lpění na principech z Angular 1.0. Vzniklo z toho něco poměrně nešťastného. React je čistčí, nezatížený zbytečnostma. V praxi je mezi nimi zásadní rozdíl zejména v rychlosti při práci s větším množstvím dat. React to zvládá lépe (byl tak navržen). Samo, můžete stránkovat, optimalizovat atd... Od toho je tady React.
PS: Ať už se naučíš jedo nebo druhé, práci bezproblémů najdeš. Jinými slovy, nauč se technologii, která je Ti sympatičtějíš.
Z mé zkušenosti větší tabulky fungují nejlépe, pokud se posílá html ze serveru. Tak to dělá většina velkých aplikací. React v tomhle případě moc nepomáhá. Při změně stránky se musí přerenderovat většina buněk.
-
Angular 2.x je zoufalý pokus dohnat React. Bohužel za cenu lpění na principech z Angular 1.0. Vzniklo z toho něco poměrně nešťastného. React je čistčí, nezatížený zbytečnostma. V praxi je mezi nimi zásadní rozdíl zejména v rychlosti při práci s větším množstvím dat. React to zvládá lépe (byl tak navržen). Samo, můžete stránkovat, optimalizovat atd... Od toho je tady React.
PS: Ať už se naučíš jedo nebo druhé, práci bezproblémů najdeš. Jinými slovy, nauč se technologii, která je Ti sympatičtějíš.
Z mé zkušenosti větší tabulky fungují nejlépe, pokud se posílá html ze serveru. Tak to dělá většina velkých aplikací. React v tomhle případě moc nepomáhá. Při změně stránky se musí přerenderovat většina buněk.
React umožňuje renderování provádět na serveru, i na serveru může udržovat kopii DOMu.
-
React umožňuje renderování provádět na serveru, i na serveru může udržovat kopii DOMu.
To je pravda, ale řekl bych, že výhody reactu se projevý hlavně při malých změnách. Při změně stránky tabulky vyjde vygenerování nového těla minimálně nastejno jako určení rozdílu a překreslení jen změněných částí.
-
oprava: projeví
:-[
-
React umožňuje renderování provádět na serveru, i na serveru může udržovat kopii DOMu.
To je pravda, ale řekl bych, že výhody reactu se projevý hlavně při malých změnách. Při změně stránky tabulky vyjde vygenerování nového těla minimálně nastejno jako určení rozdílu a překreslení jen změněných částí.
Ano, ale ruku v ruce s tím musí přijít i změna konceptu zobrazování a především vyhledávání informací, ne už listování v dlouhých stránkovaných seznamech, ale zobrazení přímo toho, co vás zajímá na základě kontextu a zadaných parametrů. A toje právě koncept, na jaký vede tlustý klient. Takže, když si otevřete například fakturu, ihned máte po ruce, odkaz na dodavatele, související objednávku, platební příkaz nějaké, účtování a ne odkaz do obecného seznamu, který manuálně procházíte.
V podstatě seznam potřebujete zobrazit jen tehdy, když hledáte něco a nevíte co. A takovému stavu v aplikaci je se potřeba vyhnout, vždy to co máte po ruce pomocí odkazů, má převyšovat vaše požadavky. No a nějaké hledání mimo běžnou práci už může být pomalejší a méně optimalizované.
Zcela přírozeně toto vzniklo v eshopech, kde se záhy vynořily filtry omezující výběr. Otevření detailu v seznamu nemusí znamenat jeho načtení, ale mohl být už načtem spolu se seznamem a ve vhodné chvíli se jen zobrazí. Supervizorem aplikace už není server, ale klient. Což odpovídá i přirozené logice.
-
Angular nepoznam, React pouzivam uz cca rok a je to pecka. Oproti angularu je vraj jednoduchsi na pochopenie (neviem porovnat) ale spolu s reactom sa musis naucit aj redux alebo flux pretoze bez toho si pri vacsich projektoch nevystacis.
React spaja viacero pristupov. Od komponetoveho pristupu ala delphi, cez funkcionalne programovanie, az po skladanie komponent na styl WPF. Daju sa v tom robit velmi pekne aplikacie ktore su po funkcnej stranke rovnako interaktívne ako desktopove. Taktiez ma velmi pozitivne prekvapil vykon reactu (hlavne ked porovnam nase aplikacie s rovnako komplexnými aplikáciami konkurencie).
-
Pouzivame Angular 2 na obrovsky system. Je to parada, hlavne pro backend vyvojare, kteri maji zkusenosti s desktopovym vyvojem (wpf, winforms).
Ucici krivka je brutalne nizka, s malyma znalostma lze hned vytvorit neco pouzitelneho.
Infrastrukturu za tebe vyresi Angular CLI, kdy staci dva prikazy k rozjeti aplikace (automaticky to vsechno nakonfiguruje - webpack, typescript, sass, atd) a spusti. Konecne vyvojovy proces podobny Visual Studio a .NET platforme, kde si stahnes projekt, zmacknes F5 a vsechno funguje. Zadne zbytecne konfigurace a trapeni navic.
ng new my-app
ng serve
Dalsi obrovska vyhoda je defaultni podpora Typescriptu, staticky typovane jazyky jsou proste pro vetsi systemy prinosnejsi. Kdyz jsem se minule snazil nejak rozumne rozjet typescript + react, tak jsem u toho stravil prebytecne mnozstvi hodin.
Ta znovupouzitelnost komponent (zapouzdreni/shadowing) je bozi.
-
Angular2 ma jednoznacne buducnost. Trackujeme ho od bety cez RC verzie a momentalne sme par tyzdnov na stabilnom release. Medzi jednotlivymi RC sa rozbijalo kopec veci.
Samozrejme treba sa mentalne pirpravit na lahky uvod do Haskellu, teda pardon na FRP v podani RxJS. Veskera komunikacia s backendom sa implementuje pomocou monad, takze si o tom treba nieco pozriet. Kedze su monadicke API v imperativnych jazykoch infekcne, je nutne designovat kod tak, aby bol monad friendly, t.j. v pripade RxJS aby ste spristupnovali Observable a zaclenili si ho do API.
Synchronnym volniam a imperativnemu programovaniu mozete dat zbohom.
-
Angular 2 má budoucnost do vydání Angular 3, kdy bude dvojka zatracena a opuštěna.
-
Co bude niekedy na jar 2017. V pripade, ze kvoli 3 budu nejake API verzie 2 urcene na deprecation, tie budu vyhodene az v vo verzii 4, ktora by mala vyjst niekedy v druhej polovici 2017.
-
Jako minule, kdy v Angluaru nezůstal kámen na kameni a aplikace v jedničce se mohly vyhodit?
-
Pokud vim, tak Angular presel na semver a verze 3 bude znamenat jen dalsi update 2ky s nejakymi breaking changes, zadny prepis od piky jako 2. Takoveto updaty se dely s Angularem 1 bezne, akorat se kvuli tomu nezvedala hlavni verze.
Ke komponente a sablone - mozna to neni presne, ale v Angularu 2 je Component dekorator (anotace) tridy kontroleru (component =?= controller) a sablona je retezec nebo html soubor, coz snad odpovida view. Takze v ramci nejake knihovny to muze znamenat neco jineho.
S Angular 2 velmi pomalu zacinam, ale pokud vim, tak ma server-side rendering (https://universal.angular.io/) a jako dalsi optimalizaci i predkompilovani sablon (AOT).
Take by mne zajimalo, co je spatneho na pouzivani Angularu a Reduxu? Jednu mensi aplikaci jsem v ng 1 + Redux psal a prislo me to dobre - diky loggeru stavu se velmi pohodlne debugovalo ve srovnani s ng 1 bez Reduxu.
Ptam se, protoze dalsi projekt mame delat v Angularu 2 a ngrx/store (vychazi z Reduxu), tak by me zajimalo, co je na tom tak sileneho.
Jinak me prijde, ze Angular 2 vs React zustava klasicke "vse pripravene v jednom" vs. "poskladej si sam" a k Angularu 2 oproti 1 jeste pribyla dobra podpora TypeScriptu, ktera pro nekoho (treba me) je velke plus. Cetl jsem, ze pro zacatecnika muze byt Angular lepsi, protoze jasne udava mantinely a vse ma clovek pripravene (ale osobne srovnat s Reactem nemuzu, zkusenosti s nim nemam).
-
ani jedno
v práci ale potkáš angular nebo react (spíš ten angular)
takže se uč angular a nějakej další jen pro sebe (třeba vue, nebo ember)
-
Angular2 +redux může a nemusí být ok,
záleží na implementaci - protože React dělá diff, Angular nic takového neumí
samozřejmě máme li čistě funkcionální konponenty a vhodnou implementaci flux architektury, tak je to OK (tuším, že pro angular 1 to splňuje https://github.com/christianalfoni/flux-angular)
hlavně jde ale o to, že angular je plný oop komplikací: controller, service, factory...
react + redux je spíše funkcionální a IMHO jednodušší...
-
To, že šablony nejsou oddělené od kódu je výhoda.
Šablony samy o sobě jsou zlo. Reálně jsou to data pro univerzální builder, ale tváří se jako program, je to mix deklarativního a procedurálního přístupu, což je samo o sobě špatné.
Neoddělení šablon od kódu způsob nevede na iluzorní šablonovou modularitu, ale na modularitu kódu. Oddělení vede na dvoukoljenou modularitu, což znesnadňuje následnou údržbu, musíte dvakrát hledat místo, které je třeba upravit. Vznikají neúmyslné vazby mezi logicky nesouvisejícími moduly.
Z praktického hlediska údržby není dobré sdílet šablony napříč aplikací, mnohem lepší je aplikaci skládat z funkčních komponent (šablona + chování a tyto aspekty komponenty držet na jednom místě pohromadě).
Sdílení šablon komponentami je porušení principu zapouzdření. Vede na vedlejší zobrazovací efekty při úpravách.
Doporučuji si nastudovat, co znamená Model-View-Controller a proč ho každý druhý UI framework znovu a znovu vynalézá už čtyřicet let (což je v IT neuvěřitelně dlouhá doba).
Šablony (views) se mezi komponentami (controller) nesdílí. Smysl rozdělení je přesně opačný. Sdílí se jedna komponenta pro více šablon. Třeba jednu šablonu generující HTML a druhou JSON.
View != Šablona, View lze realizovat i bez šablony.
A znáte framework, který zakazuje použít šablonu v komponentě, jiným komponentám?
Nevim jestli jsem vas pochopil uplne spravne, rikate ze pouzit view v controlleru jinym controllererem je vporadku? Jsem trochu zmateny co tim vlastne myslite. Obecne nacpat kus view do controlleru je hloupost, stejne tak volat controller ve view, pouziti sablony jinym kontrolerem je normalni (notice, error a jine helpery napr.). Jinak v ruby on rails vam to 100% nedovoli, je workaround, ale to je proste mimo logiku a smysl celeho MCV (MVC je hloupost protoze neopovida poradi dle meho nazoru). To ze v Javascriptu, kde si odkudkoliv muzu prepsat cokoliv a kdyz mi to nepujde procpu to pres DOM je totiz celej kamen urazu. Takze to, jestli vy pak pisete "prasokod", protoze to je jednodussi nebo rychlejsi nebo z jakehokoliv jineho duvodu, jeste neznamena, ze neporusujete koncepci. Takze je to podobna situace asi jako s coding standards. Bohuzel v pripade porusovani koncepce vytvarite diry a pochybne/nezname situace/chovani aplikace. Nicmene jsem vas jenom mozna spatne pochopil tak si to neberte za zle. A ano view samotne neni definovano jako "HTML", ale muze to byt json, xml nebo i neco jineho klidne i CSS, obrazek.... proc ne. Me prijde, ze Angular se hodne inspiroval RoR, stejne tak Laravel. V Djangu je to trochu jine chapani/koncept/interpretace MCV oproti zminenym.