NOVINKA - Online rekvalifikační kurz Python programátor. Oblíbená a studenty ověřená rekvalifikace - nyní i online.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Diskuze – Lekce 9 - OOP diář v JavaScriptu - Formátování a mazání záznamů

Zpět

Upozorňujeme, že diskuze pod našimi online kurzy jsou nemoderované a primárně slouží k získávání zpětné vazby pro budoucí vylepšení kurzů. Pro studenty našich rekvalifikačních kurzů nabízíme možnost přímého kontaktu s lektory a studijním referentem pro osobní konzultace a podporu v rámci jejich studia. Toto je exkluzivní služba, která zajišťuje kvalitní a cílenou pomoc v případě jakýchkoli dotazů nebo projektů.

Komentáře
Avatar
Petr Zabransky
Člen
Avatar
Odpovídá na Lubor Pešek
Petr Zabransky:19.2.2023 12:20

To "centrální spouštění" najdeš v souboru ./SRC/TS/index.ts . Možná by bylo lepší to řešit tak, že bych si v HTML vytvořil prázný element s ID a JS by tam jen vyrenderoval obsah toho elementu. Nebo to řešit úplně jinak. Začínám s tím, tak zatím zkouším a pátrám. Aby to bylo prostě jednoduché a logické. Pro SEO je podle mě nejlepší když komponenta už existuje v HTML se všemi texty a JS jen obsluhuje události.

 
Odpovědět
19.2.2023 12:20
Avatar
Petr Zabransky
Člen
Avatar
Petr Zabransky:19.2.2023 12:38

Ten příklad s jednou hlavní komponentou, která v sobě obsahuje ostatní komponenty je asi ideální OOP. To si dovedu představit třeba u desktopových aplikací i z hlediska předávání argumentů, zapouzdření atd. Krásná práce. Ale u webu, kde mám část jen statický text, část jednoduché komponenty s funkcemi a jinou část, kde probíhají složitější objektové události mi to přijde nereálné. Navíc objekty jsou navázané na elementy v DOMU, což to ještě více komplikuje. Možná na to jdu ale špatně a řeší se to úplně jinak.

 
Odpovědět
19.2.2023 12:38
Avatar
Petr Zabransky
Člen
Avatar
Odpovídá na Lubor Pešek
Petr Zabransky:19.2.2023 12:41

Jinak stylování komponent teď neřeším. To dělám pomocí SASS + BEM. Řeším vlastně obsluhu těch komponent javascriptem a nejraději bych to měl všechno jako objekty.

 
Odpovědět
19.2.2023 12:41
Avatar
Lubor Pešek
Člen
Avatar
Odpovídá na Petr Zabransky
Lubor Pešek:19.2.2023 16:28

Mám za to, že tento druh přemýšlení tě jednou zavede na cestu, kdy budeš muset ať už na straně serveru nebo i na straně clienta držet spoustu komponent v paměti.
Toho by ses měl na webových aplikací hodně vyvarovat.

Dokonce jsem zjistil, že je lepší nevytvářet přímo nějaké obsáhlé komponenty jako takové, ale vytvářet si jednoduché divy. Ty potom přes třídy v cssku stylovat a pokud možno nervat do nich moc funkcí. Proč? Protože musíš brát v úvahu, že web je interpret. Čím míň toho musí dynamicky načítat, tím je to vždycky lépe.

Proto to třeba zní i šíleně, ale i blbá tabulka vytvářená přes divy je pro performance lepší, než používat kupříkladu přímo HTML tag table.
Proto osobně na webu přemýšlím stylem - komponentu si pouze nějak obecně stylovat pomocí tříd a potom její funkci řešit přes JS.

A teď zkusím tedy návrh. Tak, jak to popisuješ, tak je to v podstatě jednoduché. V jednom jediném JS souboru si nadefinuješ veškeré třídy a na tento soubor se vždy odvoláš, když budeš konkrétní třídu vytvářet. Řešil bych to přes parametry. Musíš najít co nejvíce společných prvků a pak už jen pomocí parametrů ovlivňovat chování každé třídy. Tam, kam bude potřeba, tam narveš statický text. (to bych dal jako první parametr). No a druhým parametrem bys třeba mohl dát pole metod (JS na rozdíl od Javy dokáže pomocí parametru předávat i metody, což se ti zde bude perfektně hodit) a v té třídě už potom tohle chování zpracuješ. Jednotlivé metody opět můžeš mít v dalším separátním souboru a nebo pokud budou příliš unikátní, tak je definuj přímo na místě, odkud to budeš provolávat.

Čili budeš mít potom ve výsledku nějakou funkci, která bude z dalšího JS soboru spouštět tu danou metodu (případně vytvářet takový objekt), který potřebuješ.
No a vždycky se budeš odkazovat právě na to jedno centrální místo, odkud tuhle metodu zavoláš a lišit se to bude už pouze a jenom v těch parametrech.

Potom je tu ještě jedna věc - jestli si nechceš hrát na Spring container, který by vytvořil naprosto všechny objekty, ty měl někde uchované a s nimi pak pracoval... To je dobré právě pro kompilovaný program, který může tuhle paměť využívat a je i efektivní. Otázka je, na co by ti to bylo na webu. Ok, můžeš mít třeba pod okno, kterým chceš pracovat s dřívějším objektem.
Lehká pomoc - v takovém případě nemusíš tahat nic z centrální paměti, ale objekt, který třeba jen upravuješ nebo ze kterého potom taháš data, tak si při přepínání stránek přesuneš v nějakém modelu v parametru.

Ono to takto v podstatě funguje i v praxi. Nikdy si nepamatuješ úplně všechno, ale vytváříš čisté objekty. Data do nich narveš pak třeba z databáze. Ale jakmile dokončíš nějaký proces, tak je zbytečné si cokoliv pamatovat.

Příklad: Když dejme tomu vytváříš nějakého uživatele. Tak vytvoříš nový objekt a otevřeš nový formulář. Tento objekt naplníš vloženými daty (rovnou provádíš i validaci - je důležité rozlišovat, jakou validaci je třeba provést na webu a jakou na backendu. Pokud jedeš jen web, tak musíš pak provádět všechno samozřejmě). No a dále pak data uložíš do databáze a tím celý proces končí a ty tento objekt už nepotřebuješ nijak držet v paměti. Na co?
Potom, když budeš s tímto uživatelem chtít pracovat, tak vytvoříš nový objekt a pomocí IDčka si dokážeš vytáhnout z databáze data, kterými nový objekt naplníš. A pak jej používáš pro to, pro co je daný objekt v tu chvíli určen. A pak jej zase zahodíš.

To samé třeba ty komponenty jako takové. Ty si nepotřebuješ nikde držet v paměti veškerá tlačítka, která se v aplikaci budou používat.
Mohlo by to mít jeden dobrý efekt a to, že by sis třeba mohl i nějak u toho kontrolovat, kde všude se daná komponenta využívá. Když potom zjistíš, že komponentu nevyužívá nikdo, mohl bys její definici smazat. To by mohla být malá výhoda, ale...
Ber to tak, že dobrý web má různá práva pro jiné uživatele. Kupříkladu že nějaké tlačítko se zobrazí danému uživateli, ale jinému ne. Nějaký combo box bude mít takovou nabídku a druhý bude mít zase jinou (na stejné stránce, ale jiným uživatelům).
Pak bys musel veškeré tyhle informace a data načítat už na startu. Ano, potom bys to mohl mít teoreticky rychlejší, ale za čas bys měl nesmírný problém s pamětí.
A to se bavíme jen o tom, že ten web bude využívat jeden člověk. Až bys dělal web, na kterém ti bude řádit 10 000 uživatelů a každý z nich bude furt provádět nějaký request, tak se z toho celý systém posere, když už na začátku vyplýtváš spoustu paměti jen na ukládání všech komponent.

Dneska se právě řeší, kde všude ušetřit místo, aby se toho v paměti ukládalo co nejméně.
Těžké je mnohdy i vybilancovat, do kdy má smysl ukládat si statická data z databáze do paměti, abychom ušetřili čas posíláním requestu třeba z nějakého výčtu.

Jak jsem psal - spíš se skutečně vše dělá tak, aby komponenta byla co nejjednodušší a v podstatě se vždy vytvářela ve chvíli, kdy bude potřeba.

Odpovědět
19.2.2023 16:28
Existují dva způsoby, jak vyřešit problém. Za prvé vyhoďte počítač z okna. Za druhé vyhoďte okna z počítače.
Avatar
Lubor Pešek
Člen
Avatar
Odpovídá na Petr Zabransky
Lubor Pešek:19.2.2023 16:39

U webových aplikací musíš malinko jinak přemýšlet, než třeba u desktopu. Tam můžeš zamrdat paměť bez problémů (samozřejmě s rozumem:D) a kór v dnešní době to nebude až tak vadit.
Ale web je o dynamičnosti. Když budeš používat jednoduché komponenty, tak ty můžeš vytvářet tehdy, kdy je budeš potřebovat. Na tom jsou právě frameworky založené. Ty si v HTMLku v konečném důsledku vždy vytváříš to, co se v dané části na stránce změní. Neměníš už dokonce ani celou stránku, ale vždy část, která se dynamicky mění.
No a v takovémto případě vážně nemusíš mít vytvořené veškeré komponenty předem. Na co?
Na co ti je kupříkladu komponenta pro combo box u formuláře, který má jen textová pole a tlačítko? V tuhle chvíli si zbytečně držíš místo v paměti komponentou, kterou nepotřebuješ.
A když ji potřebuješ, tak ji v danou chvíli lehce vytvoříš.

Ten centrální přístup, který jsem zde popisoval, tak platí zejména pro data.
Můžeš takhle z jednoho místa využívat společné metody, kterým se pak následně právě dostaneš k požadovaným datům.

Příklad, který jsem zde uváděl, tak byl pro návrh programu, který nepočítá s dynamickým rozložením webu, kdy si každá stránka bude vše spravovat sama.

Každopádně pokud bys fakt měl takový návrh, kdy by dejme tomu třeba 20 komponent mezi sebou skutečně moc často komunikovali napříč celou aplikací a vzájemně se ovlivňovaly, tak samozřejmě takové věci nejjednodušeji řeší pole nebo ještě lépe mapa.
A klidně pro tvůj přehled (abys nemusel šíleně pracovat třeba s IDčkami atd.) tak si vytvoř mapu map neboli mapu, která spravuje jednotlivé mapy pro každé komponenty. Konkrétně bych to viděl tak, že v té hlavní mapě bude mapa pro tlačítka, pro combo boxy, pro text fieldy, pro color pany atd. No a potom každá vlastní mapa v sobě si už bude pod nějakými hesly pamatovat danou komponentu, kterou budeš potřebovat.
No a takhle budeš mít uloženou "lokální databázi" v paměti a budeš moct s těmi objekty komponent přímo pracovat mezi sebou.

Ale vážně bych se na webu tomuhle řešení snažil vyhnout. Tohle řešení je buď na desktop a nebo na návrh nějaké webové aplikace, která je jen na jedné stránce.
Pak ale předpokládám, že těch komponent nebudeš mít tolik, aby to byl tak závažný problém a nenapadlo by tě použít mapu.

Odpovědět
19.2.2023 16:39
Existují dva způsoby, jak vyřešit problém. Za prvé vyhoďte počítač z okna. Za druhé vyhoďte okna z počítače.
Avatar
Lubor Pešek
Člen
Avatar
Odpovídá na Petr Zabransky
Lubor Pešek:19.2.2023 16:55

Tak beru zpět :) Podíval jsem se na tvůj kód a chápu tedy, že všechno máš v jednom souboru a web jako takový nestyluješ do více stránek.
Sorry, já už jsem asi hodně zkažený frameworkem, takže už deafultně očekávám, web o více stránkách.

Tak pak ano, tak jestli to máš takhle jednoduché, tak i tvůj dotaz dává smysl a pak je fakt jednoduché řešení mapa a map, jak jsem popisoval. A jsi vysmátý. Každý objekt při vytváření vložíš do této mapy a pak už si jej taháš pouze odsud.

Odpovědět
19.2.2023 16:55
Existují dva způsoby, jak vyřešit problém. Za prvé vyhoďte počítač z okna. Za druhé vyhoďte okna z počítače.
Avatar
Petr Zabransky
Člen
Avatar
Odpovídá na Lubor Pešek
Petr Zabransky:19.2.2023 18:31

Děkuju moc za vysvětlení 👍 To s tou pamětí mě vůbec nenapadlo. Zatim to mám sice jednu stránku a učím se na tom, ale plánuju to rozšířit a chci se to učit od začátku správně a vidět to v širším kontextu. Je to docela složité jak vidím. Možná proto to většina firem řeší těmi frameworky. Ten FW tě přecejen drží v urcitych kolejích a řeší spoustu věcí za tebe a pak je to i čitelnější po druhych. Možná nakonec ustoupím a půjdu s dobou a naučím se ten React. Chtěl bych už někde nastoupit i treba na zkoušku a pak se vyvíjet. Takhle nevím, co se přesně ucit ikdyz tu jsou nějaké osnovy. Tech technologií a variant je spousta a každá firma to ještě řeší jinak a u nás na Ostravsku není zase tolik firem, které by se o juniory praly. Tak ještě jednou děkuju moc za ochotu a tvůj čas 👍🙂

 
Odpovědět
19.2.2023 18:31
Avatar
Lubor Pešek
Člen
Avatar
Odpovídá na Petr Zabransky
Lubor Pešek:19.2.2023 22:21

Neexistuje "správné" řešení. Máš tu tři faktory. Cenu/čas vývoje, výkon, čistý kód. NIKDY se ti nepodaří najít takové řešení, které by bylo dobré pro všechny tyto složky:) Vždycky je to max 2 na úkor jednoho.
Navíc žádné řešení není správné.
Na to, co jsem psal, tak se podívá 10 programátorů. 2 z nich netuší, o čem je řeč, 4 se chytí za hlavu, co to píšu za ptákoviny, 4 se mnou budou souhlasit.

Musíš vždy přemýšlet nad tím, co děláš a jaký bude tvůj hlavní cíl. Ne vždy to tak i dopadne, ale aspoň se od něčeho odrazíš.

Jinak frameworků se neboj. Jak říkáš - pomáhá to nějakým způsobem zjednocovat kód. Hlavně backend je hodně všude podobný. Samozřejmě každá firma si pak následně předělává různé části kódu pro své účely, ale základy se odvíjí od toho samotného.

Když si projdeš zdejší tutoriály, tak budeš mít dobré základy. Ačkoliv musím přiznat, že co se webových technologií týče, tak určitě u těch lekcí pročítej vždy i komentáře. Spousta programátorů tam píše dobré postřehy. Sežere ti to čas, ale každá minuta, kterou investuješ do svého rozvoje ti přinese nakonec víc, než si myslíš;)
A neboj se experimentovat a hrát si s tím. Hlavně se nelekej, že je něco těžkého. Když je něco těžké - tak to musíš pochopit a strávit nad tím víc času, ale vše je pochopitelné.

Tak hodně štěstí a kdybys měl někdy nějaký problém, tak mi klidně i napiš PMko. Když budu vědět, můžeme na problém juknout.

Odpovědět
19.2.2023 22:21
Existují dva způsoby, jak vyřešit problém. Za prvé vyhoďte počítač z okna. Za druhé vyhoďte okna z počítače.
Avatar
Natálie Růžičková
Tvůrce
Avatar
Natálie Růžičková:27.10.2023 15:10

Ahoj, děkujeme všem za podnětné reakce na článek, pracujeme na aktualizaci, tak se na vše důkladně podíváme.

 
Odpovědět
27.10.2023 15:10
Avatar
Jan Gritzbach
Člen
Avatar
Jan Gritzbach:2.1.2024 21:02

Citace z článku:

Vytvoříme instanci objektu Date z našeho data a použijeme její metodu toLocaleString()

Zřejmě je zde překlep a má být uvedeno toLocaleDateS­tring().

Odpovědět
2.1.2024 21:02
"Stay curious, learn every day!"
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 10 zpráv z 34.