Super odcinek! Zrób może jakąś serie "dobre praktyki programowania", gdzie pokazujesz: 1. Zły kod, często popełniany przez nowych developerów 2. Poprawiony kod. Mógłbyś zostawić w pliku oba kody i tłumaczyć bazując na złym kodzie, czemu się tak nie robi. Odcinki 3-5 minutowe. Bardzo by się przydała taka playlista na pasku zakładek. Pozdrawiam! :) Jeżeli to czytasz, proszę o odpowiedź, lub serduszko, żeby inni co popierają pomysł mogli się wypowiedzieć / zagłosować na niego.
Daję znać! Mega mi się podobało! Jak dla mnie, osoby które dopiero zaczyna swoją przygodę z JS , takie rady są bardzo cenne. Czekam na kolejny odcinek :)
Bardzo fajne rady. Jedynie o czym nie wiedziałem to o async / await. Jeśli więcej jest takich smaczków to pewnie, że warto je poznać a przede wszystkim sprawdzić siebie. Zrobić pauzę i samemu pomyśleć, co można w przedstawianym kodzie zmieniać :)
Bardzo, dobry filmik. Jednego czego mi brakuje to żeby była stara i nowa wersja, łatwiej byłoby widoczne zmiany. Teoretycznie można sobie zrobić screen i porównać co się zmieniło i jak bardzo. Ale jakby na górze byłą cały czas stara wersja kodu łatwiej jest śledzić każdy krok zmiany jaka została dokonana i np zatrzymać sobie filmik przeanalizować. Dobra robota świetnie nadajesz się na nauczyciela, bardzo przejrzyście mówisz nie plączesz się. Przyjemnie się słucha i ogląda.
Warto dodać, że wykonując push na tablicy, która jest constem wcale nie modyfikujesz tego czym jest nasza stała (dlatego js nam na to pozwala), pod naszą stałą znajduje się referencja na tablicę i to jej nie można modyfikować. Ta sama zasada tyczy się obiektów, gdy obiekt jest stałą - wciąż możemy dowolnie zmieniać wartości wewnątrz tego obiektu. Super odcinek, pozdrawiam ;)
Ogólnie to chciałem powiedzieć, że jestem tylko 19 letnim gówniakiem ze szkoły średniej i moje rady mogą okazać się głupie, bo do juniora mi jeszcze daleko haha :) Ale z takich kosmetycznych rzeczy w tym przykładzie to zwróciłbym w funkcji getBeer data[0], wtedy można destrukturyzować od razu przekazany obiekt, w fetchu mimo wszystko ta klasyczna konkatenacja wydaje mi się bardziej czytelna "url + id", no i pozabierałbym te wszystkie nawiasy z funkcji strzałkowych, gdzie jest jeden argument, żeby było bardziej sexy, hehe. Przepraszam jeżeli nie mam racji bo tak jak mówiłem wyżej nie mam żadnego doświadczenia i z chęcią się dowiem, jeżeli się mylę :).
data[0] powinno być rozwiązane po stronie API. Wysyłamy GETa na adres "url/:id", czyli spodziewamy się jednego elementu w odpowiedzi, a nie tablicy elementów, bo jak wiemy - id jest unikatowe :) Sugeruję używanie nowego sposobu łączenia zmiennych z tekstem. Jest on po prostu bardziej elegancki. Reszta to kwestia indywidualna.
Ale w tym API jak mówił Adam, biorąc jeden element dostajemy tablice [{}]. Zwracając data[0] nie musimy destrukturyzować const [beer] = data. Miałem na myśli ten konkretny przykład, zawsze trochę mniej kodu prawda :) A co do konkatenacji to rzeczywiście template string jest lepszy. Niepotrzebnie z tym wypaliłem, haha
@@wiktorbandura Zgadzam się, w tym konkretnym przykładzie Twoje rozwiązanie jest prawidłowe. Lecz z założenia funkcje mają być tak uniwersalne jak tylko się da (pozwala to oszczędzić sporo czasu na debugowaniu, gdy coś w łańcuchu działania aplikacji się zmieni), więc lepiej jest zwrócić całą tablicę, lub data[0] tak jak mówisz, ale opakowane w ifa, którym np logujemy info w razie wykrzaczenia ;D Wiem, może się troszkę czepiam, ale kiedyś też nie zwracałem na to uwagi, a później lądowałem z ręką w nocniku, bo w API z którego korzystała moja stronka coś się zmieniło, a ja nie zabezpieczyłem należycie kodu :/ Podsumowując, żeby mój komentarz nie wyglądał tylko jak puste słowa krytyki: 1) Starajmy się tworzyć uniwersalne funkcje i obsługę błędu (try-catch, albo minimalnie chociaż jakiś console.log) - zaoszczędzi nam to wiele czasu w przyszłości, 2) Starajmy się odwoływać do konkretnego elementu jak najrzadziej, czy też go zwracać (głównie chodzi mi o elementy z httpRequestów), a jeśli już to opakować go w ifa - znowu zaoszczędzimy czas później ;) 3) Zdobywanie stażu programistycznego, to nauka na błędach, a lepiej uczyć się na błędach innych niż własnych. Pozdro! :) Do juniora Ci bliżej niż myślisz. Mało osób w średniej szkole już coś sobie pisze :)
Cześć ! :) A może coś o optymalizacji WordPressa? Jak przyśpieszyć wynik Google PageSpeed Insights? Z tego co mi wiadomo trzeba mieć pewien zakres wiedzy programistycznej, a sporo ludzi szuka informacji na temat przyśpieszenia takich stron. Pozdrawiam!
Jak Ty to robisz że za każdym razem jak o czymś pomyślę to od razu wrzucasz na ten temat jakiś toturial/poradnik/odcinek ? :D Tak bardzo fajny odcinek, nasza gawędź fanów prosi o większą ilość porad, w których pokażesz jak pisać POPRAWNY kod w oparciu O NOWE technologie :)
Część wiem że jesteś po frontedowej stronie mocy , ale słyszałeś albo używałeś może NestJs , uważam że nie jako wymusza on dobre praktyki związane z programowaniem , po za tym rozbicie backendu na warstwy , skupienie się na domenie czyli programowanie DDD powodują że aplikacje są łatwo skalowalne. Jak ktoś programował wcześniej w c# .net core to wiele podobnych rzeczy może znaleźć dla siebie .
A nie jest jeszcze przypadkiem tak, że jak mamy tylko jeden parametr w funkcji strzałkowej, to możemy pominąć nawiasy? Jak dla mnie to też może poprawić jakość kodu, warto o tym wspomnieć. Poza tym super odcinek, jak zawsze! :)
Hej fajny odcineczek :D. Tylko zastanawiam się po co jest ten .then((data) => data) skoro response.json() zwraca Promise to on rekurencyjnie sobie sprawdzi czy to cos co nie jest zwracane jest promisem i jak coś to zaczeka i w następnym then otrzymasz już tylko dane z tego promise który jest zwracany, więc teoretycznie ta funkcja nic nie robi, jest sobie funkcją identity :)
przy pierwszym przykładzie dobrze by było przypisać długość tablicy do zmiennej i tą zmienną używać w pętli. Tutaj może różnicy nie robi, ale przy większych tablicach sprawdzanie za każdym razem jej długości może obciążyć procesor.
Niekoniecznie → mrale.ph/blog/2014/12/24/array-length-caching.html W skrócie: nie musimy robić mikrooptymalizacji, bo silniki JS są zwykle na tyle mądre, że robią to same ;)
7:59 consty tego typu (czyli prostego typu, z faktycznie stałymi wartościami) preferuję nazywać DUŻYMI_LITERAMI. Jak rozumiem ta konwencja nie jest stosowana w JS?
Te try/catche mnie trochę mierzą. W Node ich używam, ale jeżeli chodzi o front to dla mnie osobiście promise'y wyglądają przejrzyściej jeżeli połączymy je z czystymi funkcjami. W takim układzie każdy 'then(nazwaFunkcji)' zajmuje zawsze jedną linijkę, a mamy jednak lepszą prozę. Plus w promise mamy finally (choć w try/catch po prostu to się da za blokiem funkcji zwyczajnie). Ale nie powiem - przykład z piwnym api broni się bardzo :) Dla tych co nie wiedzą: then(nazwaFunkcji) i then(res => nazwaFunkcji(res)) to to samo. No i jest to szansa na nazwanie tego co robimy zamiast po prostu to robić, żeby w przyszłości nie musieć się domyślać o co nam chodziło.
Część Roman nazywam się Aleks i jestem w technikum PROGRAMISTYCZNYM w klasie 1. I chciałem zapytać czy zrobił byś odc z jakimiś tipami poradami do dotychczasowego js ale tego czystego bez bibliotek.
Wszystko pięknie. Tylko 2 pytanka. Dlaczego nie zamieniłeś wszystkich then? Co jak wolę then i catch, bo mogę po jakimś ciągu napisać tylko 1 catch? :)
Czemu destrukturyzacja jako osobne `const`y a nie bezpośrednio w parametrach? Osobiście stosuję ten drugi sposób (github.com/Comandeer/rollup-plugin-babel-minify/blob/master/tests/helpers/createTransformTest.js#L24-L30 ), chociaż często słyszę, że jestem fanatykiem destrukturyzacji :D Osobiście też mam mieszane uczucia względem `fetch`. Z jednej strony jest przyjemniejsze do pracy niż XHR, z powodu swojego API opartego o `Promise`. Z drugiej zaś - to dość low-levelowe API, na co wskazuje choćby fakt, że sami musimy zająć się przerabianiem pobranych danych na strawny format (`response.json()`). XHR ma tę przewagę, że wystarczy określić typ zwracanej odpowiedzi (XML, JSON, text czy nawet drzewko DOM) i po prostu dostajemy wszystko już przeparsowane i gotowe do działania. A eventowe API można obejść małą funkcją-helperem, przerabiającym to na `Promise`.
W praktyce prawie zawsze korzystam z axiosa, więc korzystanie z fetcha jest dla mnie swego rodzaju egzotyką 😂Ale jak zwykle masz sporo racji. Co do destrukturyzacji w parametrach, to mógłbym to zrobić, gdyby ten element nie był wewnątrz tablicy 🤔Chyba, że masz jakiś pomysł?
cześć jestem dosyć młody lecz chcę wiązać moją przyszłość z programowaniem nie miałem nigdy z tym do czynienia więc myślałem o nauce z książek przy czym nie wydając dużej ilości pieniędzy polecił byś jakąś książkę lub inny sposób nauki ? podkreślam nie miałem nigdy z tym do czynienia .
Wszystko super i fajnie omówione ALE... :D Po kursach z Kylem Simpson'enm na FM, chyba jestem bardziej skłonny iść w stronę używania var, const, let do wyrażania tego co moja zmienna ma robić, albo jaką informacje ma przekazywać czytającemu kod. Const jest na tyle perfidny że używanie go przy tablicach czy obiektach bardzo psuje czytelność kodu ( myli czytającego, który widzi chwile później .push na tej tablicy ), zwłaszcza dla osób które const znają z innych języków. C zęsto moje funkcje zwierają IIFE, albo krótkie wyrażenia która zamykam w {}, i tam let jest idealny( jeśli chce tymczasową zmienną ), ale jeśli w tym samym miejscu używam zmiennej która pochodzi ze scope'a wyżej to czytelniejsza jest dla mnie informacje jeśli ta zmienna jest varem, a nie let'em. :) Ex. (function namingAnonymousFunctionIsCool(){ var someNumber = 1; { let i = someNumber; i--; someNumber = i; } })
Dobry odcinek, właśnie dobrych praktyk brakuje mi najbardziej. Fajną opcją byłoby gdybyś np: na koniec każdego odcinka wrzucał 2 dobre praktyki w js, nawet w formie hasłowej, bo żaden poradnik nie zawiera wszystkich, a najtrudniej jest pisać czysty kod jak się ich nie zna :) Pozdrawiam
Fajny odcinek, ale... .then((data) => data) what? :O PS. Co prawda VS Code jest najpiękniejszym edytorem do JavaScriptu, a produkty JetBrains są płatne, nieszczególnie ładne, zamulają wolniejszego kompa i mają cięższy learning curve, ale nie mogę nie powiedzieć, że takie rzeczy, jak zmiana function na =>, wywalenie zahardcode'owanej wartości do zmiennej, czy zamiana konkatenacji stringów na template literal to jest tam zautomatyzowana i można sobie coś takiego zrobić za pomocą 2-4 naciśnięć klawiatury.
Mam pomysł na całą serię. Może by tak ludzie do ciebie wysyłali jakieś proste małe projekty z swoi kodem, a ty byś go recenzował wskazując jego wady i dobre strony?
@@helloroman Zawsze można zanonimizować. Zresztą miałbyś kontrole nad tym, co się dostanie na odcinek, a co nie. Minusem jest pewnie natłok pracy, bo to trzeba przejrzeć, ocenić, znaleźć niedociągnięcia. Nawet mały projekt może być "rozległy" , ostatnio zrobiłem zadanie rekrutacyjne, to wyszło mi 60 plików (SASS/HTML/JS). Plusem jest natomiast realny kod adeptów programowania, zawierający rzeczywiste błędy. W każdym razie dzięki za odpowiedź.
@@helloroman No jak nic nie zwracasz z funkcji async to zwraca undefined i to idzie do then (catch sie nie odpali), czyli funkcja then ci się odpali i będziesz miał const [beer] = undefined i potem leci cały kod z undefiend. Żeby to rozwiązać trzeba zrobić throw e; ale wtedy musisz też mieć catch na tej funkcji bo pójdzie error uncatch exception in Promise.
Oglądam te filmiki o js i stwierdzam, że to jest jakiś antyjęzyk... łączenie stringa brzydkie, używanie forEach na arrayach zamiast jak w normalnym języku statycznie typowanym jak c# w pętli foreach(var item in array) (albo jak zależy nam na kolejności to po prostu for). Czy na prawdę jeśli string template jest nowszy od varString + 'stringLiteral' to należy tego używać? Wygląda to na narzucanie innym jak mają pisać programy...
albo ta destrukturyzacja tablic... po co to? żeby zaoszczędzić 2-3 linie? jak taki const [beer] wygląda? Moim zdaniem nie za dobrze a już na pewno nie za czytelnie - to sobie ponarzekałem :P
proszę nie brać tego do siebie po prostu lubię narzekać szczególnie przez to, że "nauczyć się" webdevu próbuję z przerwami od kilku solidnych lat, z filmem wszystko w porządku :P
po prostu zamiast "template literals" trzeba mowic "string interpolation" ;) co do dekonstruktora - nie wime czy jest sens rozbijac beer na dwa obiekty, jak masz zdefiniowany obiekt (zwlaszcza w Typescriptcie) chyba nie ma sensu tego robic. co do metody getBeer - lepiej wrzucic ja do obiektu i do obiektu przekazac string z api jako parametr (i samego fetcha tez)
Z linkiem do API jako parametr to zależy do czego ma być ta funkcja i z jakich API korzystasz w projekcie. W tym przypadku nie było sensu podawać go jako argument. Ale nie do końca rozumiem rozkminę z dekonstruktorem, wyjaśnisz?
@@helloroman możesz podrzucić swój config na githuba, najbardziej interesuje mnie co to za theme i color scheme, dodatkowo ikonki jakieś customowe?. Gdybyś miał chwilę, dzięki. Pozdrawiam.
@@helloroman nie będzie tak źle, to nie pierwszy raz jak przeglądam kod, ale boję się tego co tam znajdę, bo było mało czasu na wyplucie nazwijmy to wersji demo, w stosunku do doświadczenia zespołu. Jak będziesz miał sposobność na zrobienie z tego jakiejś (mini) serii to pewnie dodam linka do zbioru, gdzie szukać dobrych praktyk w zespole :)
Sory Roman ale konkatenacja dwóch zmiennych za pomocą "Literal Template Strings" jest po prostu głupie, powiedziałbym że nieprawidłowe. Zapis: baseURL + id jest o wiele krótszy i czytelniejszy niż: `${baseURL}${id}` Po drugie mniej bezpieczny bo pod zmiennymi mogą kryć się wyrażenia i zmienne albo musza być z zaufanych źródeł albo trzeba było by je sprawdzać. Nie testowałem, ale podejrzewam , że jest to też bardziej czasochłonne bo ciąg musi być parsowany. Zresztą jest to wbrew idei powstania tej konstrukcji językowej, czyli budowania szablonów. Pewnie można znaleźć sporo innych sensownych zastosowań, ale takim najbardziej oczywistym jest wstawianie do DŁUGIEGO tekstu (szablonu) zmiennych. Akurat konkatenacja dwóch zmiennych to najgorszy z możliwych przykładów.
Jeśli korzystasz z ustawień AirBnB w ESlincie to nie masz możliwości tworzenia konkatenacji - wymuszane jest na Tobie użycie template'ów. Myślę, że w dużej mierze to co napisałeś jest po prostu kwestią opinii, więc nie będę się jakoś specjalnie kłócił.
@@helloroman Też specjalnie kłócić się nie będę, szczególnie że nie znam tego narzędzia i pewnie go nie poznam bo siedzę na backędzie. Natomiast mówienie że kod stał się bardziej elegancki w domyśle przejrzysty w zupełności zgodzić się nie mogę. Zrozumiał bym, od biedy, wtedy gdy był jakiś stały ciąg między zmiennymi, np: x = `${a}, ${b}` ale konkatenacja tylko 2 zmiennych wydaje się całkowicie bez sensu. To tak jak bym w PHPie gdzie parsowanie zmiennych było o zawsze napisał: $x = "$a$b"; zamiast: $x = $a.$b; Chyba wszyscy koledzy by mnie wyśmiali.
Andrzej Mazur rzadko w naturze spotyka się tak prosty template jak ten który napisałem, możliwe że powinienem był użyć bardziej skomplikowanego przykladu. Rzecz w tym że jak się już zdecydujemy na jedną konwencję to warto się jej trzymać
Krzysztof Gwóźdź xD trzeci komentarz o tym. Wiem ze nie musze, robie to odruchowo bo w 90% przypadkow cos destrukturyzuje. A dodatkowo mysli o tym za mnie eslint. Rzeczy tego typu naprawde nie sa istotne.
@@helloroman Jasne, rozumiem. Często w tym filmie wspominałeś o samym aspekcie wizualnym kodu, dlatego zwróciłem na to uwagę, bo według mnie pominięcie tych nawiasów również działa na to dodatnio ;)
![Jak pisać lepszy JavaScript cz. II [Prettier, ESlint i inne] ⌨️ hello roman #77](http://i.ytimg.com/vi/HjA_pMm86Jo/mqdefault.jpg)
![Jak pisać lepszy JavaScript cz. II [Prettier, ESlint i inne] ⌨️ hello roman #77](/img/tr.png)
![Kiedy zacząć uczyć się frameworków? [React, Vue, Angular etc.] ⌨️ hello roman #41](/img/n.gif)
Super odcinek! Zrób może jakąś serie "dobre praktyki programowania", gdzie pokazujesz:
1. Zły kod, często popełniany przez nowych developerów
2. Poprawiony kod. Mógłbyś zostawić w pliku oba kody i tłumaczyć bazując na złym kodzie, czemu się tak nie robi.
Odcinki 3-5 minutowe.
Bardzo by się przydała taka playlista na pasku zakładek.
Pozdrawiam! :)
Jeżeli to czytasz, proszę o odpowiedź, lub serduszko, żeby inni co popierają pomysł mogli się wypowiedzieć / zagłosować na niego.
MrFckingninja .
@@pabas3792 Słucham?
Więcej takich odcinków poproszę, otwierają one oczy młodszym programistą.
Nie korzystałam wcześniej użytkowo z destrukturyzacji tablic i chyba czas zacząć. Chętnie obejrzę więcej tipów. Dzięki!
Świetny odcinek, chętnie poznam więcej takich porad :)
Daję znać! Mega mi się podobało! Jak dla mnie, osoby które dopiero zaczyna swoją przygodę z JS , takie rady są bardzo cenne. Czekam na kolejny odcinek :)
Bardzo fajne rady. Jedynie o czym nie wiedziałem to o async / await.
Jeśli więcej jest takich smaczków to pewnie, że warto je poznać a przede wszystkim sprawdzić siebie. Zrobić pauzę i samemu pomyśleć, co można w przedstawianym kodzie zmieniać :)
Wielkie dzięki! ❤️ Za tydzień kolejne rady
Świetny odcinek 😀 bardzo przydatny dla wszystkich którzy się dopiero uczą 😀
Świetna forumła (y). Jestem jak najbardziej za, by było więcej tego typu odcinków. :D
Bardzo, dobry filmik.
Jednego czego mi brakuje to żeby była stara i nowa wersja, łatwiej byłoby widoczne zmiany. Teoretycznie można sobie zrobić screen i porównać co się zmieniło i jak bardzo. Ale jakby na górze byłą cały czas stara wersja kodu łatwiej jest śledzić każdy krok zmiany jaka została dokonana i np zatrzymać sobie filmik przeanalizować.
Dobra robota świetnie nadajesz się na nauczyciela, bardzo przejrzyście mówisz nie plączesz się. Przyjemnie się słucha i ogląda.
Super, czekam na następny. I szacunek za prostotę tłumaczenia.
Wielkie dzięki ❤️
Super odcinek czekam na następne !
Podobało. Dawaj dalej
Warto dodać, że wykonując push na tablicy, która jest constem wcale nie modyfikujesz tego czym jest nasza stała (dlatego js nam na to pozwala), pod naszą stałą znajduje się referencja na tablicę i to jej nie można modyfikować. Ta sama zasada tyczy się obiektów, gdy obiekt jest stałą - wciąż możemy dowolnie zmieniać wartości wewnątrz tego obiektu. Super odcinek, pozdrawiam ;)
Wszystko się zgadza, dzięki za doprecyzowanie ;)
Mega dowcip ;). Zwłaszcza gdy się urodziło w latach osiemdziesiątych i muzykę lat dziewięćdziesiątych się dobrze pamięta....
Super odcinek, duzo merytorycznego contentu! Oby wiecej takich odcinkow z nowoczesnymi praktykami!
Świetny odcinek! Wielkie dzięki za rady!
Panie Romku świetny materiał :)
Tipy od Ciebie zawsze na propsie. "Roman" zachęcam do kontynuacji następnych odcinków.
Super, czekam na nexta
Tego typu odcinki są bardzo przydatne, także jakbyśmy mieli głosować to ja jestem za! :) więcej trików i rad z js :)
Postaram się częściej wrzucać tego typu odcinki. Zwłaszcza, że teraz zrezygnowałem z tych poniedziałkowych i mam więcej czasu
Dej więcej, mam hory kod :D Świetny odcinek :) Oj, dostałbym po łapach przy code review od Ciebie ;)
Jestem z siebie dumny, że o większości wiedziałem ;) Odcinek świetny i przydatny. Więcej takich S'IL VOUS PLAIT :)
Dzieki! Jak masz swoje rady to dawaj ♥️
Ogólnie to chciałem powiedzieć, że jestem tylko 19 letnim gówniakiem ze szkoły średniej i moje rady mogą okazać się głupie, bo do juniora mi jeszcze daleko haha :) Ale z takich kosmetycznych rzeczy w tym przykładzie to zwróciłbym w funkcji getBeer data[0], wtedy można destrukturyzować od razu przekazany obiekt, w fetchu mimo wszystko ta klasyczna konkatenacja wydaje mi się bardziej czytelna "url + id", no i pozabierałbym te wszystkie nawiasy z funkcji strzałkowych, gdzie jest jeden argument, żeby było bardziej sexy, hehe.
Przepraszam jeżeli nie mam racji bo tak jak mówiłem wyżej nie mam żadnego doświadczenia i z chęcią się dowiem, jeżeli się mylę :).
data[0] powinno być rozwiązane po stronie API. Wysyłamy GETa na adres "url/:id", czyli spodziewamy się jednego elementu w odpowiedzi, a nie tablicy elementów, bo jak wiemy - id jest unikatowe :)
Sugeruję używanie nowego sposobu łączenia zmiennych z tekstem. Jest on po prostu bardziej elegancki.
Reszta to kwestia indywidualna.
Ale w tym API jak mówił Adam, biorąc jeden element dostajemy tablice [{}]. Zwracając data[0] nie musimy destrukturyzować const [beer] = data. Miałem na myśli ten konkretny przykład, zawsze trochę mniej kodu prawda :) A co do konkatenacji to rzeczywiście template string jest lepszy. Niepotrzebnie z tym wypaliłem, haha
@@wiktorbandura Zgadzam się, w tym konkretnym przykładzie Twoje rozwiązanie jest prawidłowe. Lecz z założenia funkcje mają być tak uniwersalne jak tylko się da (pozwala to oszczędzić sporo czasu na debugowaniu, gdy coś w łańcuchu działania aplikacji się zmieni), więc lepiej jest zwrócić całą tablicę, lub data[0] tak jak mówisz, ale opakowane w ifa, którym np logujemy info w razie wykrzaczenia ;D
Wiem, może się troszkę czepiam, ale kiedyś też nie zwracałem na to uwagi, a później lądowałem z ręką w nocniku, bo w API z którego korzystała moja stronka coś się zmieniło, a ja nie zabezpieczyłem należycie kodu :/
Podsumowując, żeby mój komentarz nie wyglądał tylko jak puste słowa krytyki:
1) Starajmy się tworzyć uniwersalne funkcje i obsługę błędu (try-catch, albo minimalnie chociaż jakiś console.log) - zaoszczędzi nam to wiele czasu w przyszłości,
2) Starajmy się odwoływać do konkretnego elementu jak najrzadziej, czy też go zwracać (głównie chodzi mi o elementy z httpRequestów), a jeśli już to opakować go w ifa - znowu zaoszczędzimy czas później ;)
3) Zdobywanie stażu programistycznego, to nauka na błędach, a lepiej uczyć się na błędach innych niż własnych.
Pozdro! :) Do juniora Ci bliżej niż myślisz. Mało osób w średniej szkole już coś sobie pisze :)
podoba się! chcemy więcej :)
Bardzo praktyczny odcinek! Sam najpierw zrobiłem CRkę żeby się sprawdzić i wyłapałem większość rzeczy tak jak Ty, oprócz async await 😎
Świetny odcinek, czekam na więcej 🙂
Dzięki, w końcu zrozumiałem async/await, jakoś nigdy nie mogłem zapamiętać jak to działa.
Świetny odcinek! Chętnie obejrzę inne porady :)
Dzięki! :) Za tydzień druga część
Super wytłumaczone :) chciałbym mieć taki code review na co dzień
Bardzo dobry materiał super to wytłumaczyłeś ja osobiście proszę o więcej takich materiałów ! 😁😁👌
Bedzie wiecej! Dzieki ♥️
*Kurs javascript by helloRoman* - Kamil wstawaj zesrałeś się ( ͡° ͜ʖ ͡°)
Cześć ! :)
A może coś o optymalizacji WordPressa? Jak przyśpieszyć wynik Google PageSpeed Insights?
Z tego co mi wiadomo trzeba mieć pewien zakres wiedzy programistycznej, a sporo ludzi szuka informacji na temat przyśpieszenia takich stron.
Pozdrawiam!
Dawaj więcej tego typu rzeczy! ❤️ ostatnie odcinki np. mi nie siadły, więcej mięsa!
Jak Ty to robisz że za każdym razem jak o czymś pomyślę to od razu wrzucasz na ten temat jakiś toturial/poradnik/odcinek ? :D
Tak bardzo fajny odcinek, nasza gawędź fanów prosi o większą ilość porad, w których pokażesz jak pisać POPRAWNY kod w oparciu O NOWE technologie :)
W końcu "załapałem" jak robić funkcje async-await. Dzięki
Nie mogę się doczekać platformy, którą tworzysz. Masz dar dydaktyczny
dobry odcinek, koniecznie nagraj drugą część
Dzięki wielkie :) Za tydzień wrzucam kolejną część
Bardzo fajny odcinek! Chcę więcej. Pozdrawiam :)
Roman odcinek super, proszę o więcej kciuk w górę
Jasne, ze chcemy więcej, świetny odcinek! 👌👊
Świetne, praktyczna wiedza w pigułce :)
Z arrow function czasami trzeba uważać :) Zwłaszcza jak chcemy mieć dostęp do arguments lub bawimy się z scopem :) Poza tym arrow function są SUPER!
Każda dobra rada na wagę złota :)
Część wiem że jesteś po frontedowej stronie mocy , ale słyszałeś albo używałeś może NestJs , uważam że nie jako wymusza on dobre praktyki związane z programowaniem , po za tym rozbicie backendu na warstwy , skupienie się na domenie czyli programowanie DDD powodują że aplikacje są łatwo skalowalne. Jak ktoś programował wcześniej w c# .net core to wiele podobnych rzeczy może znaleźć dla siebie .
A nie jest jeszcze przypadkiem tak, że jak mamy tylko jeden parametr w funkcji strzałkowej, to możemy pominąć nawiasy? Jak dla mnie to też może poprawić jakość kodu, warto o tym wspomnieć.
Poza tym super odcinek, jak zawsze! :)
Dzięki za świetny odcinek, czekam na więcej!
Jak się nazywa theme z którego korzystasz ?
dzieki! Material Dark Oceanic
Hej fajny odcineczek :D. Tylko zastanawiam się po co jest ten .then((data) => data) skoro response.json() zwraca Promise to on rekurencyjnie sobie sprawdzi czy to cos co nie jest zwracane jest promisem i jak coś to zaczeka i w następnym then otrzymasz już tylko dane z tego promise który jest zwracany, więc teoretycznie ta funkcja nic nie robi, jest sobie funkcją identity :)
życzę Wszystkim oglądającym miłego dnia :)
Serdecznie dziękuję za takie życzenia
Spoko odcineczek! Może jakiś odcinek o performance? Jak pisać kod, żeby działał możliwie szybko, czego unikać itd.?
Robiłem taki odcinek o CSS, może Cię zainteresuje :) O JavaScript jeszcze nie miałem okazji
@@helloroman tak widziałem, czekam na odcinek o JS :) Pozdrawiam
O to było dobre! thx Ziom :)
Tak ja chcę więcej takich odcinków.
przy pierwszym przykładzie dobrze by było przypisać długość tablicy do zmiennej i tą zmienną używać w pętli.
Tutaj może różnicy nie robi, ale przy większych tablicach sprawdzanie za każdym razem jej długości może obciążyć procesor.
Niekoniecznie → mrale.ph/blog/2014/12/24/array-length-caching.html
W skrócie: nie musimy robić mikrooptymalizacji, bo silniki JS są zwykle na tyle mądre, że robią to same ;)
@@ComandeerPL to jest bardzo dobra wiadomość. Dzięki za pozytywne wibracje :)
No i namówił. Idę do sklepu
7:59 consty tego typu (czyli prostego typu, z faktycznie stałymi wartościami) preferuję nazywać DUŻYMI_LITERAMI. Jak rozumiem ta konwencja nie jest stosowana w JS?
Jak slusznie zauwazyles to zalezy od konwencji. Ale faktycznie w prawdziwych projektach tez uzywam takiego zapisu jak zasugerowales 👍
Te try/catche mnie trochę mierzą. W Node ich używam, ale jeżeli chodzi o front to dla mnie osobiście promise'y wyglądają przejrzyściej jeżeli połączymy je z czystymi funkcjami. W takim układzie każdy 'then(nazwaFunkcji)' zajmuje zawsze jedną linijkę, a mamy jednak lepszą prozę. Plus w promise mamy finally (choć w try/catch po prostu to się da za blokiem funkcji zwyczajnie). Ale nie powiem - przykład z piwnym api broni się bardzo :)
Dla tych co nie wiedzą: then(nazwaFunkcji) i then(res => nazwaFunkcji(res)) to to samo. No i jest to szansa na nazwanie tego co robimy zamiast po prostu to robić, żeby w przyszłości nie musieć się domyślać o co nam chodziło.
Podobny odcinek byłby super :D
Już za tydzień :)
Na etapie w jakim jestem z JS to przyswoilem patent z control+g...tez dobrze...😏
Część Roman nazywam się Aleks i jestem w technikum PROGRAMISTYCZNYM w klasie 1. I chciałem zapytać czy zrobił byś odc z jakimiś tipami poradami do dotychczasowego js ale tego czystego bez bibliotek.
Przecież ten odcinek o tym jest
Świetny odcinek. Poproszem wincyj!
erykwks zgadza sie, zawsze mi sie miesza xD
Wszystko pięknie. Tylko 2 pytanka. Dlaczego nie zamieniłeś wszystkich then? Co jak wolę then i catch, bo mogę po jakimś ciągu napisać tylko 1 catch? :)
Yo! 1. Zapomniałem na śmierć o tym drugim, dzięki że napisałeś xD 2. W async/await też możesz zrobić jeden catch po ciągu awaitów.
Spoko tipy, Są przydatne ;)
Czemu destrukturyzacja jako osobne `const`y a nie bezpośrednio w parametrach? Osobiście stosuję ten drugi sposób (github.com/Comandeer/rollup-plugin-babel-minify/blob/master/tests/helpers/createTransformTest.js#L24-L30 ), chociaż często słyszę, że jestem fanatykiem destrukturyzacji :D
Osobiście też mam mieszane uczucia względem `fetch`. Z jednej strony jest przyjemniejsze do pracy niż XHR, z powodu swojego API opartego o `Promise`. Z drugiej zaś - to dość low-levelowe API, na co wskazuje choćby fakt, że sami musimy zająć się przerabianiem pobranych danych na strawny format (`response.json()`). XHR ma tę przewagę, że wystarczy określić typ zwracanej odpowiedzi (XML, JSON, text czy nawet drzewko DOM) i po prostu dostajemy wszystko już przeparsowane i gotowe do działania. A eventowe API można obejść małą funkcją-helperem, przerabiającym to na `Promise`.
W praktyce prawie zawsze korzystam z axiosa, więc korzystanie z fetcha jest dla mnie swego rodzaju egzotyką 😂Ale jak zwykle masz sporo racji. Co do destrukturyzacji w parametrach, to mógłbym to zrobić, gdyby ten element nie był wewnątrz tablicy 🤔Chyba, że masz jakiś pomysł?
@@helloroman, `getBeer( 5 ).then( ( [ { name, description } ] ) => { […] } );`. Jak dla mnie czytelne.
Tomasz Jakut ej nie robiłem tak nigdy ♥️ thx!
mógłbym prosić o motyw vsc? Pozdrawiam
Muszę rozchodzić ten suchar
Hahaha 😂No to jest jeden z tych wytrawnych co mordę wykręcają
Romku prosimy o więcej
Bedzie wiecej 🚀
cześć jestem dosyć młody lecz chcę wiązać moją przyszłość z programowaniem nie miałem nigdy z tym do czynienia więc myślałem o nauce z książek przy czym nie wydając dużej ilości pieniędzy polecił byś jakąś książkę lub inny sposób nauki ? podkreślam nie miałem nigdy z tym do czynienia .
Wszystko super i fajnie omówione ALE... :D
Po kursach z Kylem Simpson'enm na FM, chyba jestem bardziej skłonny iść w stronę używania var, const, let do wyrażania tego co moja zmienna ma robić, albo jaką informacje ma przekazywać czytającemu kod. Const jest na tyle perfidny że używanie go przy tablicach czy obiektach bardzo psuje czytelność kodu ( myli czytającego, który widzi chwile później .push na tej tablicy ), zwłaszcza dla osób które const znają z innych języków. C zęsto moje funkcje zwierają IIFE, albo krótkie wyrażenia która zamykam w {}, i tam let jest idealny( jeśli chce tymczasową zmienną ), ale jeśli w tym samym miejscu używam zmiennej która pochodzi ze scope'a wyżej to czytelniejsza jest dla mnie informacje jeśli ta zmienna jest varem, a nie let'em. :) Ex.
(function namingAnonymousFunctionIsCool(){
var someNumber = 1;
{
let i = someNumber;
i--;
someNumber = i;
}
})
Kyle Simpson serio tak stosuje vary i lety? Totalnie mi nie podchodzi coś takiego
Dobry odcinek, właśnie dobrych praktyk brakuje mi najbardziej. Fajną opcją byłoby gdybyś np: na koniec każdego odcinka wrzucał 2 dobre praktyki w js, nawet w formie hasłowej, bo żaden poradnik nie zawiera wszystkich, a najtrudniej jest pisać czysty kod jak się ich nie zna :) Pozdrawiam
Fajny odcinek, ale...
.then((data) => data)
what? :O
PS. Co prawda VS Code jest najpiękniejszym edytorem do JavaScriptu, a produkty JetBrains są płatne, nieszczególnie ładne, zamulają wolniejszego kompa i mają cięższy learning curve, ale nie mogę nie powiedzieć, że takie rzeczy, jak zmiana function na =>, wywalenie zahardcode'owanej wartości do zmiennej, czy zamiana konkatenacji stringów na template literal to jest tam zautomatyzowana i można sobie coś takiego zrobić za pomocą 2-4 naciśnięć klawiatury.
Roman, te stringi wyglądają dużo lepiej.
Jakiego extension-a używasz do tego migającego kursora? I w jaki sposób robisz to multiple cursor (inaczej niż CMD+OPTION+SHIFT+ARROW)? Pozdro!
Sprawdz sobie go to next occurance bo mozesz miec inny skrot
@@helloroman Dzięki. Ogarnięte :) A co to efekt z tym kursorem?
Mam pomysł na całą serię. Może by tak ludzie do ciebie wysyłali jakieś proste małe projekty z swoi kodem, a ty byś go recenzował wskazując jego wady i dobre strony?
To już wtedy się nie nazywa code review, tylko public shaming 😃Nie chciałbym robić czegoś takiego
@@helloroman Zawsze można zanonimizować. Zresztą miałbyś kontrole nad tym, co się dostanie na odcinek, a co nie. Minusem jest pewnie natłok pracy, bo to trzeba przejrzeć, ocenić, znaleźć niedociągnięcia. Nawet mały projekt może być "rozległy" , ostatnio zrobiłem zadanie rekrutacyjne, to wyszło mi 60 plików (SASS/HTML/JS). Plusem jest natomiast realny kod adeptów programowania, zawierający rzeczywiste błędy. W każdym razie dzięki za odpowiedź.
Co do let-ów i const-ów, polecam odcinek MPJa z kanału FunFunFunction. 😃
Chciałbym być taki cool jak MPJ ❤️
@@milesq th-cam.com/video/sjyJBL5fkp8/w-d-xo.html
@@helloroman No nie wiem, ja tam wolę Romana ;D
Super bylby odcinek pod tytulem - ”jak utrzymać strukturę dużych plików JS i nie zwariować” XD
super odcinek
jak się nazywa ten dodatek z animacją kursora?
Wydaje mi się, że mam to ustawione jakoś w VSC po prostu - zerknę i postaram się wrzucić
Można ustawić w settings np:
"editor.cursorStyle": "line-thin",
"editor.cursorWidth": 2,
"editor.cursorBlinking": "expand",
Więcej!!!!!!
Ja bym jeszcze dodał wartości domyślne po destrukturyzacji "beer" dla "name" i "description" ;)
Fakt, w ogóle domyślne wartości w destrukturyzacji są super ❤️
Jak masz try..catch w async i nie wyrzucasz go dalej to then się wykona z undefined więc Ci się wysypie aplikacja.
Jakub T. Jankiewicz hej, możesz rozwinąć?
@@helloroman No jak nic nie zwracasz z funkcji async to zwraca undefined i to idzie do then (catch sie nie odpali), czyli funkcja then ci się odpali i będziesz miał const [beer] = undefined i potem leci cały kod z undefiend. Żeby to rozwiązać trzeba zrobić throw e; ale wtedy musisz też mieć catch na tej funkcji bo pójdzie error uncatch exception in Promise.
Z filmiku o tipach, w którym tylko poruszyłeś async/await zrozumiałem jak to działa, a nie dawałem rady z tutków, gdzie było to obszernie opisane...
Możliwe, że musisz jeszcze trochę doczytać bo totalnie po łebkach to opisałem. Polecam kurs Willa Sentence'a „The new hard parts”
Oglądam te filmiki o js i stwierdzam, że to jest jakiś antyjęzyk... łączenie stringa brzydkie, używanie forEach na arrayach zamiast jak w normalnym języku statycznie typowanym jak c# w pętli foreach(var item in array) (albo jak zależy nam na kolejności to po prostu for). Czy na prawdę jeśli string template jest nowszy od varString + 'stringLiteral' to należy tego używać? Wygląda to na narzucanie innym jak mają pisać programy...
Strzałeczki lepsze of function? Dla mnie function bardziej czytelne
albo ta destrukturyzacja tablic... po co to? żeby zaoszczędzić 2-3 linie? jak taki const [beer] wygląda? Moim zdaniem nie za dobrze a już na pewno nie za czytelnie - to sobie ponarzekałem :P
proszę nie brać tego do siebie po prostu lubię narzekać szczególnie przez to, że "nauczyć się" webdevu próbuję z przerwami od kilku solidnych lat, z filmem wszystko w porządku :P
Jakiego programu używasz do programowania ?
W pracy Webstorm, do filmików visual studio code
po prostu zamiast "template literals" trzeba mowic "string interpolation" ;)
co do dekonstruktora - nie wime czy jest sens rozbijac beer na dwa obiekty, jak masz zdefiniowany obiekt (zwlaszcza w Typescriptcie) chyba nie ma sensu tego robic.
co do metody getBeer - lepiej wrzucic ja do obiektu i do obiektu przekazac string z api jako parametr (i samego fetcha tez)
Z linkiem do API jako parametr to zależy do czego ma być ta funkcja i z jakich API korzystasz w projekcie. W tym przypadku nie było sensu podawać go jako argument. Ale nie do końca rozumiem rozkminę z dekonstruktorem, wyjaśnisz?
Jaka czcionka w vscodzie? :P
Fira
@@helloroman możesz podrzucić swój config na githuba, najbardziej interesuje mnie co to za theme i color scheme, dodatkowo ikonki jakieś customowe?. Gdybyś miał chwilę, dzięki.
Pozdrawiam.
Również byłbym chętny na config
Skąd te tapety? ;)
GFDA
Wincyj 😃
Super
Odcinek rychło w czas, bo akurat mam się wziąć za review aplikacji ;_;
Oj to te pare rad moze nie wystarczyc :D
@@helloroman nie będzie tak źle, to nie pierwszy raz jak przeglądam kod, ale boję się tego co tam znajdę, bo było mało czasu na wyplucie nazwijmy to wersji demo, w stosunku do doświadczenia zespołu.
Jak będziesz miał sposobność na zrobienie z tego jakiejś (mini) serii to pewnie dodam linka do zbioru, gdzie szukać dobrych praktyk w zespole :)
Sory Roman ale konkatenacja dwóch zmiennych za pomocą "Literal Template Strings" jest po prostu głupie, powiedziałbym że nieprawidłowe.
Zapis:
baseURL + id
jest o wiele krótszy i czytelniejszy niż:
`${baseURL}${id}`
Po drugie mniej bezpieczny bo pod zmiennymi mogą kryć się wyrażenia i zmienne albo musza być z zaufanych źródeł albo trzeba było by je sprawdzać.
Nie testowałem, ale podejrzewam , że jest to też bardziej czasochłonne bo ciąg musi być parsowany.
Zresztą jest to wbrew idei powstania tej konstrukcji językowej, czyli budowania szablonów. Pewnie można znaleźć sporo innych sensownych zastosowań, ale takim najbardziej oczywistym jest wstawianie do DŁUGIEGO tekstu (szablonu) zmiennych.
Akurat konkatenacja dwóch zmiennych to najgorszy z możliwych przykładów.
Jeśli korzystasz z ustawień AirBnB w ESlincie to nie masz możliwości tworzenia konkatenacji - wymuszane jest na Tobie użycie template'ów. Myślę, że w dużej mierze to co napisałeś jest po prostu kwestią opinii, więc nie będę się jakoś specjalnie kłócił.
@@helloroman Też specjalnie kłócić się nie będę, szczególnie że nie znam tego narzędzia i pewnie go nie poznam bo siedzę na backędzie.
Natomiast mówienie że kod stał się bardziej elegancki w domyśle przejrzysty w zupełności zgodzić się nie mogę.
Zrozumiał bym, od biedy, wtedy gdy był jakiś stały ciąg między zmiennymi, np:
x = `${a}, ${b}`
ale konkatenacja tylko 2 zmiennych wydaje się całkowicie bez sensu. To tak jak bym w PHPie gdzie parsowanie zmiennych było o zawsze napisał:
$x = "$a$b";
zamiast:
$x = $a.$b;
Chyba wszyscy koledzy by mnie wyśmiali.
Andrzej Mazur rzadko w naturze spotyka się tak prosty template jak ten który napisałem, możliwe że powinienem był użyć bardziej skomplikowanego przykladu. Rzecz w tym że jak się już zdecydujemy na jedną konwencję to warto się jej trzymać
Jeśli przekazujesz tylko jeden argument w funkcji strzałkowej to nie musisz już go pakować w nawiasy.
Krzysztof Gwóźdź xD trzeci komentarz o tym. Wiem ze nie musze, robie to odruchowo bo w 90% przypadkow cos destrukturyzuje. A dodatkowo mysli o tym za mnie eslint. Rzeczy tego typu naprawde nie sa istotne.
@@helloroman Jasne, rozumiem. Często w tym filmie wspominałeś o samym aspekcie wizualnym kodu, dlatego zwróciłem na to uwagę, bo według mnie pominięcie tych nawiasów również działa na to dodatnio ;)
Jak najbardziej masz rację 👍
"mamy faktycznie zmienną która jest stałą" :D
XD to je javascript. Tego nie pomalujesz.
Wincyyyyyjjjjj!!!
` Sie podobało ${😁} `
wincy ! :)
Bydzie! 😂
Rewelka
constius manx*
Tak by się nazywał ich cover band 😂
too basic. more advanced examples pls ;]
Yes sir ;)
Romku prosimy o więcej