ReactJS

  • Keskustelun aloittaja Keskustelun aloittaja aittis
  • Aloitettu Aloitettu
React kysymystä. Elikkäs on vaikeuksia saada renderöityä päivämäärä näkymään Reactilla oikein. Serveri toimittaa kellonajan muodossa vaikkapa date=1583962799732. React-kompnentin rungossa teen operaation {Date(date).toString()}, joka mielestäni toimi javascriptissä. Ongelmaksi muodostuu se, että kellonaika jatkaa päivittymistä itsestään (ainakin aina kun jotakin rendataan uusiksi) ja kello tuntuu elävän nykyhetkeä. Miten tämän saisi toimimaan niinkuin pitää?
 
kasa sanoi:
React kysymystä. Elikkäs on vaikeuksia saada renderöityä päivämäärä näkymään Reactilla oikein. Serveri toimittaa kellonajan muodossa vaikkapa date=1583962799732. React-kompnentin rungossa teen operaation {Date(date).toString()}, joka mielestäni toimi javascriptissä. Ongelmaksi muodostuu se, että kellonaika jatkaa päivittymistä itsestään (ainakin aina kun jotakin rendataan uusiksi) ja kello tuntuu elävän nykyhetkeä. Miten tämän saisi toimimaan niinkuin pitää?
Napsauta laajentaaksesi...
No vaikuttaa kyllä aika kummalliselta. Laitappas vähän koodia jakoon.
 
Itselläni tämä koodi rendautuu väärin kun kirjoitan tekstikenttään:

const App = () => {
const date = 1583962799732
const [txt, setTxt] = useState('')

const on_change = (event) => {
setTxt(event.target.value)
}

return (
<div>
{Date(date).toString()}
<textarea value={txt} onChange={on_change}/>
</div>)
}
 
Date() = funktio joka palauttaa nykyhetken ja sitä ei voi alustaa omalla arvolla
New Date() = palauttaa uuden Date instanssin ja voit myös alusta sen antamalla päiväyksen parametrina.

Ei vaisinaisesti liity reactiin millään lailla. :geek:
 
visionääri sanoi:
Onko React osaajalle minkälainen kynnys alkaa vääntämään Vue.js:llä?
Lukemani perusteella Vue näyttää vieläkin lupaavammalta kuin React, jonka ainoana heikkouteuna näen osaajien puutteen vrt React devaajiin.
Napsauta laajentaaksesi...
Ainakin itselle oli helppo siirtyä reactista vueen. Luin läpi vuen dokumentaation, ja sen jälkeen suoraan asiakasprojektiin. Helposti onnistu, tässä linkki Introduction — Vue.js
 
Miten React-sivu olis kätevintä linkittää valmiiseen sivustoon? Eli nyt sivustoa tehtäisiin uusiksi reactilla, mutta yksi vanha sivu säilyisi "osasivuna". Elikkä jonkinlainen linkki react-routerista vanhan sivun index.html:ään vai voiko renderöinnin tehdä jotenkin komponentissa?
 
kasa sanoi:
Miten React-sivu olis kätevintä linkittää valmiiseen sivustoon? Eli nyt sivustoa tehtäisiin uusiksi reactilla, mutta yksi vanha sivu säilyisi "osasivuna". Elikkä jonkinlainen linkki react-routerista vanhan sivun index.html:ään vai voiko renderöinnin tehdä jotenkin komponentissa?
Napsauta laajentaaksesi...
Mitä sivu sisältää? Mikä sen funktio on?

Vähän noista riippuen, mutta renderin sisäänhän voi laittaa mitä vaan html:ää.
 
Macu sanoi:
Mitä sivu sisältää? Mikä sen funktio on?

Vähän noista riippuen, mutta renderin sisäänhän voi laittaa mitä vaan html:ää.
Napsauta laajentaaksesi...

Juu elikkä sivu on sellainen varsin massiivinen käyttöliittymäsivusto, jonka kääntämiseen kokonaan reactille menee tovi jos toinenkin. Kaveri on tehnyt sen ja hän ei osaa reactia. Hankaluuksia aiheuttaa, että paljon dom-elementtejä luodaan suoraan javascriptillä ja seassa on ejs:ää, joten suoranaista html:ää on vähän hankala hahmottaa. Homma ratkaistiin toistaiseksi sillä, että serveri ohjaa tietyt urlit ei-react sivulle ja tietyt sitten react-sivulle.
 
Lisää kysymyksiä. Onko hyvä idea käyttää hookkeja listalta rendattavissa komponenteissa? Eli tyyliin lista.map((i)=><Komponentti>i</Komponentti>) ja sitten Komponentin sisällä olisi vaikka useState-hookissa tavaraa. Ongelmaksi näyttää muodostuvan se, että react jostain syystä renderöi listaan lisäyksen jälkeen listan perään uuden divin (esimerkiksi). Tällöin listan alkuun tai keskelle lisätyt osat saattavat mennä epäsynkkaan, koska hookit osoittavat vanhoihin alkioihin ja niiden sisältö muuttuu shiftauksen vuoksi.. Toistaiseksi olen joutunut siirtämään hookit listan sisältävään komponenttiin, jota ei renderöidä kuin toivottavasti sen kerran kun lista ekaa kertaa ilmestyy. Onko mitään mahdollisuutta, että react laittaisi uuden DOM-elementin listalla muualle kuin loppuun vai enkö tajua jotain?

Oon yrittänyt etsiä tarkkaa speksiä tuosta että miten virtual DOMin vertausoperaatiot ja oikean DOMin päivitys menevät, mutta toistaiseksi laihoin tuloksin.
 
@kasa Sulla ei taida olla listan elementeillä uniikkia "key"-propsia? Kurkkaapa selaimen konsoliin, siellä on ehkä herja. Jokaisella listan alkiolla on oltava siis uniikki ID.

Sinänsä hookeja voi käyttää myös listan alkioilla. Mutta joskus voi olla järkevää tehdä niistä komponentteja, jotka vain antavat datalle esitysmuodon. Ja toimittaa data propseina.
 
Paapaa sanoi:
@kasa Sulla ei taida olla listan elementeillä uniikkia "key"-propsia? Kurkkaapa selaimen konsoliin, siellä on ehkä herja. Jokaisella listan alkiolla on oltava siis uniikki ID.

Sinänsä hookeja voi käyttää myös listan alkioilla. Mutta joskus voi olla järkevää tehdä niistä komponentteja, jotka vain antavat datalle esitysmuodon. Ja toimittaa data propseina.
Napsauta laajentaaksesi...

Okei, tämä olikin se errori. Kiitos! Key oli, mutta se oli vain indeksi, eikä linkittynyt elementtiin mitenkään. Laitoin nyt uniikin id:n avaimeksi.
 
Noniin, laitetaan nyt tähän "kilpailijan" ketjuun, kun ei omaakaan löytynyt. Eli kyseessä Vue. Ajaako jo Reactista ohi? Näyttää työpaikkailmoituksissa esiintyvän enemmän ja enemmän. Itse aloittelin tänään Vuen opiskelua ja täytyy sanoa, että siinä missä Reactiin pääsi suht nopeasti sisään kunhan sai webpäkit tulille, Vue vaikuttaa ihan karmealta sekamelskalta.. En voi ymmärtää, miten joku pitää tätä Reactia helpompana.
 
En ole Vue'ta käyttänyt, mutta ei siinä mitään ihan hirveää sinänsä ole. Tekee paljon paremmin sen mitä alkuperäinen Angular aikoinaan yritti. Lähiaikojen esimerkit Vue-projekteista tosin ei ole kovin hehkeitä, esimerkiksi Ilmatieteen laitoksen sivujen uudistus on Vue-projekti (Nuxt) ja voi hyvänen aika sentäs miten monta eri rikosta siinä on tehty! Yhtä huonoa jälkeä tosin saisi Reactillakin, että enemmän kyse on kokemattomista webbidevaajista ison uudistusprojektin äärellä. Kokemus on kuitenkin luokkaa, että sivu kun lataa, niin palapelitorni kokoaa itsensä silmien edessä. Mikään ei säilytä korkeuttaan, mitään tärkeää ei tarjoilla oikeasti valmiina palvelimelta vaan haetaan vasta selaimen päässä erillisillä API-kutsuilla, ja ne vanhat osoitteet joille ei kirjoitettu tukea eivät osaa ohjata lähimpään vastaavaan näkymään vaan heittävät 500-tason virhettä.

Reactista oma mielipide nyt kuuden vuoden kokemuksen jäljiltä on se, että sitä käytetään aivan liian usein aivan liian väärällä tavalla. Suurimman osan ei pitäisi tehdä palvelintarjoiltuja CSS-in-JS moniskriptisplitattuja SPA-sivuja Reactilla, mutta niin vaan se näyttää olevan voittava trendi. React on parhaimmillaan rikkaissa UI-kokemuksissa, mutta pahimmillaan sillä voi tehdä todella kovaa hallaa käyttökokemukseen huomaamatta. Ja sitten ongelmien korjaaminen vaatii hirveästi devausaikaa ja huomioimista. Perinteinen JS:llä kevyesti rikastettu HTML+CSS -saitti on lopulta hirveän helppo optimoida sikamaisen nopeaksi verrattuna hirveän kompleksiseen SPA code splitting -hirviöön. Toki jälkimmäistä on hauskempaa ja haastavampaa devata... ja on sillä joitakin devaajakokemukseen liittyviä etuja, kun "sama JS palvelin- ja selainkoodin rendaamiseen".

Oikeasti useimmiten voisi vaan pilkkoa sivuille muutamaan paikkaan React-miniappeja ja lisätä tarvitun skriptin vaikka manuaalisesti per sivu, eikä pistää koko helahoitoa yhden JS-monoliitin varaan.
 
Merri sanoi:
Reactista oma mielipide nyt kuuden vuoden kokemuksen jäljiltä on se, että sitä käytetään aivan liian usein aivan liian väärällä tavalla. Suurimman osan ei pitäisi tehdä palvelintarjoiltuja CSS-in-JS moniskriptisplitattuja SPA-sivuja Reactilla, mutta niin vaan se näyttää olevan voittava trendi. React on parhaimmillaan rikkaissa UI-kokemuksissa, mutta pahimmillaan sillä voi tehdä todella kovaa hallaa käyttökokemukseen huomaamatta. Ja sitten ongelmien korjaaminen vaatii hirveästi devausaikaa ja huomioimista. Perinteinen JS:llä kevyesti rikastettu HTML+CSS -saitti on lopulta hirveän helppo optimoida sikamaisen nopeaksi verrattuna hirveän kompleksiseen SPA code splitting -hirviöön. Toki jälkimmäistä on hauskempaa ja haastavampaa devata... ja on sillä joitakin devaajakokemukseen liittyviä etuja, kun "sama JS palvelin- ja selainkoodin rendaamiseen".

Oikeasti useimmiten voisi vaan pilkkoa sivuille muutamaan paikkaan React-miniappeja ja lisätä tarvitun skriptin vaikka manuaalisesti per sivu, eikä pistää koko helahoitoa yhden JS-monoliitin varaan.
Napsauta laajentaaksesi...

Täsmälleen samaa mieltä ja henkilökohtaisesti SPA paradigma on alkanut jossain määrin syömään miestä, vaikka Reactin koodaus itsessään onkin itselleni erittäin mielekästä. SPA soveltuu hyvin tapauksiin jossa siitä UI:ssa tapahtuvasta rendaamisesta saavutetaan hyötyjä parantuneena käyttökokemuksena, mutta ei tuo vaan ole se keskeisin tavoite ihan kaikkialla (nimim. enterprise softaa Reactilla tehneenä). React itsessään on aika kevyt paketti, joten juuri tuollaisten näkymäkohtaisiin React-minisovellusten käyttö niissä tapauksissa missä sille on hyvät perusteet kuulostaisi omaan korvaan aika optimilta ratkaisulta.
 
Vinkkejä kaivataan miten React/Express stack deployataan cloud nativena.

Kun deployaatte React-sovelluksen ja teillä on bäkkärissä node.js/express API niin tarjoatteko Reactin tuon expressin kautta vai onko API ja React kaksi eri sovellusta? Jos koko full stack deployataan vaikka Azuren pilveen App Serviceen niin miten toi URL/route hoidetaan Ractin päässä kun backend tulee "eri" servicestä? Pitääkö Reactille antaa joku baseUrl parametri joka viittaa API:n osoitteeseen jotta itse aplikaatiossa voidaan käyttää lyhyitä urleja kuten esim. /tasks eikä esim. https://myapi.azure.com/api/tasks
 
©©© sanoi:
Kun deployaatte React-sovelluksen ja teillä on bäkkärissä node.js/express API niin tarjoatteko Reactin tuon expressin kautta vai onko API ja React kaksi eri sovellusta?
Napsauta laajentaaksesi...

Aika yleistä on laittaa se frontti ihan erikseen S3:een (ja vastaava Azuressa) vaikka CDN:n taakse (CloudFront etc.). Ja sitten se bäkkäri on missä on ja React appille tietenkin kerrotaan, mihin se lähettää API-kutsut.

React appissa voit tietenkin abstarktoida ne API-kutsut miten haluat. Sulla voi olla vaikka api client -objekti, joka sitten hoitaa kutsut ja palauttaa datan. Sen kutsuvan komponentin tms. ei tarvitse tietää URLeista tuon taivaallista. Tai jos käytät Reduxia, niin samalla tavalla jonkun async-actionin voi laittaa käyttämään tuota API clienttiä joka sitten hoitaa sen likaisen työn.

Eli applikaatiossa kutsut vain apiClient.getNotes(). Ei tarvetta urleille.
 
Paapaa sanoi:
Aika yleistä on laittaa se frontti ihan erikseen S3:een (ja vastaava Azuressa) vaikka CDN:n taakse (CloudFront etc.). Ja sitten se bäkkäri on missä on ja React appille tietenkin kerrotaan, mihin se lähettää API-kutsut.

React appissa voit tietenkin abstarktoida ne API-kutsut miten haluat. Sulla voi olla vaikka api client -objekti, joka sitten hoitaa kutsut ja palauttaa datan. Sen kutsuvan komponentin tms. ei tarvitse tietää URLeista tuon taivaallista. Tai jos käytät Reduxia, niin samalla tavalla jonkun async-actionin voi laittaa käyttämään tuota API clienttiä joka sitten hoitaa sen likaisen työn.

Eli applikaatiossa kutsut vain apiClient.getNotes(). Ei tarvetta urleille.
Napsauta laajentaaksesi...
Missä kohtaa se koko API URL sitten työnnetään sille React applikaatiolle? Onko se esim. joku const muuttuja jossain servicessä joka hoitaa noita API-kutsuja?
 
©©© sanoi:
Missä kohtaa se koko API URL sitten työnnetään sille React applikaatiolle? Onko se esim. joku const muuttuja jossain servicessä joka hoitaa noita API-kutsuja?
Napsauta laajentaaksesi...

Esimerkiksi juuri noin. Se voi olla ihan vaan joku const apiUrl = "https://...". Tai jos sulla olisi live- ja QA-versiot samasta appiksesta, niin buildatessa se oikea API voitaisiin injektoida ympäristömuuttujien kautta, jotta eri versiot sitten käyttäisivät eri API-ympäristöä myös.
 
©©© sanoi:
Vinkkejä kaivataan miten React/Express stack deployataan cloud nativena.
Napsauta laajentaaksesi...

Ja kun frontti ja bäkki ovat omissa repoissaan, on ehkä helpompi ja nopeampi esim. julkaista bugfixi vain fronttiin ilman että bäkkärin toiminta keskeytyy - ja toisinpäin. Ne voivat elää koko ajan omaa elämäänsä (toki jos API muuttuu niin se vaikuttaa fronttiin). Siksi niiden pitäminen visusti erillään on se yleisin tapa toimia.
 
Kellään tehtynä full stack openin tehtävää 2.13? Sain sen ratkaistua mutta vähän jäi mietityttämään olisiko tätä voinut ratkaista jollakin toisellakin tavalla. Netistä löytyy joitakin vastauksia mutta ne on kai tehty vanhemmalla reactin versiolla niin ainakin nopeasti vilaistuna vaikutti vähän erilaisella kun ei noita hookeja vielä useimmissa ole.
 
Moilaps sanoi:
Tuolla alhaalla toi 2.13
Napsauta laajentaaksesi...

Jos toi yhden maan näkymä olisi siis oma näkymä, niin sitten se löytyisi omasta URLista reitittimen takaa. Tällöin ne show-painikkeet olisivat linkkejä maakohtaisille sivuille. Ja kun saavut yksittäisen maan sivulle, niin ehkä URLista voisi lukea sen maatunnuksen ja sillä voi sitten useEffect():llä lukea API:sta datan tämän maan osalta.

Jos taas se yhden maan näkymä avautuu siihen listaan muiden sekaan, niin sitten teet Country-komponentin (joita näytetään listassa), jolla on useState:n avulla IsHidden-tila, jota voi napilla muuttaa. Jos isHidden on totta, niin data on piilotettu ja näkyy vain se show-nappi. Jos taas se on false, niin data näytetään listassa ja napissa voisi lukea hide.
 
Paapaa sanoi:
Jos toi yhden maan näkymä olisi siis oma näkymä, niin sitten se löytyisi omasta URLista reitittimen takaa. Tällöin ne show-painikkeet olisivat linkkejä maakohtaisille sivuille. Ja kun saavut yksittäisen maan sivulle, niin ehkä URLista voisi lukea sen maatunnuksen ja sillä voi sitten useEffect():llä lukea API:sta datan tämän maan osalta.

Jos taas se yhden maan näkymä avautuu siihen listaan muiden sekaan, niin sitten teet Country-komponentin (joita näytetään listassa), jolla on useState:n avulla IsHidden-tila, jota voi napilla muuttaa. Jos isHidden on totta, niin data on piilotettu ja näkyy vain se show-nappi. Jos taas se on false, niin data näytetään listassa ja napissa voisi lukea hide.
Napsauta laajentaaksesi...

Latasin koko .json:in kerralla tolla useEffecttilla. Toi muiden sekaan laittaminen tuntui vähän vaikealta silloin kuin tein ton niin käytin vain uudestaan samaa koodia mitä silloin kun tulee "täysi osuma". Vaikeuksia omalla kohdalla oli se että unohdin nuo "rules of hook"s niin sitä piti vähän googletella että missä mättää. Tossa vielä koodi tähän tehtävään. fullstackopen 2.13 - Pastebin.com
 
Nostetaas tää ketju ylös!

React v19 julkaistaan kohta. New Features in React 19 – Updates with Code Examples

Onko täällä ketään joka tällä hetkellä opettelee käyttöliittymien luontia Reactilla? Mitä sivustoja, kursseja tai muita lähteitä olet hyödyntänyt oppiaksesi? Esim jotain alla olevista?

Udemy
Fullstack Open
Tubettajat? Jos niin mitkä kanavat?

Mitä suosittelisit muille?
 
latez0r1 sanoi:
Perinteinen alkemia pyrki muuttamaan lyijyn kullaksi ja löytämään täydellisen tasapainon eri elementtien välillä. Modernin teknologian maailmassa tämä ajatus elää yhä – mutta nyt se ilmenee ihmisen ja teknologian sekä eri kehitystyökalujen saumattomana yhdistämisenä. Esimerkkinä tästä toimii täydellisesti Next.js ja React.js.

React.js tarjoaa komponenttipohjaisen lähestymistavan, joka tekee käyttöliittymien kehittämisestä selkeää, joustavaa ja tehokasta. Mutta kun halutaan viedä React-sovellukset seuraavalle tasolle – suorituskyvyn, hakukoneoptimoinnin (SEO) ja skaalautuvuuden osalta – astuu kuvaan Next.js.

Next.js on React-pohjainen framework, joka tuo mukanaan ominaisuuksia kuten:

Palvelinpuolen renderöinti (SSR) – Parantaa sovelluksen nopeutta ja SEO-ominaisuuksia.

Staattinen sivujen generointi (SSG) – Vähentää palvelimen kuormaa ja nopeuttaa latausaikoja.

API-reitit – Mahdollisuus rakentaa backend-toimintoja suoraan Next.js-sovelluksen sisään.

Helppo reititys – Tiedostopohjainen reititys tekee sovelluksesta selkeän ja helposti hallittavan.


Yhdessä nämä työkalut mahdollistavat modernien, dynaamisten ja suorituskykyisten verkkosovellusten kehittämisen – kuin teknologista alkemiaa, jossa yhdistetään parhaat puolet eri järjestelmistä.

Kun yhdistämme Reactin joustavuuden ja Next.js:n tarjoamat optimoidut ominaisuudet, syntyy symbioosi, joka tuo esiin molempien vahvuudet:

React toimii luovana pohjana komponenttien rakentamiseen.

Next.js optimoi ja viimeistelee kokonaisuuden, tuoden suorituskyvyn ja SEO:n osaksi sovellusta.


Tämä yhdistelmä tarjoaa kehittäjälle työkalut, joilla voi luoda verkkosovelluksia, jotka ovat sekä käyttäjäystävällisiä että teknisesti tehokkaita.

Moderni alkemia ei ole vain filosofinen käsite, vaan käytännön kehitystä, jossa eri teknologiat yhdistyvät saumattomasti. Ihmisen luovuus, kuten käyttöliittymien suunnittelu ja sovelluksen logiikka, sulautuu teknologian tarjoamiin työkaluihin, kuten Next.js:n ja Reactin optimoituihin ominaisuuksiin. Lopputuloksena on sovellus, joka toimii sujuvasti ja tehokkaasti sekä käyttäjän että kehittäjän näkökulmasta.
Napsauta laajentaaksesi...
Hieno teköälyllä tuotettu tekstirykelmä, mutta mikäs tämän tekstin tarkoituksena oli?
 
Basa se on minusta, mutta joskus 2016 sitä olisi voinut pitää ihan ok:na. Nykyään on rajapintoja, kuten Svelte, jotka tekee saman lyhyemmin. Lisäksi Mozilla Web API on kevyempi.
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
261 793
Viestejä
4 547 336
Jäsenet
74 849
Uusin jäsen
ookooo

Hinta.fi

Back
Ylös Bottom