codez

Pie PureRenderMixin-a izmantošanas react salīdzina visas props un state vērtības: https://github.com/facebook/react/blob/5d3b12bb3bd6a092cf00ede07b8255a8399c2e58/src/addons/ReactComponentWithPureRenderMixin.js#L41-43 https://github.com/facebook/react/blob/5d3b12bb3bd6a092cf00ede07b8255a8399c2e58/src/utils/shallowEqual.js#L21-40 Problēma varētu rasties asinhronos procesos, kad tu izmaini daļu no state un tad izsauc kaut ko asinhronu, kurš balstās uz state, utml. Bet kā jau teicu vienkāršos gadījumus problēmām nevajadzētu būt. P.S. Šeit masīva elementa nomaiņas piemērs ar Immutable.js: http://jsfiddle.net/d9crpzqy/12/

Wuu, tam var izmantot React update addonu. Piemērs: http://jsfiddle.net/d9crpzqy/11/ Bet tavā gadījumā var nt = this.state.t; nesaglabā citā masīvā, nt ir tas pats state.t masīvs un būtībā notiek tas pats, kas Kasspars piemērā. Kas attiecas uz Kasspara piemēru, domāju, ka lielākajā daļā gadījumu nekam sliktam nevajadzētu notikt, taču nebūtu grūti atrasts speciālu gadījumu, kur tas var strādāt ne tā kā domāts. Pareizākais būtu lietot vai nu update addonu, vai Immutable datu struktūras, piemēram, Immutable.js

Ja izmanto React: https://github.com/eiriklv/react-masonry-mixin

Props un State izmanto jebkurā gadījumā, tikai svarīgi ir, kas tieši nāk caur šo props un state. Lai liela izmēra React aplikācija strādātu ātri, ir svarīgi, lai ne tikai pārrenderēšana būtu efektīva, bet arī kompleksākas render funkcijas izsauktos retāk. To var panākt ar PureRenderMixin, kurš tad, kad iepriekšējais props un state ir vienādi salīdzinot ar "shalow" salīdzināšanu - tātad tikai pirmajā līmenī. Ja dati, kas glabājas ir masīvi vai objekti, tad salīdzinātas tiek attiecīgi reference. Ja izmanto plain js datu struktūras, tas, lai kokveida datu struktūrā saglabātos iepriekšējās references tiem atzariem, kuri neizmainījās, var lietot React update addonu, bet tas ir diezgan ierobežots savā funkcionalitātē. Daudz plašāka bibliotēkā ir immutable.js, kuru pareizi izmantojot, var panākt to, ka pat daudz mazāk lieku render funkciju tiek izsaukts. Otra lieta ir tā, ka ir divu veidu stāvokļi, komponentes lokālie un aplikācijas globālie. Piemēram, entitījas kā users, posts, comments, utml. es glabātu globālā storē, kurai var piekļūt dažādas komponentes, bet lokālus, kas raksturo tikai konkrēto komponenti, pašā komponentē. Piemēram, ja man būtu komentāru komponente, tad komponente pati glabātu komentāru id koku: [1,2,3,[4,5,6],7,8,[9,10]], savukārt globālais store glabātu komentāru, lietotāju, u.c. nepieciešamās entitījas, jo tās: 1) var būt vajadzīgas citās komponentēs un, lai, ja kādā nomainās dati, ir tikai viens patiesības avots; 2)Tajā pašā komponentēs var būt tā, ka daudzās vietās izmanto vienu un to pašu entitīju un lai nebūtu liekas kopijas. Tālāk attiecīgi šīs globālās entitījas var būt arī kaut kas sarežģītāks par vienkāršu native js objektu vai Immutable Mapu. Piemēram, ja komentāros vajag attēlot lietotāja avataru un arhitektūra ir būvēta tā, ka no saiti uz lietotāja avataru var izrēķināt no lietotāja id, tad attiecīgi pie id piekļūs caur user.id, bet pie avatara saites caur user.avatarUrl(). Šeit attiecīgi noder kaut kas sarežģītāks par native js datu struktūrām. P.S.: Šeit informācija par to kā Immutable uzlabo React https://facebook.github.io/react/docs/advanced-performance.html

React ir View bibliotēka un nenoliedzami pašreiz ātrdarbīgākā, pārspējot visas citas ar krietnu atrāvienu. Vue ir MVVM freimworks, kura View daļa ne tuvu nav tik ātrdarbīga kā React-am, bet efektivitāte tiek panākta ar pietiekami gudru modeļu daļu. Ja sāksi lietot Vue, tad esi sasiets ar visām tā sastāvdaļā, kamēr React gadījumā, izmanto, kuru modeļu bibliotēku gribi, vai tā būtu Backbone, Immutablejs, native js, u.c. Tāpat ar React tu vari aplikāciju būvēt MVVM, MVC, Flux un citiem paterniem vai to kombinācijām.

Nav paredzēts, ka nomainās. setState nenomaina state, bet tikai pasaka, ka vajag nomainīt. Un, ja nemaldos, reāla nomaiņa notiek saskaņoti ar renderēšanas kadriem (ne biežāk kā 60 reizes sekundē), kas ļauj veidot sarežģītas komponentes, kurās setState var tikt izsaukt ļoti daudz reižu, bet reālā komponentes stāvokļa maiņa tiek veikta tikai pa renderēšanas kadriem. Respektīvi tā ir optimizācija. Tu vari tajā handleXXXXX funkcijā uztaisīt ciklu ar 10'000 setState izsaukumiem, bet reāli state tiks nomainīt tikai vienu reizi. Tā ir optimizācija. http://facebook.github.io/react/docs/component-api.html#setstate

Beidzot sludinājums ar pienācīgiem augšējajiem atalgojuma griestiem. Bet vai nešķiet diezgan dīvaini likt sludinājumu PHP devam, bet prasībās rakstīt "you are interested in a new technologies" ;)

Nē, fiidlē ir JSXTransformer.js, kurš pārveido javascript kodu pirms palaišanas. Bet, piemēram, pie produktu izstrādes es JSXTransformeri laižu servera pusē un man uz klientu uzreiz nāk ES3 saderīgs javascripts.

Tāpēc, ka jsx ir jātrasformē un to transformējot tiek transformētas arī ES6 arrow funkcijas: https://facebook.github.io/react/docs/tooling-integration.html#jsx Arrow funkciju piemērs jsfiddlē taču tev iet?

bind(this) nozīmē, ka funkcija tiks izsaukta ar contextu this. Kā var redzēt piemērā, ja netiek piebindots this (3 un 4 gadījumā), tad anonīmās funkcijas konteksts ir window un nav pieejama App react klase un nevar izsaukt funkciju add. Ar arrow funkciju (5 un 6) pieraksts ir krietni īsāks http://jsfiddle.net/d9crpzqy/10/ var App = React.createClass({ getInitialState(){ return { x:5 } }, add(d){ this.setState({x:this.state.x+d}); }, render(){ return <div> <div>X = {this.state.x}</div> <button onClick={function(){this.add(1)}.bind(this)}>Add 1</button> <button onClick={function(){this.add(2)}.bind(this)}>Add 2</button> <button onClick={function(){this.add(3)}}>Add 3</button> <button onClick={function(){this.add(4)}}>Add 4</button> <button onClick={()=>this.add(5)}>Add 5</button> <button onClick={()=>this.add(6)}>Add 6</button> </div> } }); React.render(<App />, document.getElementById('app'));

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions Tā ir anonīma funkcija ar piebindotu this. ES6 standarts. react jsx transformeris to pārveido ES3 atbilstošā funkcijā, lai strādātu uz pārlūkiem, kuri vēl neatbalsta šo ES6 standarta daļu.

Vienkārša situācija, piemēram, ar todo sarakstu. Ar jquery tev būs jāraksta sekojošas funkcijas, kas maina izskatu: - renderēt visu listu - izdzēst elementu - pievienot elementu - atzīmēt kā izpildītu - utt. Ar react tu raksti, tikai: - renderēt visu listu

Es pieturos pie principa, ka uzreiz ir jāraksta kvalitatīvs kods, nevis uzrakstīt pāris vai vēl trakāk ļoti, ļoti daudz testus un tad mainīt kodu, līdz viņš iziet visus testus. Tā kā nerakstu React komponenšu bibliotēkas un manas komponentes lielākoties ir specifiskas attiecībā pret projektu, tad vairāk visu testēšanu balstu uz funkcionāliem testiem - Scalatest ar Selenium. Taču, ja ir vajadzība pēc tīras React komponenšu testēšanas, tad izmantoju Mocha un React testa addonu, aptuveni šādi: http://jsfiddle.net/d9crpzqy/9/ Saprotams, ka manā gadījumā (Scala, sbt) es priekš testu laišanas izmantoju sbt un attiecīgos pluginus.

Aptuveni kā Kaspars rakstīja: http://jsfiddle.net/d9crpzqy/7/

Ja tev der pat caur IP adresei, tad kāda vaina kūkijiem?

Augšuplādējot bildi, saglabā orģinālu kā bildes/12/34/56/orig.jpg, tālāk, kad pieprasa bildi 123456, pārbaudi, vai eksistē bildes/12/34/56/orig_wm.jpg, ne neeksistē, paņem oriģinālu, uzliec watermarku un saglabā kā bildes/12/34/56/orig_wm.jpg, to pašu vari darīt, ja gribi dažādus izmērus, vari pieprasot norādīt, piemēram, platumu un augstumu un tad skatīties, vai eksistē bildes kešotā versija, piemēram, bildes/12/34/56/w_64_h_64.jpg P.S. Vari paskatīties, vai jau nav gatavs kāds labs softs, kas to dara un uz kura augšuplādējot bildi, tas māk servēt bildes dāžādos izmēros ar ūdenszīmēm, utml. Uz ātro atradu šādus: https://github.com/pierrre/imageserver (Go) https://github.com/agschwender/pilbox (Python) https://github.com/thoas/picfit (Go) PHP libs: https://github.com/CodeSleeve/stapler P.P.S: Un galu galā, ja apjoms ir mazs, var vispār par to neuztraukties un izmantot gatavus servisus, kas piedāvā iesākumu bez maksas, piemēram Cloudinary: http://cloudinary.com/pricing http://cloudinary.com/documentation/php_integration

Vari mēģināt tā - kad pieprasa bildi, paskaties, vai tāda bilde ar ūdenszīmi jau ir, ja nav, tad uzliec oriģinālam un nosūti to bildi, ja ir, tad ņem jau uzģenerēto. Tādā gadījumā, ja ūdenszīme mainīsies, tad pietiks tikai izdzēst kešotās versijas, vai nomainīt kešoto versiju ceļu un pārējais ģenerēsies automātiski, kad bildi pirmo reizi pieprasīs.

Atkarīgs, vai var būt situācija, kad ūdenszīme nomainās uz citu.

Katra komponente pati maina savus "state". Bet, ja gribi padot kādu ziņu, tad ar props padod callback eventu.

React, ja tā var teikt ir vēl ļoti jauns un vēl nav visām situācijām atlasījušies labākie risinājumu paterni. Ja komponente ir pilnīgi neatkarīga, es arī lieku ajax request-us pašā komponentē. Ja tas ir kaut kas globālākās, tad kāda moduļa actionā, kurš ir stream-s (piem. Bacon.Bus), kurš pieslēgts pie cita stream-a, kas ir store. Respektīvi manā frp pielietotajā paternā store no action-iem ne ar ko neatšķiras, tie abi ir plūsmas. Šeit primitīvs piemērs ar Baconjs plūsmām un globāliem actioniem un storēm: http://jsfiddle.net/d9crpzqy/1/ P.S. Modelēt stores kā plūsmas ir forši, tas ļauj ar tām veidot visdažādākās transformācijas - ekstraktēt datus, filtrēt, pārveidot, utt. Šeit iepriekšējais piemērs ar papildinājumu, kurā ir otra store, kas atkarīga no pirmās caur filter un map funkciju. http://jsfiddle.net/d9crpzqy/2/ Protams reālā izstrādē plūsmas pie react komponentes state tiek pieslēgtas ar vienu mixin rindiņu, nevis manuāli. Facebook taisās nāk klajā ar savu Relay un GraphQL, kas ļaus vispār iztikt ar vienu centrālu stori un vienu ajax requesta endpointu: https://facebook.github.io/react/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html

React pamatā - tas ir standarts, kurš tik drīz nepazudīs, jo visas iepriekšējās UI veidošanas metodes padara nenozīmīgas. Aplikāciju var organizēt dažādos veidos, populārākais ir ar Flux paternu, piemēram, Reflux ar, piemēram, react-router. Es izmatoju kaut ko līdzīgu refluxam, tikai visu informācijas plūsmu organizēju ar FRP veidā ar plūsmām. Es izmantoju savu plūsmu implementāciju, bet var izmantot kādu gatavu, piem., Bacon.js, (piemērs) Pateicoties React addon-am update datu modelim ļoti labi der plain javascript datu struktūras. Ja nepatīk vai neapmierina React update funkcionalitāte, var izmantot Immutable.js vai Cortext

Tāpēc jau TLM arī meklē, ka neviens pie viņiem par tādu atalgojumu neiet. Un jquery, mysql, analītiska domāšana un atbildības sajūta? Tas ir tik 2008! Sludinājums ar 20 rindiņām nekā. To sludinājumu pat lasīt nav vērts, kur nu vēl atsaukties. Mikrouzņēmumiem jau nu vajadzētu pacensties ar sludinājumiem.

Nezinu, jāpaskatās Lursoftā.

Tas atkarīgs kāds uzņēmums, ja viņi ir mikrouzņēmums, tad vairāk par 720 EUR uz rokas nebūs.

Atalgojums kā vienmēr 500 EUR/mēnesī.