![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 191 Pomógł: 4 Dołączył: 7.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
Witajcie mam mętlik w głowie i wydaje mi się że im więcej szukam i czytam tym mniej wiem.... Chciałbym powoli odejść od samego jQuery i skupić się bardziej na czystym, zorientowany "obiektowo" javascripcie. Wiem że są różne wzorce projektowe jednak nie mam takiej wiedzy i doświadczenia, żeby móc stwierdzić który jest lepszy (dysponowanie pamięcią, wydajność, łatwość nauki), a co najważniejsze który pozwoli mi miękko wejść w takie frameworki jak angular czy backbone? Podoba mi się Module Pattern ale widzę że dużą popularność ma Prototypal Pattern. Bardzo proszę o rozjaśnienie sytuacji, może przedstawienie obecnych trendów itp Każdy wpis będzie cenny. Pozdrawiam
|
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 717 Pomógł: 120 Dołączył: 18.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Cytat Wiem że są różne wzorce projektowe jednak nie mam takiej wiedzy i doświadczenia, żeby móc stwierdzić który jest lepszy (dysponowanie pamięcią, wydajność, łatwość nauki), a co najważniejsze który pozwoli mi miękko wejść w takie frameworki jak angular czy backbone? podchodzisz trochę od d... strony ![]() Cytat Chciałbym powoli odejść od samego jQuery i skupić się bardziej na czystym, zorientowany "obiektowo" javascripcie. Wiem że są różne wzorce projektowe jednak nie mam takiej wiedzy i doświadczenia, żeby móc stwierdzić który jest lepszy (dysponowanie pamięcią, wydajność, łatwość nauki), a co najważniejsze który pozwoli mi miękko wejść w takie frameworki jak angular czy backbone? Podoba mi się Module Pattern ale widzę że dużą popularność ma Prototypal Pattern. Bardzo proszę o rozjaśnienie sytuacji, może przedstawienie obecnych trendów itp Każdy wpis będzie cenny. Pozdrawiam Angular jest za bardzo zopiniowany. Pisząc w Angularze przestajesz pisać w normalnym, czystym JavaScripcie, bo musisz pisać tak jak Angular od ciebie wymaga. Plusem jest to, że owszem, nauczysz się paru ciekawych wzorców projektowych, choćby wstrzykiwanie zależności (depedency injection), które jest stosowane w Angularze wielu miejscach. Także nauczysz się składania aplikacji z powiązanych ze sobą komponentów(dyrektyw). Co prawda w Angularze komponenty są niedorobione pod kątem implementacji, ale jeśli traktować to jako wzorzec projektowy Komponentu (który wciela x innych frameworków), to bardzo okej. Nauczysz się też pewnych antypatternów, np. to jak nie należy tworzyć modułów w JavaScripcie (angularowe moduły oparte to porażka roku). Jeśli chodzi o inne wzorce, to Angular wykorzystuje również wzorzec Serwisu, który pozwala oddzielić logikę aplikacji od wyświetlania (chodzi o to, że pisząc komponent ("dyrektywę") możesz część kodu umieścić w zewnętrznych obiektach ("serwisach"), dzięki czemu nie bruździsz sobie). Jednak Angular ma 3 minusy: 1. trudny w nauce 2. uciążliwy przy dłuższym korzystaniu 3. Obecna wersja jest już przestarzała, a nowego Angulara 2 (który ma być już lepszy i prostszy) jeszcze nie ma. Co do Backbone to bardzo fajny framework na początku. Opiera się na dość prostych zasadach, nauczy cię pewnych rzeczy, choćby MV*, programowania opartego na słuchaniu zdarzeń, otworzy oczy na pewne rzeczy jak może być budowana aplikacja (po zaznajomieniu się z Backbone, potem nawet jak robiłem coś na czystym jQuery, to starałem się wcielać pewne zasady, które zauważyłem w Backbone). Minusem (choć dla niektórych to będzie plus) Backbone'a jest na to, że wszystko musisz robić samemu, i ten framework to tak jakby nie framework (bo mówię, opierając się na jQuery można napisać atrapę Backbone'a i nie będzie dużo gorsza). Ale dla celów edukacji Backbone jest okej. Jeszcze jest React, czyli framework, który polega w zasadzie na robieniu komponentów i składaniu ich w większe komponenty. I całą aplikację robisz na komponentach, a potem łączysz to z jakimiś źródłami danych (albo jednym źródłem). Możesz się z niego nauczyć bardziej modularnego podejścia. Poza tym React w dużej mierze opiera się na paradygmatach programowania funkcyjnego, co też jest dużym bonusem do nauki. Zachęca również do bardziej odpowiedzialnego podejścia w kwestii programowania, zwraca uwagę na niemutowalność (czyli niezmienność obiektów) oraz na odpowiednie oddzielenie widoku od kodu logiki (zwykle poprzez tzw. architekturę Flux, która nie jest niczym nowym, ale jest ładnym buzzwordem). Jako że React cię nie pilnuje (możesz robić co chcesz), to powinieneś sam dbać o pewne rzeczy, albo będziesz miał burdel w kodzie i w działaniu. Uczy to odpowiedzialności. W zasadzie bardzo łatwy do wejścia, chociaż jest wskazane, żebyś nauczył się przy okazji ustawić sobie build system w jakimś Babelu. Nie jest to konieczne co prawda, ale ten krok pozwoli na używanie JSX, czyli składni HTMLa w plikach JS (w React szablony komponentów tworzy się w plikach JS). Cytat Podoba mi się Module Pattern ale widzę że dużą popularność ma Prototypal Pattern. Bardzo proszę o rozjaśnienie sytuacji, może przedstawienie obecnych trendów itp Każdy wpis będzie cenny. Pozdrawiam Obecne trendy w JavaScript są takie, że wraca się do rzeczy sprzed kilkudziesięciu lat oraz odkrywa rzeczy dawno odkryte przez programistów innych języków czy działek programowania. Więc chcesz być na czasie w JavaScripcie - nie zamykaj się na JavaScript - to sam będziesz pionierem i uważany za mesjasza wśród frontendowców. Jeśli chodzi jednak o konkretne implementacje starych jak świat wzorców projektowych w JavaScript to tu masz ściągę: http://addyosmani.com/resources/essentialj...npatterns/book/ Ten post edytował PrinceOfPersia 29.10.2015, 14:41:24 -------------------- |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 191 Pomógł: 4 Dołączył: 7.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
Po pierwsze... zostaniesz moim mistrzem?
![]() ![]() ![]() Mam chęć rozwoju tylko potrzebuje kogoś kto wskaże mi drogę... Ten post edytował d4ng 29.10.2015, 15:23:21 |
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 1 268 Pomógł: 254 Dołączył: 11.06.2009 Skąd: Świętochłowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat Więc chcesz być na czasie w JavaScripcie - nie zamykaj się na JavaScript - to sam będziesz pionierem i uważany za mesjasza wśród frontendowców. True. Teraz środowisko JS odkrywa magię Unixa: jest moda na tworzenie super lekkich, modularnych rozwiązań, gdzie jeden moduł wykonuje jedną, konkretną rzecz. I wszystko w oparciu o moduły: http://addyosmani.com/writing-modular-js/ A jeśli już mówimy o React: warto od razu poczytać sobie o Web Components i eventowej architekturze aplikacji (http://www.slideshare.net/nzakas/scalable-javascript-application-architecture) -------------------- ★Mój blog || Okiem krytyka★
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 191 Pomógł: 4 Dołączył: 7.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
Bardzo dziękuje za odpowiedz, jak dla mnie modułowe podejście jest łatwiejsze (https://www.youtube.com/watch?v=m-NYyst_tiY) i czytelniejsze, ale czy lepsze (wydajność, rynek pracy)?
|
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 717 Pomógł: 120 Dołączył: 18.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Cytat Po pierwsze... zostaniesz moim mistrzem?exclamation.gif! biggrin.gif jestem w szoku Twojej wypowiedzi! za którą bardzo bardzo dziękuje. haha, spoko ![]() Cytat("d4ng") wydajność Co do wydajności to we frontendzie jest podstawowa zasada, która w 90% przypadków się sprawdza: - JavaScript jest szybki, jeśli coś wolno działa to zapewne jest to DOM To przeglądarka zamula. Ustawianie styli na elementach DOM, wstawianie czegoś do DOM, usuwanie, scrollowanie okna przeglądarki, wyświetlanie elementów w przeglądarce itp. To czy zrobisz sobie moduły w JS, to gra minimalną rolę. Ponieważ JS jest szybki. Przeglądarki są wolne. Na tym bazuje zresztą React, że odświeża tylko te elementy DOM, które się zmieniły i dlatego jest szybciej (chociaż również w React można zrobić wolno działającą aplikację, jeśli się niewłaściwie go użyje) Cytat rynek pracy)? ze względu na rynek pracy: warto poznać Module Pattern taki, jak tam opisany, bo będziesz go używał nieraz pewnie, chociaż niekoniecznie... przy tworzeniu modułów. W zasadzie nazwa modułu jest myląca, bo może posłużyć do tworzenia modułu, ale równie dobrze do tworzenia zwykłych obiektów, ew. do izolowania zwykłych obiektów, czyli może posłużyć do kreacji i enkapsulacji czegokolwiek. Może lepiej byłoby to określać inaczej, np. "Encapsulation with IIFE" (IIFE to właśnie samowywołująca się funkcja). Ale cóż, przyjęło się że jest to Module Pattern ![]() do samego robienia modułów zwykle używa się jakiegoś systemu modułów. Najpopularniejsze obecnie to chyba - CommonJS (czyli `require('nazwamodułu')` itp.) teoretycznie to są moduły z NodeJS, ale przy użyciu choćby Browserify można je "kompilować" i odpalać potem w przeglądarce. - moduły z ES6 żeby ich użyć też używa się specjalnego "kompilatora" (czy raczej transpilatora), np. Babel, który transpiluje kod z ES6 (standard nie wspierany w całości przez przeglądarki) do ES5 (powszechny standard). - moduły z Angulara Ale one nie są kompatybilne z niczym, więc będziesz ich mógł używać tylko w Angularze, ponieważ twórcy Angulara postanowili, że będą hipsterami i wymyślą własny system modułów, zamiast użyć jakiegoś istniejącego. Nie dziwne, że teraz muszą przepisywać całego Angulara ![]() Cytat("Comandeer") True. Teraz środowisko JS odkrywa magię Unixa: jest moda na tworzenie super lekkich, modularnych rozwiązań, gdzie jeden moduł wykonuje jedną, konkretną rzecz. I wszystko w oparciu o moduły: http://addyosmani.com/writing-modular-js/ ten link jest przykry, bo pokazuje patologię programowania w JS - że do wszystkiego jest ileś konkurencyjnych rozwiązań. Na szczęście powoli wchodzą moduły z ES6 (po 20 latach istnienia języka dorobili do niego moduły!), więc pewnie niedługo wszyscy będą robić na tych modułach, ew. wspierając się np. CommonJS, które jest bardziej dynamiczne i pozwala na większą dowolność w ładowaniu modułów (co jest jednak wadą pod pewnymi względami), niż pozwala na to instrukcja `import` z ES6. Cytat A jeśli już mówimy o React: warto od razu poczytać sobie o Web Components i eventowej architekturze aplikacji (http://www.slideshare.net/nzakas/scalable-javascript-application-architecture) to warto nie tylko w odniesieniu do Reacta, ale ogólnie do dobrych praktyk programowania. BTW chyba miałeś na myśli "modułowej" bo w tym linku z Slideshare bardziej o modułach i decouplingu jest. -------------------- |
|
|
![]()
Post
#7
|
|
Grupa: Zarejestrowani Postów: 191 Pomógł: 4 Dołączył: 7.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
PrinceOfPersia czytając Twoje wpisy rozlewa mi się mózg na klawiaturę i zdaje sobie sprawę jak małym robaczkiem jestem w tym ogródku... ale na pewno się nie zniechęcam i powoli będę parsować temat
![]()
Ten post edytował d4ng 30.10.2015, 16:04:05 |
|
|
![]()
Post
#8
|
|
![]() Grupa: Zarejestrowani Postów: 1 268 Pomógł: 254 Dołączył: 11.06.2009 Skąd: Świętochłowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat teoretycznie to są moduły z NodeJS No właśnie teoretycznie nie ![]() Cytat moduły z Angulara Ale one nie są kompatybilne z niczym, więc będziesz ich mógł używać tylko w Angularze I to mnie dziwi, bo moduły z Angulara są bardzo podobne do AMD i nie powinno być aż tak wielkich trudności z przepisaniem Angulara na AMD. Cytat Na szczęście powoli wchodzą moduły z ES6 (po 20 latach istnienia języka dorobili do niego moduły!), więc pewnie niedługo wszyscy będą robić na tych modułach Dopóki nie zostanie wytworzony standard asynchronicznego loadera dla nich, to raczej zostanie transpilowanie ich do CJS albo nawet AMD (jeśli async loader jest wymogiem dla aplikacji). Cytat BTW chyba miałeś na myśli "modułowej" bo w tym linku z Slideshare bardziej o modułach i decouplingu jest. A czym jest komponent, jeśli nie modułem, który powinien być odizolowany od reszty i wystawiać eventowe API? ![]() @d4ng hint: patterny można łączyć ![]() -------------------- ★Mój blog || Okiem krytyka★
|
|
|
![]()
Post
#9
|
|
Grupa: Zarejestrowani Postów: 717 Pomógł: 120 Dołączył: 18.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Cytat A czym jest komponent, jeśli nie modułem, który powinien być odizolowany od reszty Tu masz rację, zapędziłem się w tym postrzeganiu modułu jedynie jako poziomu organizacji na poziomie pliku (CommonJS itp.), że znikła mi szersza perspektywa tego, że koncepcyjnie wszystko może być modułem, choćby pojedyncza funkcja. Czyli mamy moduł jako sposób na organizację samego kodu (po to, żeby człowiek się połapał w programie) oraz moduł w sensie koncepcyjnym. Czasem to jest to samo, czasem nie. Można zrobić aplikację choćby na modułach CommonJS, ale nie zachowując żadnych dobrych praktyk i zrobić np. 10 plików, który każdy jest zależny od 5 innych. Czyli moduły w sensie organizacji kodu, ale już nie koncepcyjnie. Z drugiej strony można zrobić aplikację w jednym pliku, który będzie miał np. 2000 linijek kodu, ale porobić tę aplikację jak najbardziej ładnie i modułowo. Cytat wystawiać eventowe API? Hmmm... Rozumiem o czym piszesz, bo niby owszem, eventy to dobra metoda na uniezależnienie modułów, ale z drugiej strony: - eventowe API może istnieć bez modułów (praca w jQuery na przykład, też opiera się na eventach, a jednak ludzie piszą spaghetti code w jQuery i nie robią w nim żadnych modułów) - Poza tym można stworzyć modularną aplikację połączoną na niezależne od siebie części, bez użycia zdarzeń (wszystko co jest niemutowalne i bezstanowe - w sumie eventy są potrzebne tylko do tego, żeby zmienić stan obiektu/aplikacji. Jeśli nie zmieniasz stanu, nie potrzebujesz eventów) Jeszcze jest taka sprawa taka, że rozwiązania bazujące na eventach często oznaczają to, że moduły uzależniają się albo od globalnego obiektu odpowiadającego za rozprowadzanie eventów, albo od konkretnego interfejsu obiektów np. mogą zakładać, że moduły będą zawierać metodę "emit" (albo "notify" jak było na tych slajdach), a co oznacza, że nie zawsze da się wyjąć moduł z aplikacji A i wsadzić do aplikacji B. Chociaż oczywiście można napisać tak apkę, żeby się dało (np. korzystając w modułach jedynie z callbacków które wchodzą na wejściu, a nie zakładać nic o dispatcherze czy o interfejsie obiektów - za to będzie odpowiadał już specjalnie przygotowany callback). Cytat I to mnie dziwi, bo moduły z Angulara są bardzo podobne do AMD i nie powinno być aż tak wielkich trudności z przepisaniem Angulara na AMD. No dobra. Jak się ma czas i ochotę, to pewnie i na CommonJS można "przepisać". Tym niemniej nikt nie będzie przepisywał ręcznie dziesiątek czy setek modułów Angulara (chyba, że od początku aplikacja by była tak pisana). A jeśli aplikacja jest oparta na hipsterskich modułach angularowych (tudzież innych "bytach" - w sumie kontrolery, serwisy czy dyrektywy to też pewnego rodzaju moduły) to nie da się jej zanalizować istniejącymi narzędziami. Tzn. nie musi być w ogóle oparta o jakieś wymyślne moduły. Nawet jakby zrobili ją na zwykłych obiektach JS czy klasach ES6 też byłoby okej (taki ma być Angular 2, ale jeszcze go nie ma). Wtedy można robić np. takie rzeczy: http://hughsk.io/colony/ ![]() Cytat No właśnie teoretycznie nie wink.gif node.js stosuje syntax nie do końca zgodny ze specyfikacją. to znaczy? Możesz "poelaborować" trochę więcej ![]() Cytat("d4ng") PrinceOfPersia czytając Twoje wpisy rozlewa mi się mózg na klawiaturę i zdaje sobie sprawę jak małym robaczkiem jestem w tym ogródku... ale na pewno się nie zniechęcam i powoli będę parsować temat Dzięki. W sumie właśnie się zastanawiam, że może powinienem więcej pisać na swoim blogu o programowaniu, skoro to ludzi ciekawi. Ten post edytował PrinceOfPersia 30.10.2015, 18:40:23 -------------------- |
|
|
![]()
Post
#10
|
|
![]() Grupa: Zarejestrowani Postów: 1 268 Pomógł: 254 Dołączył: 11.06.2009 Skąd: Świętochłowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat Rozumiem o czym piszesz, bo niby owszem, eventy to dobra metoda na uniezależnienie modułów, ale z drugiej strony Akurat to było odniesienie prosto do Web Components. Od strony używającego komponentu całość de facto sprowadza się do tego: Kod <my-component></my-component> Cała zawartość tego elementu jest zamknięta w Shadow DOM tak, że nic nie wycieka na zewnątrz. Tutaj logicznym sposobem komunikacji ze światem zewnętrznym są po prostu eventy DOM-owe (poprzez interfejs CustomEvent), np. ładny colorpicker po wybraniu koloru po prostu odpali zdarzenie change. Bo tylko to w sumie interesuje developera korzystającego z tego komponentu. Jednak eventy dla całej aplikacji: why not? ![]() Cytat praca w jQuery na przykład, też opiera się na eventach Hm… Ja jednak jakoś wolę odróżniać zdarzenia DOM-owe od "innych". Nie wiem, może mam już jakieś eventowe zboczenie. Cytat co oznacza, że nie zawsze da się wyjąć moduł z aplikacji A i wsadzić do aplikacji B. To też zależy gdzie piszemy taką aplikację. Np w środowiskach node'owych de facto standardem jest natywny EventEmitter. Jasne, można pokombinować, żeby apka nic nie musiała wiedzieć o dispatcherze - pytanie tylko czy zawsze się to opłaca? Jeśli przyjmiemy, że z danych komponentów będzie korzystać dany zespół, to raczej nie będą zmieniać samego szkieletu aplikacji w różnych projektach. Cytat No dobra. Jak się ma czas i ochotę, to pewnie i na CommonJS można "przepisać". Da się i na CMD ![]() Cytat to znaczy? Możesz "poelaborować" trochę więcej Chodzi głównie o sposób eksportowania rzeczy z modułu. Wg specki (coś mi ich strona nie chce działać, hm) można to robić tylko i wyłącznie przy pomocy exports. A w nodejs przeważająca większość modułów eksportowana jest przez module.exports. Niby nic, ale niezgodność jest. -------------------- ★Mój blog || Okiem krytyka★
|
|
|
![]()
Post
#11
|
|
Grupa: Zarejestrowani Postów: 191 Pomógł: 4 Dołączył: 7.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
Kurcze ciesze się że z tego tematu powstała taka ciekawa dyskusja, bogata w więdze i doświadczenie.
Cytat wskazane, żebyś nauczył się przy okazji ustawić sobie build system w jakimś Babelu. Co to jest? z dalszej treści wywnioskowałem że to jakiś kompilator z wersji ES6 na ES5? Cytat CJS albo nawet AMD jaka jest różnica między jednym a drugim (fundamentalna) Cytat że moduły będą zawierać metodę "emit" (albo "notify" jak było na tych slajdach), a co oznacza, że nie zawsze da się wyjąć moduł z aplikacji A i wsadzić do aplikacji B co to jest emit i notifly? różnice? przykład? zastosowanie? Cytat Dzięki. W sumie właśnie się zastanawiam, że może powinienem więcej pisać na swoim blogu o programowaniu, skoro to ludzi ciekawi. Śmiało, czytałem Twoje wpisy (widze że masz lekkość w pisaniu) jak również bloga i krytyka Comandera, bardzo fajnie piszecie, jest tam dużo cennej wiedzy. hmm co do tematu to fajnie by było napisać o dobrych praktykach żeby własnie uniknąć wspomnianego wcześniej "spaghetti code w jQuery" ![]() Kod <my-component></my-component> Cytat Cała zawartość tego elementu jest zamknięta w Shadow DOM tak, że nic nie wycieka na zewnątrz. yy? Shadow DOM to coś innego od DOM? i na koniec... Cytat patterny można łączyć wink.gif Prototype pattern ma raczej sens przy kodzie obiektowym - a Twój taki (jeszcze) nie jest. ok, ale praktycznie cały kod przekleję jak będę robił część odpowiedzialną za update bądź użyje go do zapisania nie strony tylko np wpisu w części blogowej... Wtedy za każdym razem mam powielać kod? Czy da się to jakoś fajnie podzielić żebym mógł korzystać z jego fragmentów w innych funkcjach? Czy da się jakoś oddzielić cześć funkcjonalna od widoku i eventu (tzn na pewno się da ale bardziej chodzi mi tu o dobre praktyki)? Ten post edytował d4ng 2.11.2015, 11:52:03 |
|
|
![]()
Post
#12
|
|
![]() Grupa: Zarejestrowani Postów: 1 268 Pomógł: 254 Dołączył: 11.06.2009 Skąd: Świętochłowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat Co to jest? z dalszej treści wywnioskowałem że to jakiś kompilator z wersji ES6 na ES5? Dokładnie to transpiler. Cytat jaka jest różnica między jednym a drugim (fundamentalna) CJS jest synchroniczne, AMD asynchroniczne. Z tej różnicy de facto wynikają wszystkie inne ![]() Cytat co to jest emit i notifly? różnice? przykład? zastosowanie? emit/notify to po prostu metoda, przez którą dany moduł porozumiewa się z resztą świata. Jeśli zachodzi w nim jakaś zmiana, emituje informację o niej. Najprostszym przykładem mechanizmu tego typu są zdarzenia w DOM, np. kliknięcie przycisku na stronie emituje zdarzenie click, pod które się można podpiąć ($.fn.on czy "tradycyjnie" addEventListener). Tego typu mechanizm można przenieść "wyżej", do samej aplikacji. Cytat Shadow DOM to coś innego od DOM? W Chrome kliknij sobie prawym przyciskiem myszy na np. polu odpowiedzi i wybierz "Zbadaj element", a następnie zajrzyj do #shadow-root ![]() Cytat Wtedy za każdym razem mam powielać kod? Nie. Jeśli dwa miejsca w kodzie robią bardzo podobną rzecz, to najprawdopodobniej da się z tego zrobić jedną klasę/funkcję i wykorzystywać ją później zamiast powielania wszędzie tego samego lub bardzo podobnego kodu. Cytat Czy da się to jakoś fajnie podzielić żebym mógł korzystać z jego fragmentów w innych funkcjach? Zrobić z tego funkcję ![]() Cytat Czy da się jakoś oddzielić cześć funkcjonalna od widoku i eventu (tzn na pewno się da ale bardziej chodzi mi tu o dobre praktyki)? W JS też istnieje MVC i podobne patterny, więc tędy droga. Ale jak takie rozdzielenie zachodzi, to już zależy od frameworka. Warto sobie popatrzeć np na http://todomvc.com/ żeby mieć jakieś porównanie. Ten post edytował Comandeer 2.11.2015, 16:22:57 -------------------- ★Mój blog || Okiem krytyka★
|
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 25.04.2025 - 07:02 |