Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> JavaScript - wzorce projektowe a frameworki?
d4ng
post 29.10.2015, 12:14:03
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
Go to the top of the page
+Quote Post
PrinceOfPersia
post 29.10.2015, 14:39:14
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 wink.gif To frameworki uczą cię wzorców, po to, żebyś stał się lepszym programistą, a nie odwrotnie.

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


--------------------
Go to the top of the page
+Quote Post
d4ng
post 29.10.2015, 15:20:44
Post #3





Grupa: Zarejestrowani
Postów: 191
Pomógł: 4
Dołączył: 7.03.2010

Ostrzeżenie: (0%)
-----


Po pierwsze... zostaniesz moim mistrzem?exclamation.gif! biggrin.gif jestem w szoku Twojej wypowiedzi! za którą bardzo bardzo dziękuje. Wracając do tematu, miałem już doświadczenie z angularem (wiem czym są serwisy, dyrektywy, controllery, routowanie) jednak w bardzo bardzo podstawowym zakresie (pracowałem przy 1 projekcje). Wykładałem się np przy tworzeniu dyrektywy z bootstrapa i pracy ze zmiennymi i metodami.. nie bardzo rozumiałem jakie występują między nimi zależności... o co chodzi z tym dziedziczeniem itp. Wtedy zdałem sobie sprawę, że nic nie umiem smile.gif że brakuje mi wiedzy w zakresie OOP javascriptu, że mój kod pisany w większości w jQuery jest niechlujny, zlany, że można wszystko robić lepiej. Tylko hmm dalej nie wiem co mam robić bo moim celem jest pisanie fajnego kodu z czystej kartki, a nie koniecznie angażowanie do tego celu kombajnu jakim jest np angular. Np. mam projekt w którym trzeba napisać w js jakąś fajną galerię zdjęć no i fajnie jakbym mógł stworzyć przy tym opensurcowy plugin który wrzucę na gita i zawsze będzie można go wykorzystać a nie klepać jakis jednorazoway kod jquery, który ciężko będzie później zaimplementować w innym projekcie.

Mam chęć rozwoju tylko potrzebuje kogoś kto wskaże mi drogę...

Ten post edytował d4ng 29.10.2015, 15:23:21
Go to the top of the page
+Quote Post
Comandeer
post 29.10.2015, 16:04:02
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)


--------------------
Go to the top of the page
+Quote Post
d4ng
post 30.10.2015, 09:07:21
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)?
Go to the top of the page
+Quote Post
PrinceOfPersia
post 30.10.2015, 15:13:38
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 smile.gif

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 wink.gif

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 wink.gif Takie i podobne rzeczy po prostu są słabe na dłuższą metę.

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.



--------------------
Go to the top of the page
+Quote Post
d4ng
post 30.10.2015, 16:00:00
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 smile.gif hmm na podstawie wpisów i tego co widzę w necie wywnioskowałem że najpierw spróbuje wchłonąć wiedzę z zakresu http://addyosmani.com/resources/essentialj...tternjavascript. Przy okazji pokaże wam fragment kodu mojego autorstwa i bardzo prosiłbym o przykład jak mógłby on wyglądać w prototpe pattern. Są w nim najczęściej używane przeze mnie elementy (pętle, tablice, zmienne, ajax, eventy). W modułowym wzorcu widziałem jak facet fajnie oddzielił widok (renderował go) od funkcjonalności w prototype też tak się da?

  1. $('#saveText').on('click', function(){
  2.  
  3.  
  4. // zmienne
  5. var ed = tinyMCE.get('content');
  6. var co = tinyMCE.get('comment');
  7. var terminy = [];
  8. var catalogs = [];
  9. var control = 1;
  10.  
  11.  
  12. // pobiera wybrane terminy
  13. for (i = 0; i < termCount; i++) {
  14. terminy.push({nazwa: $('.form-termin-name-'+i).val(), termin: $('.date-val-'+i).val()});
  15.  
  16. }
  17.  
  18.  
  19. // pobiera wybrane katalogi
  20. $('.category-tree input[type="checkbox"]:checked').each(function(){
  21. catalogs.push($(this).val());
  22. });
  23.  
  24.  
  25. // walidacja
  26. if ($('.form-title-text').val() == ''){
  27. $('.form-title-text').css('border', '2px solid #ff5454');
  28. control = 0;
  29. }
  30.  
  31. // if walidacja == 1
  32. if(control == 1){
  33. $.ajax({
  34. type: 'POST',
  35. url: base_url+'index.php/document/save_document',
  36. data: {
  37. 'nameText': $('.form-title-text').val(),
  38. 'contentText': ed.getContent(),
  39. 'directoryText': catalogs,
  40. 'commentText': co.getContent(),
  41. 'terminy': terminy
  42. },
  43. success: function(res) {
  44. if (res){
  45. showInfo('success', 'Tekst został pomyślnie zapisany! ');
  46. location.replace(base_url+'index.php/edycja-dokumentu/'+res+'/edit');
  47. }
  48. },
  49. error: function(res) {
  50. showInfo('error', 'Błąd połączenia z serwerem! ');
  51. }
  52. });
  53. }
  54.  
  55. });


Ten post edytował d4ng 30.10.2015, 16:04:05
Go to the top of the page
+Quote Post
Comandeer
post 30.10.2015, 16:48:12
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 wink.gif node.js stosuje syntax nie do końca zgodny ze specyfikacją.
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? wink.gif

@d4ng hint: patterny można łączyć wink.gif Prototype pattern ma raczej sens przy kodzie obiektowym - a Twój taki (jeszcze) nie jest.


--------------------
Go to the top of the page
+Quote Post
PrinceOfPersia
post 30.10.2015, 18:39:18
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/ wink.gif

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 wink.gif ?


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


--------------------
Go to the top of the page
+Quote Post
Comandeer
post 30.10.2015, 20:08:13
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? wink.gif
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 wink.gif Raczej chodziło mi o to, że nie rozumiem decyzji devów Angulara. Po co wytworzyli własny "standard" zamiast skorzystać z wzorców używanych w społeczności od lat?
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.


--------------------
Go to the top of the page
+Quote Post
d4ng
post 2.11.2015, 11:48:28
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" smile.gif

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
Go to the top of the page
+Quote Post
Comandeer
post 2.11.2015, 16:21:45
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 wink.gif W zarzuconym przeze mnie artykule Osmaniego jest to dokładnie opisane.
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 wink.gif Najlepsze artykuły o tym mają na HTML5 Rocks: http://www.html5rocks.com/en/tutorials/web...ents/shadowdom/
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ę wink.gif Albo moduł.
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


--------------------
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 29.05.2024 - 05:10