![]() |
![]() |
![]()
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: 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? (IMG:style_emoticons/default/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 (IMG:style_emoticons/default/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. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 17.10.2025 - 03:17 |