Kompromisszumkód kibaszott
A mi feladatunk az úgynevezett kompromisszumok döntése. Kérdés a megoldás pozitív és negatív pontjainak meghatározása és az egyensúly megbecsülése. Ilyen módon választjuk meg azt a megoldást, amely a legjobban megfelel (legalábbis a szemünkben) az igényeinknek.
Azonban iparunkban létezik dogma rendszer. Már nem arra törekszünk, hogy a kompromisszumokat a perspektívába helyezzük és összehasonlítsuk, hanem a "gondolkodási iskolák" ellen harcolunk, amelyek mindegyikének axiómái vannak (ezt az elvet nem mutatták be, hanem az érvelés alapjául használják).
A front-end-ben alkalmazott modern technológiákról folytatott újabb vita után, amelyet ezen axiómák néhány védője cáfolt, megpróbálom ésszerűsíteni a megközelítésünket és megmagyarázni annak kompromisszumait.
Az ötlet itt az, hogy tegyük megért miért alkalmazzuk ezeket a megközelítéseket és technológiákat, milyen összefüggésben, és nem rájuk kényszeríteni őket. Kis szerencsével ez a cikk néhány beszédet megváltoztat "nimportawak (sic)" -ről "nem az én típusú projektemre".
Kezdetben a webet úgy tervezték egy sor dokumentum: minden oldal egy. Minden navigációnál kiváltjuk egy új életciklus oldal: befejezzük az aktuális oldalt, inicializáljuk a következőt.
Ez a modell nagyon egyszerű, és nagyon helyes tapasztalatokat tesz lehetővé többnyire statikus oldalak esetében.
Van egy oldalunk HTML-ben, egy stíluslap CSS-ben. És ez az. Megtudjuk, hogy jól el kell különítenünk őket (az aggodalmak elkülönítésének elve nevében, ha van valami, ami rosszul esik, akkor leépített tapasztalatot kell javasolni.
Az évek során a felhasználók igényei egyre magasabbak: oldalakkal kellett válaszolni rájuk interaktívabb és technikái részleges újratöltések oldal (egy oldal életciklusa meglehetősen drága). Szóval elkezdtünk hozzáadni egy korlátozott intelligenciát egy kis JS-sel, különösen néhány interaktív téglával, az oldal végét betölteni az AJAX-szal.
Ezek a technikák drasztikusan lehetővé tették javítsa a böngészési élményt felhasználók: kevesebb adatunk van betöltésre, gyorsabban jelenítjük meg azt, amit az emberek szeretnének látni (még mindig kissé bosszantó lenne új oldalt betölteni, amint ráközelít a Google Maps-re). És itt van az első kompromisszum:
- több adatot töltünk be a kezdeti oldalbetöltéskor (JS),
- De ez lehetővé teszi számunkra, hogy kevesebb adatot töltsünk be az egymást követő terhelésekről.
Ezután jön a mobil platformok elterjedése. A felhasználók eléréséhez a web már nem az A platform, de A platform többek között. Ezután stratégiai érdekessé válik a vállalatok számára a közös bázisok kialakításának megkezdése a következő formában:API-k, amelyekre különböző ügyfelek, különböző platformokon fognak feliratkozni.
Abban az időben a front-end soha nem látott változást tapasztalt: elkezdtünk alkotni valódi alkalmazások, már nem olyan dokumentumok, amelyekbe egyes jellemzőket véletlenszerűen oltottak volna. Ezután fejlettebb eszközöket szerzünk be, a szoftverek más területein (például az MVC) már bevált minták alapján. Elmúltak azok a JS fájlok, amelyek inicializálják a 3 jQuery plugint körhinta készítéséhez.
Ezután a következőkben kezdünk el gondolkodni nézetek. Némi függetlenséget is elnyerünk a háttérképtől, az interfészünket közvetlenül a JS-től generálhatjuk.
Most már nem feltétlenül kell megtanulnunk a háttér-verem működését, szervezését, sablonnyelvét: a veremeink mestereivé válunk.
Olyan új kérdéseket ölelünk fel, mint az útválasztás, az adatgyűjtés és az intelligens kliens gyorsítótárak létrehozása. Ekkor megjelennek ezekre megoldásokat kínáló keretek (Angular, Ember és Backbone, hogy csak néhányat említsünk).
Ezután a React egyedi megközelítéssel érkezik versenytársaival: az alkatrészekkel. Az alkalmazás minden újrafelhasználható blokkjához létrehozunk egyet.
Az összetevő egy fekete doboz, amely paramétereket (kellékeket) vesz fel, helyi állapotú lehet, és amely az interfészt bármikor leírja.
A React a JSX-szel, a JS kiterjesztésével is érkezik, amely lehetővé teszi az interfész HTML-re (XML) hasonlító formában történő leírását, de korlátozásai nélkül (például az attribútumok sorosítási igénye nélkül). A JSX megőrzi a HTML ismertségét (és egy ilyen szintaxis relevanciáját az elemek fájának ábrázolására), de egyre növekvő frusztráltságra "logika nélküli" sablonokkal válaszol, amelyek a segédek létrehozását és az adatok upstream átalakítását kényszerítették.