JS a funkcionalne programovanie
Tento dotaz som polozil aj na inom fore (forum.zive.cz) verejne sa k tomu priznavam nekamenujte ma za to... lebo vsimol som si ze tam chodi malo prispievatelov (1 prispevok za mesiac) tak som tu otazku polozil aj tu:
Dajme tomu ze kodim reactovu komponentu a mam tam localny state. V lokalnom state je ulozeny plain object.
state = {
nejakyPlainObject: { a: 1, b: 2, c: 3 },
nejakaInaPremnna: "Nasa krasna hodnota"
}
a teraz v tom plain objekte chcem zmenit polozku b na 4 ako je lepsie ju zmenit? Toto je reactovy funkcionalny pristup na to aby som zmenil 1 hodnotu musim okopirovat vsetky predchadzajuce hodnoty:
const { nejakyPlainObject } = this.state;
this.setState({ nejakyPlainObject: { ...nejakyPlainObject, b: 4 } });a potom tu mame klasicky imperativny pristup:
const { nejakyPlainObject } = this.state;
nejakyPlainObject.b = 4;
this.setState({ nejakyPlainObject });Ten druhy mi smrdi lebo sa nim porusuju zasady funkcionalneho programovania (premenna vo funkcionalnom programovani nemoze menit hodnotu ked chcem prmennu s inou hodnotou mal by som vytvorit novu premennu). Ten prvy mi zase smrdi lebo je neefektivny.
Kladiem si teda otazku co je lepsie pouzivat? Ten druhy sposob je rychlejsi. Ten prvy zase cistejsi. Ale predstavte si ze ten plainObject nema 3 ale 5000 poloziek (trebars je v nom velka excelovska tabulka skonvertovana na JSON). Co by ste uprednostnili vy?
A máš reálný problem s výkonem, že to řešíš? Předčasná optimalizace je zlo.
Oba přístupy mají své pro i proti, nedá se jednoznačně určit, co je lepší a co horší.
>> Předčasná optimalizace je zlo.
prečo myslíš?
Kromě argumentace autoritou, vlastní zkušeností a zdravým selkým rozumem?
V kostce - nejdřív bys měl napsat unit testy, abys byl schopný rozhodnout, zda program (nebo ta část, kterou zrovna píšeš), dělá to, co dělat má. Program bys měl psát tak, aby byl přehledný, snadno pochopitelný a pracoval správně. Ono i to je dost práce a často zjistíš, že zadání nebylo zcela dokonalé a je potřeba přidat další testy a udělat další úpravy, aby to fungovalo a dělalo co má.
V této fázi má cenu optimalizovat pouze pokud narazíš na omezení pamětí, nebo program běží opravdu naprosto neúnosně dlouho z hlediska ladění (nikoli budoucího užití) a průběžně testovat, zda sis tam nezanes nějaké chyby.
Teprve když ti všechny testy prochází a zároveň vidíš, že program dělá to, co dělat má (a nedělá to co dělat nemá), tak má cenu se začít zabývat optimalizacema, aby to co dělat má dělal rychleji, s menšími nároky na paměť, refaktorizovat ho a tak.
Protože optimalizace stojí poměrně dost času, práce, znepřehledňuje ti program a odvádí od konečného cíle. Pokud s nima začneš příliš brzo, tak se ti snadno stane, že program nikdy nedokončíš, protože budeš pořád jen přepisovat další a další kusy kódu, dokud ti nedojde čas a motivace. Zároveň se do toho snadno zamotáš a ztratíš přehled o tom, co všechno to má dělat a co a jak to přesně dělá. Nemluvě o tom, že pracně optimalizovaná část se může nakonec ukázat být zbytečná a z programu ji celou vypustíš (takže všechna ta práce přijde nazmar), nebo hůř nevypustíš, když už sis s ní dal tolik práce a pak budeš všelijak kroutit ostatní části, abys ji nemusel smazat a dostaneš o mnoho horší výsledek.
Samozřejmě se taky může stát, že zoptimalizuješ kus programu, kde výpočet stráví jen nepatrný zlomek času a zkomplikuješ si tím následné odstranění skutečného úzkého hrdla (ať už proto, že nezbude čas a síly před dokončením programu, nebo že věci zašmodrcháš tak, že bude pekelně těžké s tím cokoli dělat).
Další věc je, že když napíšeš program, co se spouští občas a běží sekundu, tak je zbytečné s jeho psaním trávit desetkrát víc času, abys někde ušetřil pár milisekund.
A pokud ten program běží neúnosně dlouho, je možné, že jsi někde zvolil nevhodný algoritmus a je potřeba zvolit jiný přístup. (Takže třeba nakonec pracně optimalizovaná část vypadne.) Nebo se ukáže, že program z principu věci stráví v jednom malém kousku 99.99% času a tak je vhodné optimalizovat tento kus a nikolli všechno/cokoli okolo.
Takže je lepší to nejdřív napsat čistě, pak se podívat, zda to nebrzdí špatný přístup či algoritmus a pak teprve optimalizovat jednotlivé části, počínaje těmi, které žerou nejvíc zdrojů.
(A samozřejmě každý krok prohnat těmi unit testy, abys viděl, zda to pořád ještě funguje a nezanesl sis tam nějakou chybu jako vedleší efekt optimalizací. Eventuálně naopak pokud testy padají a výsledek je přitom správný, zda není chyba v testech.)
Taky se může ukázat, že použití pekelně účinného algoritmu na třídění velkých polí to vlastně brdí, pokud je ve výsledku použit na něco, co nikdy nebude mít víc než pár položek a zvládne to lépe algoritmus méně dokonalý, který ale má výrazně nižsí konstantní časovou složku. (Použít vyvážené binární stromy pro tisíce položek je lepší než bublesort. Pro tři položky je tomu naopak.)
Takže já bych nejdřív napsal testy, pak program a pak se podíval, co ho na reálných datech skutečně brzdí a to případně opravil.
Má ten tvůj local state tři položky? Použij čisté řešení.
Drží tvůj local state 5000 položek z Excelu překonvertovaných do JSON a ty to řešíš JS v prohlížeči u klienta? Asi máš především úplně jiný problém k řešení. (a nejspíš to povede na totální změnu nejen modelu, ale i použitých jazyků a prostředků)
(A samozřejmě - pokud ti to s kratším a stylově čistým řešením neprochází testama, tak nejdřív oprav chyby a pak teprve přemýšlej o efektivitě přiřazování jednotlivých proměnných)
Koukám, že než jsem na mobilu nadatloval odpověď, tak tu přistála ještě obsáhlejší a přesnější
Ještě jsem si vzpomněl na jeden citát:
To není z mé hlavy, je to část výroku Donalda Knutha. Což je významný matematik a profesor programování.
V podstatě jde o to, že většinou stavíš spoustu času optimalizací, která se pak ukáže jako nepotřebná. Nejdřív by sis měl zjistit, co je na tvém programu pomalé, a to teprve optimalizovat.
A velmi často zjistíš, že skutečná brzda je někde úplně jinde, v části kódu, který ti před tím přišel v pořádku.
Např. stavíš den celý den optimalizací, která tu část kódu zrychlí o 10 sekund. Vypadá to skvěle, ale pak zjistíš, že se ta část reálné spouští jednou denně. A pak tam můžeš mít část, která se dá zrychlit o tisícinu sekundy. Nic moc co? Jenže když se to spouští milionkrát denně, tak ušetříš 17 minut.
První, tím druhým si dojebeš stav aplikace, protože mutuješ objekty, žádné kraviny okolo. První přístup je správně. (ale dost nepřehledný zápis).
Sem s reaktem nechoď, tady ti dědci umí jen php a ještě si myslí že jsou mistři světa.
Edit: https://medium.freecodecamp.org/handling-state-in-react-four-immutable-approaches-to-consider-d1f5c00249d5
Edit2: DRUHÝ ZPŮSOM JE HLAVNĚ ŠPATNĚ A PORUŠUJE HLAVNÍ PRAVIDLO REAKTU.
Teď jsi nám to všem dědkům nandal! Tys měl k obědu určitě Šalamounovu stolici, viď? To se pozná...
To víš že jo
Coze ?!
Stačí poslední věta.
Proč jste tak agresivní? Protože mám pravdu? Proč teda nikdo nenapsal že to porušuje základní ideu reactu?
No já nevím, kdo tu začal s agresivitou.
A proč by to měl psát? Na idee rectu se autor neptal, ptal se, zda upřednostnit přehlednost či výkonnost a bylo mu řečeno, že přehlednost, pokud ho omezení nepřinutí k tomu druhému. A optimalizovat jen na to, co ho skutečně omezuje. Doporučuješ to snad naopak? Nebo si myslíš, že u obecných doporučení je nutno zdůrazňovat, že se často vyplatí je uvážit i v marginálních případech?
Nebo tou svou pravdou myslíš ten blábol, že zde místní umí jen jeden jediný jazyk? A jak PHP souvisí s s reactem? Že ačkoli je jedno programovací jazyk a druhé knihovna, tak jsou oba interpretované, nebo že je to jediný jiný jazyk, který znáš? Nebo proč ho vůbec zmiňuješ?
Opět jsi ukázal že o tom moc nevíš, react se ve většině případech prohání přes babel. A hlavní nadpis babelu hlásá - Babel · The compiler for next generation JavaScript. Všimni si toho slovíčka compiler ;)
A PHP se prohani prez Zend a kompiluje taky (tak si nahraď jsou interpretované výrazem mohou být interpretované, jako by na tom v této debatě záleželo). Vetsinu knihoven, ktere v nejakém jazyku napíšu také proháním přez kompilátor, aniž bych je nazýval jazykem, a když jsme u toho Bábelu, všimni si taky, že tam je slovíčko Javascript, nikoli React :) Takže jsi zatím nevysvětlil vůbec nic, jenom ještě zamlžuješ, proč do této debaty taháš PHP.
Zatím jsi nijak nezodpověděl:
- proč by měl někdo jmenovitě zmiňovat, že obecné pravdy platí kromě tisíce jiných případů i pro JS knihovnu react (když jsme u těch upozornění, všiml sis, že na domovských stránkách Reactu jej výslovně označují za JS knihovnu hned nahoře na hlavní stránce a dukumentace tím taky začíná?)
-- Když už zmiňuješ ten Bábel jako kompilátor, mohl bys také jedním dechem dodat, že překládá do JavaScriptu, který je následně interpretovaný - čili argument, že javascriptová knihovna React není iterpretovaná, protože kromě jiného jde prohnat kompilátorem, který ji přeloží na interpretovaný jazyk je takový - řekněme nedostatečně přesvědčivý až úsměvný
- proč je špatně, že tazateli bylo doporučeno programovat čistě
- proč je špatně, že mu bylo nedoporučeno používat ten druhý způsob, i kdyby s ním eventuálně pár cyklů ušetřil
- jaké je tedy tvé doporučení pro tazatele, ohledně řešení jeho problému, v čem se liší od doporučení, která zde dostal a proč je ten rozdíl podstatný
- jak jsi dospěl k bludu, že místní ovládají pouze PHP
- proč do debaty o JS to PHP vůbec taháš (protože jsi s ním přišel ty a do té doby tu o něm nebyla řeč vůbec)
- co je ta tvoje velká pravda, kterou tady nechápeme
Promiň, to co jsi napsal je moc dlouhé a nechci utrácet čás čtením nějakých blábolů, obzvlášť když hned v první větě je PHP. Hádat jsem se nepřišel. Dal jsem jen radu, tomu, kdo se ptal.
(to znamená že jsem to nečetl, ne že neodepíšu protože nemáš pravdu, pravdu mít můžeš, ale nevím co si psal, ani nemám zájem to vědět).
Rada, kterou jsi dal byla stejná jako rada těch před tebou (použít čisté řešení), ale zjevně jsi je nečetl, zato o nich víš vše od věku přez programátorské zkušenosti až po to, že ačkoli tvrdíš to samé, co oni, tak oni se mýlí a pravdu máš ty.
Ty bláboly jsou tvoje nepodložená tvrzení a
PHP jsi použil jako první ty.
Že neumíš číst vypovídá o tobě.
Ne, já jsem radil použit SPRÁVNÉ řešení a to je jen jedno z tich možností co tazatel napsal. Přečti si to ještě jednou, než napíšeš zase nějakou sračku.
ty radíš první řešení jako jediné správné,
ostatní radí první řešení, pokud není opravdu pádný důvod použít něco jiného a v takovém případě prověřit důsledky
Tedy panuje shoda na tom, že pro začátek je dobré react použít doporučeným způsobem. Neshoda nastane až v okamžiku, kdy je předchozí nepoužitelné či silně nepraktické - ty prosazuješ jedinou SPRÁVNOU cestu, my prosazujeme dosažení cíle.
REACT doslova píše: React has been designed from the start for gradual adoption, and you can use as little or as much React as you need. (zvýrazněno autory)
Licence je MIT, tedy explicitně umožňuje i MODIFIKACI reactu a to i v jeho základních vlastnostech, včetně kupříkladu úprav pro optimalizaci i za cenu mutable state, pokud to dotyčný shledá (pro sebe) vhodným.
REACT byl navržen jako počátek pro postupné úpravy a výslovně nevylučuje ani použití jiným způsobem, než je uvedeno v jeho dokumentaci. Dává tedy za pravdu dědkům, neprohlašuje se za JEDINOU SPRÁVNOU CESTU.
React je jedním (nikoli jediným) z mnoha možných prostředků, jak dosáhnout určitého cíle, použít react v nezměněné podobě podle doporučení autorů je jedním (nikoli jediným) z možných způsobů jak ho použít. Použité prostředky záleží na cíli, nikoli cíl na použití reactu obecně doporučovaným způsobem.
Pročti si dokumentaci Reactu, než napíšeš další neuváženost prozrazující tvou nezkušenost a neznalost.
jediné sračky čo tu vidím, si napsal ty.