
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?
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á...
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?
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.
jediné sračky čo tu vidím, si napsal ty.