@LukeJL: @pan_krewetek:
Może faktycznie za szybko... Problem w tym, a może własnie nie problem... że zdaję sobie z tego sprawę. Zadałem sobie zadanie, wzorowałem się na innym projekcie na klasach. Ale na zasadzie przeglądnę max 1h, zamknę i robię swoje. No i niby projekt działa i tak jak mówicie, człowiek zdał sobie sprawę że w pewnym momencie za szybko leciał z tematem.
Mówią żeby na początku nie tracić czasu na pierdoły i nie spuszczać się 3h nad jedną rzeczą - nie mówię o rozwiązaniu problemu który się napotka, a bardziej o kwestie np. performance. Czy uzyć listenera i eventdelegation. To taki przykład bo na początku wydawało mi się, że nauczę się kiedy - i co używać. Ale widzę że to tak nie działa.
Projekt na pewno będę chciał jeszcze rozwinąć, ale pewnie go przepiszę jak zdobędę trochę wiedzy. By nie robić tego 2-3 razy.
Czyli waszym zdaniem olać sprawę i przyjdzie to samo z czasem? Może się wam wydać że przyszedłem tu szukać złotego środka na naukę, nie chcę być źle zrozumiany. Po prostu widzę że jak coś zaplanuję, to nauka idzie lepiej. Chodzi mi o focus nad jedną rzeczą, a nie skakanie po zagadnieniach bez celu.
Obejrzałem 3 projekty taskList - jakkolwiek banalnie to brzmi i nudnie. 3 różne podejście. MVC, zwykłe funkcyjne i trzecie na zasadzie fabryki ( chyba, bo nie mam wiedzy, ale kod przypominał tworzenie komponentów za pomocą dodatkowo ręcznie napisanej biblioteki ).
Pewnie trzecie podejście to przerost formy nad treścią. Ale zastanawiałem się jak takie publiczne apki, wypuszczone od profesjonalnych devów wyglądają.
To tylko przykłady które zamieszały mi w głowie.
Jak się zaczyna projekt, to wygodnie jest robić wszystko w jednym pliku i używać zmiennych globalnych.
Jak masz kilkadziesiąt linijek kodu, to naprawdę nie trzeba tego dzielić na 10 różnych plików ani robić super eleganckiego kodu.
Problem jest, żeby wychwycić moment, kiedy zacząć refaktorować i wydzielać rzeczy do modułów (albo do osobnych funkcji, do osobnych klas itp.)
Rozumiem. Zauważyłem też, że zbyt szerokie skupianie się na problemie powoduje że ciężko zacząć. Jak podzielę to na mniejsze problemy i implementuję to jakoś leci, i jeszcze niemożliwe wcześniej po 3h jest napisane ( dunno how ).
Także jak skupisz się zbytnio na czystych kodach to w efekcie będzie to wyglądać tak jakbyś poprzez formę chciał ukryć swoje braki.
Chyba faktycznie zacząłem za dużo myśleć.
Przed frameworkiem warto poznać podstawowe narzędzia typu NPM, webpack, moduły, robienie bundla. To tego TypeScript też się przyda. Co do klas, to w JS można bez tego żyć, wydzielając funkcje i > stosując moduły. Funkcyjny React pokazuje, że bez klas można się obyć, chyba że wolisz Angulara. W backendzie w Node też można stosować funkcyjne podejście i zapomnieć o this.
TypeScript wypada kojarzyć czy warto coś umieć napisać. Nie wiem w którą stronę chciałbym iść. Na pewno spróbuje Reacta na początku. Na razie daję sobie rok z Jsem.
Trochę mnie podbudowaliście. Wrócę na ścieżkę nauki którą kontynuowałem i będę wracał do zagadnień które poruszyłem w tym projekcie co robiłem. Pobijając błędy które tu zrobiłem.
Nie chciałem się żalić, ale taki post chyba wyszedł. Jestem otwarty jeszcze na jakieś rady.
Wrócę do braków: Fetch, moduły, npm, babel itd..
sięgaj do fachowej literatury
Chodzi o książki czy arty znanych pro / publicystów programistów ?