Ahoj, prihodim par svych zkusenosti. Obecne bych se ridil tim, co umi vetsina lidi v tymu. Mnoho lidi z djanga travi prilis mnoho casu nadcasovymi optimalizacemi na mistech, kde to neni v dany moment nezbytne nutne.
- přináší gulp něco výrazně lepšího než klasické django nástroje? Pro FE hlavne to, ze se nemusi ucit django veci. Django compressor dela svou vec, ale pokud jsi uz zvykly na nejaky workflow, tak se to prvni dny dost plete pod nohy. Navic je na webu mnoho hotovych receptu na inegraci LiveReload, SVG optimizeru, post css apod. Netvrdim, ze to v django-compressor nejde, ale rozhodne na tom stravis mnoho casu. - jaký nástroj byste použili místo gulp (jde hlavně o to, aby frotenďák/koder mohl ve Foundation vytvářet komponenty použitelné ostatními) Pokud vetsina zna gulp/grunt/node scripts zustante u toho. Me se osvedila kombinace bower (pro intalaci fe knihoven)+gulp+node - dá se rozumně zkombinovat s běžným vývojovým django workflow (django-gulp na první vyzkoušení funguje s runserver, podle dokumentace i collectstatic, ale praktické zkušenosti jsou nenahraditelné) Ja si vzdy vystacil s oddelenym adresarem pro fronted veci (typograficka stranka vcetne komponent), nasledna kompilace (dist ukazoval do struktury djanga) a pouzival jsem django static files "ManifestStaticFilesStorage" pro hashe v souborech. Na vetsim projektu takovy adresaru bylo i vice(menili se FE developeri, psali se ruzne mini appky), podstatne byl vzdy vysledny CSS soubor. Minusem jsou komity pro staticke buildy pro produkci, ale ja radeji to, nez abych se pak spolehal na "live" kompilaci na serveru. Je taky pravda, ze node_modules mohou byt obrovske (kazdy modul si tahne svoje zavislosti), ale ja to mam pouze na dev stroji. Robert 2016-09-22 19:32 GMT+02:00 Plovarna <mic...@plovarna.cz>: > Jako backendově orientovaný člověk bych nerad bránil použití moderního >> frontend řešení, ale když vidím, že zprovoznění gulpu a laravel-elixir >> protáhlo build docker kontejneru z původních 30s na 2m20s, v repu přibyl >> npm-shrikwrap.json o 4.000 řádcích a node_modules má 240 MB, nemám z toho >> úplně dobrý pocit. >> >> Oddel to uplne od sebe. Frontend budou driv nebo pozdeji delat jini lidi >> nez backed a bude na nich, jak build FE zrealizuji. Ty budes jen linkovat >> finalni soubory. >> > No to právě nechci. Možná v nějaké pozdější fázi, ale v současném týmu (6 > programátorů) mi přijde jako luxus, aby byly jednotliví lidi specialisti na > něco. Jeden z hlavních důvodů, proč nám nefungovala architektura > microservice byla tendence, kdy někdo měl pocit, že vlastní danou > komponentu, ostatní se nezajímali, jak je to udělané a s opravami chyb nebo > novými fíčurami se čekalo na daného specialistu. > > Samozřejmě, že každý má oblast, ve které se vyzná nejvíc, ale myslím, že i > backenďák, který, když to přeženu, přidá DateTimeField by měl být schopný > udělat i formulář s DateSelect widgetem (t.j. i nějaké css a js) a dát to > vývojový server, kde se na to podívá zadavatel a ověří, že to reálně řeší > problém, který to řešit mělo - a to všechno bez toho, aby čekali než jim > frontend team přikompiluje ten js do nějakého min.js. > > Jasne, nevnucuju, jen sdilim vlastni zkusenost. > > Podle me si ty dve veci (backend/fronted kod) zaslouzi oddelene > zpracovani. FE nezajima jakou DB mas za sebou, jake predpoklady musi splnit > aby jim neco fungovalo. To same plati i z pohledu BE — jestli nekdo udela > funkcni FE na reactu nebo jQuery, je mi to jedno. Je to jasna hranice, > kazda z tech stran ma sve nastroje a navyklosti, kterych se nemusi vzdavat. > Staci si dohodnout rozhrani, pres ktere budou komunikovat (a to muze byt > klasicke API na BE, a zkompilovane JS/CSS od FE). > > My jsme to delali dlouhou dobu klasicky, jako asi vetsina Djangistu > (staticke soubory u projektu, nedej boze rozdelene podle appek do nekolika > samostatnych static/ adresaru). ./manage.py staticfiles pak trval minuty, > semtam cely proces spadl protoze v Bootstrap CSS se objevil nejaky pokazeny > UTF-8 znak, a podobne dobroty. FE team s nama dokola resil co a kam maji > nakopirovat, zavolat, aby se to v Djangu objevilo. Tohle vsechno ve mne > nechalo pachut, ke ktere bych se nerad vracel. > > S malym tymem bych to asi zasel mastil vsechno na jedne hromadce. S tymem > sesti lidi bych to ale uz asi resil jinak. > > Toz at se dari! > > M. > > -- > -- > E-mailová skupina django-cs@googlegroups.com > Správa: http://groups.google.cz/group/django-cs > --- > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny > „django-cs“ ve Skupinách Google. > Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, > zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com. > Chcete-li tuto diskusi zobrazit na webu, navštivte > https://groups.google.com/d/msgid/django-cs/etPan.57e415aa.63702aaf.16739% > 40plovarna.cz > <https://groups.google.com/d/msgid/django-cs/etPan.57e415aa.63702aaf.16739%40plovarna.cz?utm_medium=email&utm_source=footer> > . > > Další možnosti najdete na https://groups.google.com/d/optout. > -- -- E-mailová skupina django-cs@googlegroups.com Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google. Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAHsQ37pjOuuTrc2Chjt3GrBPb5UiO7SDstCgJanFiGX9y-ya1Q%40mail.gmail.com. Další možnosti najdete na adrese https://groups.google.com/d/optout.
