(function(w,d,s,l,i){w[l]=w[l]|||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=? 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-5LHNRP9'); Padziļināts ieskats populārākajos React āķos - The Codest
The Codest
  • Par mums
  • Pakalpojumi
    • Programmatūras izstrāde
      • Frontend izveide
      • Backend izstrāde
    • Staff Augmentation
      • Frontend izstrādātāji
      • Backend izstrādātāji
      • Datu inženieri
      • Mākoņa inženieri
      • QA inženieri
      • Citi
    • Tā Konsultatīvais dienests
      • Audits un konsultācijas
  • Nozares
    • Fintech un banku darbība
    • E-commerce
    • Adtech
    • Healthtech
    • Ražošana
    • Loģistika
    • Automobiļu nozare
    • IOT
  • Vērtība par
    • CEO
    • CTO
    • Piegādes vadītājs
  • Mūsu komanda
  • Case Studies
  • Zināt, kā
    • Blogs
    • Tikšanās
    • Tiešsaistes semināri
    • Resursi
Karjera Sazinieties ar mums
  • Par mums
  • Pakalpojumi
    • Programmatūras izstrāde
      • Frontend izveide
      • Backend izstrāde
    • Staff Augmentation
      • Frontend izstrādātāji
      • Backend izstrādātāji
      • Datu inženieri
      • Mākoņa inženieri
      • QA inženieri
      • Citi
    • Tā Konsultatīvais dienests
      • Audits un konsultācijas
  • Vērtība par
    • CEO
    • CTO
    • Piegādes vadītājs
  • Mūsu komanda
  • Case Studies
  • Zināt, kā
    • Blogs
    • Tikšanās
    • Tiešsaistes semināri
    • Resursi
Karjera Sazinieties ar mums
Atpakaļ bultiņa ATGRIEZTIES ATPAKAĻ
2021-12-07
Programmatūras izstrāde

Padziļināts ieskats populārākajos React āķos

The Codest

Pawel Rybczynski

Software Engineer

Daudzu interviju laikā esmu novērojis, ka pat pieredzējušiem programmētājiem ir problēmas atšķirt āķus, nemaz nerunājot par to sarežģītākajām iespējām. Tāpēc šajā rakstā mēģināšu izskaidrot, kā Hooks ir jāizmanto.

Vissvarīgākās lietas, kas jums jāatceras par āķiem:

  • tos var izmantot tikai funkciju komponentos - klases komponentiem ir sava dzīves cikla implementācija;
  • tie vienmēr sākas ar izmantot;
  • Varat izmantot tik daudz āķu, cik vēlaties, taču jāatceras, ka to izmantošana ietekmē kopējo veiktspēju;
  • tie ir jāizpilda tādā pašā secībā katrā renderēšanas reizē... bet kāpēc? Aplūkosim piemēru:
importēt { useState,useEffect } no "reaģēt";

eksportēt noklusējuma funkciju FunctionComponent() {
const [value, setValue] = useState(1);
const [doubleValue, setDoubleValue] = useState(1);
if (value > 3) {
  useEffect(() => setDoubleValue(value * 2),[value]);
}

return (
  
    

{{`Vienreizējā ${vērtība} Double ${doubleValue}}}

); } ```

Sākumā jūs saņemsiet brīdinājumu no eslint:

<code>srcFunctionComponent.js
   11:5. rinda: React Hook "useEffect" tiek izsaukts nosacīti. <strong>React āķi</strong> jāizsauc tieši tādā pašā secībā katrā komponentā render .eslintreact-hooks/rules-of-hooks

Kā redzat, tas ir tikai eslint brīdinājums, lai jūs varētu to atspējot, pievienojot komandu no apakšas augšpusē. FunkcijaComponent

/* eslint-disable react-hooks/rules-of-hooks */ 

un tas darbosies, bet tikai līdz brīdim, kad mēs izpildīsim nosacījumu, kas darbojas mūsu Hook. Nākamais, ko mēs redzēsim, ir šī kļūda.

Nepamatota kļūda: Renderēts vairāk āķu nekā iepriekšējā renderēšanas reizē.
     React 5
     FunctionComponent FunctionComponent.js:11
     React 12
     Unstable_runWithPriority scheduler.development.js:468
     React 17
     js index.js:7
     js main.chunk.js:905
     Webpack 7
 react-dom.development.js:15162

Kāpēc tā notiek? React paļaujas uz to, kādā secībā tiek izsaukti Hook, jo React nezinātu, ko atdot par useEffect, jo rindā nebija šāda Hook, ko pārbaudīt.

Atcerieties, ka eslint ir spēcīgs rīks, tas palīdz mums daudz potenciālu kļūdu un kļūdu. Brīdinājumu izslēgšana ir bīstama lieta, vienmēr pārbaudiet, vai brīdinājuma ignorēšana var izraisīt lietotnes kļūmi.

useState

Jūs droši vien zināt, kā tas izskatās 😉

const [value, setValue] = useState(0);

Tātad, jums ir 4 elementi: stāvoklis (reactive vērtība), atjaunināšanas funkcija (setter), faktiskais āķis (funkcija) un izvēles sākotnējā vērtība. Kāpēc tas atgriež masīvu? Tāpēc, ka mēs to varam pārstrukturēt pēc saviem ieskatiem.

Tagad vēlos pievērsties pēdējam elementam - sākotnējai vērtībai. Ir divi veidi, kā nodot sākotnējo stāvokli:

  1. Ar cietā kodētā vērtība vai smth - kas tiks izsaukts katrā renderēt
const [value, setValue] = useState(0);
  1. Ar funkcijas versiju. Tas ir ļoti noderīgi, ja vēlamies sākotnējo stāvokli palaist tikai vienu reizi, pirmajā renderēšanas reizē. Varbūt jums ir jāveic daudz sarežģītu aprēķinu, lai saņemtu sākotnējo stāvokli? Tas ievērojami samazinās resursu izmaksas, yay!
const [value, setValue] = useState(() => {
   console.log("INIT");
   return 0;
 });

Kā pārbaudīt, vai pirmais veids patiešām tiek izsaukts katrā renderēšanas reizē? Izveidojiet funkciju un nododiet to kā sākotnējo stāvokli:

const checkInit = () => {
console.log("INIT");
return 0;
};

const [value, setValue] = useState(checkInit());
```

Un tagad nododiet to, izmantojot otro veidu:

const checkInit = () => {
console.log("INIT");
return 0;
};

const [value, setValue] = useState(() => checkInit());
```

Forši, vai ne?

Noice.png

Vēl viena lieta, kas var radīt kļūdas lietotnes plūsmā: jūs droši vien zināt, kā atjaunināt stāvokli, vai ne?

setValue(1);

Pareizi... bet ko darīt, ja es gribu atjaunināt stāvokli, pamatojoties uz iepriekšējo stāvokli?

setValue(value + 1);

Jā... Bet nē... Ko darīt, ja mēģināsiet izsaukt iestatītāja funkciju divas reizes, vienu pēc otras? Ieteicamais veids, kā atjaunināt stāvokli, pamatojoties uz iepriekšējo stāvokli, ir izmantot funkciju. Tā garantē, ka jūs atsaucaties uz iepriekšējo stāvokli

setValue((prevState) => prevState + 1);
// ar objektiem:
setUser((prevState) => ({ ...prevState, lastName: "Brzeczyszczykiewicz" }));

useEffect

Šis Hook pieņem 2 argumentus (otrais arguments nav obligāts), un mēs to izmantojam, lai apstrādātu blakusparādības. Un atkarībā no tā, ko mēs nododam kā otro argumentu, āķis tiks izsaukts atšķirīgi:

  1. bez otrā argumenta - katrs render
izmantotEffect(() => {
   doSomething();
 });
  1. tukšs masīvs - tikai pirmajā renderēšanas reizē
useEffect(() => {
   doSomething();
 }, []);
  1. masīvs ar atkarībām - katru reizi, kad mainās atkarību masīva vērtība.
izmantotEffect(() => {
   doSomething(value);
 }, [value]);

Tīrīšana

Izmantojot useEffect, mēs varam izmantot kaut ko, ko sauc par tīrīšanu. Kādam nolūkam tas ir paredzēts? Tā ir ļoti noderīga, bet, manuprāt, vislabāk to var izmantot notikumu klausītāju tīrīšanai. Pieņemsim, ka vēlaties izveidot notikumu klausītāju, kas ir atkarīgs no kāda stāvokļa. Jūs nevēlaties pievienot jaunu notikumu klausītāju katrai stāvokļa maiņai, jo pēc dažiem renderēšanas reizēm būs tik daudz klausītāju, ka tas ietekmēs lietotnes veiktspēju. Lielisks veids, kā izvairīties no šādām lietām, ir izmantot tīrīšanas funkciju. Kā to izdarīt? Vienkārši pievienojiet atgriešanas funkciju funkcijai useEffect.

useEffect(() => {
console.log("blakus efekts 1", count);
return () => {
console.log("DESTROYED 1");
};
});

useEffect(() => {
console.log("blakus efekts 2", count);
return () => {
console.log("DESTROYED 2");
};
}, []);

useEffect(() => {
console.log("side effect 3", count);
return () => {
console.log("DESTROYED 3");
};
}, [count]);
```

Tā kā tas ir iekšpusē useEffect Hook, atgriešanās tiek izsaukta atkarībā no atkarību masīva - katrā renderēšanas reizē, tikai pirmajā renderēšanas reizē vai kad mainās vērtība atkarību masīvā. Bet, kad komponents tiek noņemts, tīrīšana tiks izsaukta otrajam argumentam neatkarīgi no tā, kas notiek. Atgriešanās kods tiek izsaukts pirms faktiskā Hook koda. Tas ir ļoti loģiski - vispirms iztīrīt veco, pēc tam izveidot jaunu. Vai ne?

izmantotEffect(() => {
   // addEventListener
   console.log("Add");
   return () => {
     // removeEventListener
     console.log("Remove");
   };
 }, [value]);

Vispirms jūs saņemsiet noņemt ziņojumu, tad Pievienot.

Lietojot useEffect un asinhrono kodu tā iekšienē, jāuzmanās no vienas lietas. Aplūkojiet turpmāk sniegto kodu:

izmantotEffect(() => {
   fetch("https://picsum.photos/5000/5000").then(() => {
     setValue((prevState) => prevState + 1);
   });
 }, []);

Sākumā tas izskatās labi. Jūs saņemat dažus dati, un, kad dati tiek saņemti, atjaunina stāvokli. Un šeit ir slazds:

Dažreiz saņemat šādu brīdinājumu:
Nevar veikt React stāvokļa atjaunināšanu neuzmontētai sastāvdaļai. Tas nav iespējams, bet norāda uz atmiņas noplūdi jūsu lietojumprogrammā. Lai to novērstu, atceliet visus abonementus un asinhronos uzdevumus useEffect tīrīšanas funkcijā.

Iemesls ir tāds, ka komponentu tikmēr var atvienot, bet lietotne joprojām mēģinās atjaunināt šīs komponentes stāvokli pēc solījuma izpildes. Kā ar to rīkoties? Jāpārbauda, vai komponents eksistē.

useEffect(() => {
let mounted = true;
fetch("https://picsum.photos/5000/5000").then((() => {
if (mounted) {
setValue((prevState) => prevState + 1);
}
});

return () => {
mounted = false;
};
}, []);
```

Piezīme: ir ļoti līdzīgs Hook => useLayoutEffect() - atsauces zvans tiek palaists pēc komponenta atveidošanas, bet pirms domēns tiek vizuāli atjaunināts. Tas ir noderīgs, strādājot ar getBoundingClientRect(), bet pēc noklusējuma vajadzētu izmantot useEffect. Kāpēc? Tāpēc, ka tas var bloķēt vizuālos atjauninājumus - ja efekta āķa iekšpusē ir sarežģīts kods.

useContext

Kādam nolūkam tas ir paredzēts? Datu koplietošana bez rekvizītu nodošanas. Sastāv no šādiem elementiem:

  1. Izveidotais konteksts - dati
  2. Konteksta nodrošinātājs - sniedziet kontekstu visiem bērniem.
  3. Nodotā vērtība - dati, kurus vēlaties kopīgot
  4. Āķis - koplietojamo datu lasīšanai
const user = {
vārds: "Adam",
lastName: "Kowalski",
};

export const UserContext = createContext(user);

;
```

Bērnā ir jāimportē konteksts un jāizsauc useContext Hook, kā argumentu nododot šo kontekstu.

importēt { UserContext } no "./App";

const { name } = useContext(UserContext);

return <h1>Sveiki {vārds}<>
```

Voilà. Izskatās forši. Galvenokārt globālo datu, piemēram, tēmu utt., nodošanai. Nav ieteicams izmantot uzdevumos ar ļoti dinamiskām izmaiņām.

Protams, mēs varam izveidot pielāgotu konteksta pakalpojumu sniedzēju un pielāgotu āķi, lai tā vietā samazinātu boilerplate... bet par pielāgotiem āķiem es runāšu nākamajā rakstā.

useReducer

Tas ļauj mums pārvaldīt stāvokli un atkārtoti attēlot, kad stāvoklis mainās - tāpat kā useState. Tas ir līdzīgs redux reduktors. Šis ir labāks nekā useState, ja stāvokļa loģika ir sarežģītāka.

const [state, dispatch] = useReducer(reducer, initialArg); 
  • Atgriež faktisko stāvokli ar nosūtīšanas metodi.
  • Sākotnējā vērtība tiek norādīta, kad tiek izsaukts āķis, un tas atšķiras no redux lietojuma.

Ir arī trešais arguments, ko var nodot funkcijai useReducer - funkcija init.

const [state, dispatch] = useReducer(reducer, initialArg, init);

Kādam nolūkam tas ir paredzēts? To var izmantot, ja vēlamies atjaunot stāvokli līdz tā sākotnējai vērtībai. Zemāk varat atrast skaistu piemēru:

// Vecāks
// Bērns
funkcija init(initialNumber) {
return { number: initialNumber };
}

funkcija reducer(state, action) {
switch (action.type) {
case "change":
atgriezt { number: Math.random() };
gadījums "reset":
atgriezt init(action.payload);
pēc noklusējuma:
throw new Error();
}
}

eksportēt noklusējuma funkciju ChildComponent({ getFactorial }) {
const [state, dispatch] = useReducer(reducer, initialNumber, init);

return (
<>
   <h2>Numurs: {state.number}</h2>
      <button
        onclick="{()" > nosūtīšana({ tips: "reset", ielāde: initialNumber })}
      &gt;
        Atiestatīšana
      </button>
      <button onclick="{()" > nosūtīšana({tips: "mainīt" })}&gt;Noskicēt</button>
    </>
  );
}

Numurs: {state.number}

ReducerInit.png

useCallback

Kad to izmantot? Ja vēlamies panākt atsauces vienlīdzību (tādējādi samazinot radīto funkciju skaitu). Šis Hook atgriež funkciju, atšķirībā no useMemo, kas atgriež vērtību.

Piemērs: Izveidojiet funkciju vecākajā komponentē un pēc tam nododiet to, izmantojot rekvizītus

/// Vecāks
 const getSquaredValue = () => count * count;
 ...
 return (
   
 )

Pēc tam pārbaudiet bērnu komponentē, cik reižu tiks izsaukts efekts Hook pēc šīs funkcijas pievienošanas atkarību masīvam:

/// Bērns
 useEffect(() => {
   console.log("getSquaredValue", getSquaredValue());
 }, [getSquaredValue]);

Tas pierakstīsies konsoles logā par katru renderēšanas reizi! Pat ja vērtības, kas atrodas getSquaredValue() funkcija nav mainījusies. Bet mēs varam no tā izvairīties, iesaiņojot šo funkciju funkcijā useCallback

const getSquaredValue = useCallback(() => count * count, [count])

Šai funkcijai varam arī nodot dažus parametrus:

const getSquaredValue = useCallback(
   (reizinātājs) => count * count * reizinātājs,
   [count]
 );

useMemo

const memoizedValue = useMemo(() => {
   return doSomething(value);
 }, [value]);
  • Tas nav neitrāls, aplūkojot resursu izmaksas - useMemo jāizsauc katrā renderēšanas reizē, tas saglabā vērtību atmiņā un salīdzina (atmiņas pieskaitāmās izmaksas),
  • izmanto Memoization - optimizācijas tehniku, īpašu kešēšanas veidu.

To vajadzētu izmantot tikai divos gadījumos:

  1. Ja vēlaties novērst sarežģīta koda izsaukšanu katrā renderēšanas reizē;
  2. Ja vēlaties panākt atsauces vienlīdzību.

Aplūkosim mazliet tuvāk otro gadījumu. Mēs vēlamies izmantot useEffect ar objektu kā atkarību. Tā kā objekti tiek salīdzināti pēc atsauces, useEffect tiks izsaukts katrā renderēšanas reizē. Lai no tā izvairītos, mēs varam apvienot useEffect ar useMemo, lai memoizētu šādus objektus un pēc tam nodotu šos memoizētos objektus atkarību masīvam. Īss piemērs:

Vispirms mēģiniet to izdarīt bez useMemo:

const hobbit = { vārds: "Bilbo" };

useEffect(() => {
console.log("Hello ", hobbit.name);
}, [hobbit]);
```

Jūs saņemsiet arī brīdinājumu:

Objekts 'hobbit' liek mainīties useEffect Hook (49. rinda) atkarībām katrā renderēšanas reizē. Pārvietojiet to atpakaļsaukuma useEffect ietvaros. Kā alternatīvu var izmantot 'hobbit' inicializāciju savā useMemo () Hook.eslintreact-hooks/exhaustive-deps

Pēc tam izmēģiniet ar useMemo:

const hobbit = useMemo(() => { {
return { vārds: "Bilbo" };
}, []);

useEffect(() => {
console.log("Hello ", hobbit.name);
}, [hobbit]);
```

useRef

Vissvarīgākais: useRef neizraisa atkārtotu renderēšanu (tāpat kā useState), jo tas nav saistīts ar renderēšanas ciklu - tas saglabā to pašu atsauci starp renderēšanas reizēm.

const ref = useRef(0);

Lai izsauktu saglabāto vērtību, ir jāizmanto pašreizējā īpašība (ref ir objekts) - ref.current

Otrs gadījums, kurā varam izmantot šo āķi, ir atsaukšanās uz HTML elementiem. Katram elementam ir atribūts ref. Tādējādi mēs varam apstrādāt fokusu, notikumus utt.

Trešais gadījums ir tāds, ka mēs varam izmantot refs, lai apstrādātu nekontrolējamus komponentus. Vairāk par tiem var izlasīt react dokumenti,
bet īsumā tas izskatās šādi:

eksportēt noklusējuma funkciju UncontrolledForm() {
  const input = useRef();

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log(input.current.value);
  };

  return (
    
      
      
    
  );
}

Kā redzat, nav notikuma apstrādātāja, tas vienkārši atceras ievadīto vērtību. Tas ir lieliski piemērots vienkāršu veidlapu apstrādei, kad vēlaties tikai nolasīt saglabātās vērtības, kad tās ir nepieciešamas (piemēram, nosūtot).

Bonuss: tas ir lieliski noderīgs, ja nepieciešams atcerēties iepriekšējās stāvokļa vērtības. Tam var izmantot useEffect Hook, tikai nododiet stāvokli ref.

const [value, setValue] = useState("");

let prevValue = useRef("");

useEffect(() => {
  prevValue.current = value;
}, [value]);

 setValue(e.target.value)}>;

Kā redzat, āķi nav tik acīmredzami. Mēs varam tos kombinēt, lai atrisinātu daudzas problēmas. Jūs noteikti gūsiet lielu labumu no šīs tēmas izpētes.

Ir arī pielāgotie āķi...

Nobeigumā, React āķi ir revolucionizējuši veidu, kā React izstrādātāji pieeja ēkai tīmekļa vietne lietojumprogrammas . Sniedzot intuitīvāku un efektīvāku veidu, kā pārvaldīt funkcionālo komponentu stāvokli un dzīves ciklu, āķi ir kļuvuši par neatņemamu funkcionālo komponentu. React izstrāde .

Neatkarīgi no tā, vai esat pieredzējis izstrādātājs vai tikai sākat strādāt ar React, ir svarīgi saprast populārākos āķus un to izmantošanas gadījumus. Ar tādiem āķiem kā useState, useEffect, useContext un citiem, React komponenti var izveidot tīrāku un vairākkārt izmantojamu kodu. Turklāt iespēja izveidot pielāgotie āķi ļauj izstrādātājiem iekapsulēt un koplietot loģiku vairākās sastāvdaļās, veicinot koda atkalizmantojamību un modularitāti. Tā kā React turpina attīstīties un ieviest jaunas funkcijas, āķiem neapšaubāmi būs galvenā loma, lai pilnībā izmantotu sistēmas potenciālu.

Neatkarīgi no tā, vai strādājat pie nelielas funkcionālas lietojumprogrammas vai liela mēroga tīmekļa lietojumprogrammas. React āķi uzlabos jūsu izstrādes darbplūsmu un pavērs neskaitāmas iespējas, lai radītu stabilu un daudzfunkcionālu lietojumprogrammu. React lietojumprogrammas .

1. daļas beigas

Lasīt vairāk:

JavaScript ir pilnībā miris. Kāds puisis internetā

GraphQL/MongoDB API izvēršana, izmantojot Netlify funkcijas

Kā nogalināt projektu ar sliktu kodēšanas praksi

Saistītie raksti

Ilustrācija viedtālruņa veselības aprūpes lietotnei ar sirds ikonu un pieaugošo veselības diagrammu, kas apzīmēta ar The Codest logotipu, kurš pārstāv digitālās veselības un HealthTech risinājumus.
Programmatūras izstrāde

Veselības aprūpes programmatūra: Mārketinga programmatūra: veidi, izmantošanas gadījumi

Šodien veselības aprūpes organizāciju rīcībā esošie rīki vairs neatgādina papīra diagrammas, kas tika izmantotas pirms vairākiem gadu desmitiem. veselības aprūpes programmatūra tagad atbalsta veselības aprūpes sistēmas, pacientu aprūpi un mūsdienīgu veselības aprūpes sniegšanu klīniskajās un...

TĀKĀDĒJAIS
Abstrakta ilustrācija ar lejupejošu joslu diagrammu ar augošu bultiņu un zelta monētu, kas simbolizē izmaksu efektivitāti vai ietaupījumus. Augšējā kreisajā stūrī redzams The Codest logotips ar saukli "In Code We Trust" uz gaiši pelēka fona.
Programmatūras izstrāde

Kā paplašināt izstrādātāju komandu, nezaudējot produkta kvalitāti

Palielināt izstrādātāju komandu? Uzziniet, kā augt, nezaudējot produkta kvalitāti. Šajā rokasgrāmatā aplūkotas pazīmes, kas liecina, ka ir pienācis laiks paplašināt komandu, komandas struktūra, pieņemšana darbā, vadība un rīki, kā arī tas, kā The Codest var...

TĀKĀDĒJAIS
Programmatūras izstrāde

Uz nākotni noturīgu tīmekļa lietojumprogrammu veidošana: The Codest ekspertu komandas ieskats

Uzziniet, kā The Codest izceļas mērogojamu, interaktīvu tīmekļa lietojumprogrammu izveidē, izmantojot modernākās tehnoloģijas un nodrošinot viengabalainu lietotāja pieredzi visās platformās. Uzziniet, kā mūsu zināšanas veicina digitālo transformāciju un biznesa...

TĀKĀDĒJAIS
Programmatūras izstrāde

Top 10 Latvijā bāzēti programmatūras izstrādes uzņēmumi

Mūsu jaunākajā rakstā uzziniet vairāk par Latvijas labākajiem programmatūras izstrādes uzņēmumiem un to inovatīvajiem risinājumiem. Uzziniet, kā šie tehnoloģiju līderi var palīdzēt uzlabot jūsu biznesu.

thecodest
Uzņēmumu un mērogošanas risinājumi

Java programmatūras izstrādes pamati: A Guide to Outsourcing Successfully

Izpētiet šo būtisko rokasgrāmatu par veiksmīgu outsourcing Java programmatūras izstrādi, lai uzlabotu efektivitāti, piekļūtu speciālajām zināšanām un sekmīgi īstenotu projektus ar The Codest.

thecodest

Abonējiet mūsu zināšanu bāzi un saņemiet jaunāko informāciju par IT nozares pieredzi.

    Par mums

    The Codest - starptautisks programmatūras izstrādes uzņēmums ar tehnoloģiju centriem Polijā.

    Apvienotā Karaliste - Galvenā mītne

    • 303B birojs, 182-184 High Street North E6 2JA
      Londona, Anglija

    Polija - Vietējie tehnoloģiju centri

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Krakova
    • Brain Embassy, Konstruktorska
      11, 02-673 Varšava, Polija

    The Codest

    • Sākums
    • Par mums
    • Pakalpojumi
    • Case Studies
    • Zināt, kā
    • Karjera
    • Vārdnīca

    Pakalpojumi

    • Tā Konsultatīvais dienests
    • Programmatūras izstrāde
    • Backend izstrāde
    • Frontend izveide
    • Staff Augmentation
    • Backend izstrādātāji
    • Mākoņa inženieri
    • Datu inženieri
    • Citi
    • QA inženieri

    Resursi

    • Fakti un mīti par sadarbību ar ārējo programmatūras izstrādes partneri
    • No ASV uz Eiropu: Kāpēc Amerikas jaunuzņēmumi nolemj pārcelties uz Eiropu?
    • Tehnoloģiju ārzonas attīstības centru salīdzinājums: Tech Offshore Eiropa (Polija), ASEAN (Filipīnas), Eirāzija (Turcija)
    • Kādi ir galvenie CTO un CIO izaicinājumi?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Autortiesības © 2026 The Codest. Visas tiesības aizsargātas.

    lvLatvian
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian es_ESSpanish nl_NLDutch etEstonian elGreek pt_PTPortuguese cs_CZCzech lt_LTLithuanian is_ISIcelandic lvLatvian