Vai tu uzskatītu signālus un RxJS par savstarpēji aizvietojamiem rīkiem, vai katru savu uzdevumu? Ja otrais — tieši kādam?
Frontend
Vai tev ir pieredze risināt veiktspējas problēmas frontendā? Piemēram, kļūdas ziņojums par palēninājumiem, vai tu pats pamanīji problēmu darba laikā. Vai vari sniegt konkrētu piemēru, kā tu to novērēji?
Vai tu saproti principu, kas ir sadalījums starp loģiku un prezentāciju modelī, uz kura balstās daudzas arhitektūras pieejas? No kurienes šī ideja sākotnēji radās?
Kādu argumentu mēs nododam funkcijai inject? Ko tieši tur nodod — atkarību vai kaut ko citu (token)?
Jūs minējāt, ka izstrādājat atkārtoti izmantojamu UI-kit komponentu bibliotēku, kas balstīta uz Angular Material. Vai ir būtiska atšķirība starp bibliotēkas komponentiem un parastajiem daudzfunkcionālajiem lietojumprogrammas komponentiem? No kā var atteikties parastos komponentēs, bet ne bibliotēkā?
Kādi konkrēti komandrindas scenāriji bija tavā praksē, izņemot Angular CLI palaišanu?
Papildus tam, ka konstruktors neuzpūšas, kādi ir vēl iemesli izmantot inject vietā, nevis konstruktoru parametru?
Kādi kritēriji ir svarīgi bibliotēkas UI-kita komponentiem, ar kuriem jūs personīgi esat saskāries praksē (piemēram, atbildības robežu noteikšana)?
Kam vispār ir nepieciešama koda pārskatīšana? Vai tā ir patiešām nepieciešama, un kādos gadījumos?
Kā tu raksturotu atšķirību starp Middle un Senior frontend izstrādē?
Kāpēc objektorientētajā programmēšanā ir nepieciešama mantošana un kādos gadījumos to būtu jāizmanto?
Vai tev ir pieredze darbā ar komandrindu (shell-komandas), izņemot Git un FTP?
Vai tavā kodā bija abonēšana iekš citas abonēšanas (parasta RxJS problēma)? Vai tu to laboji vai tas joprojām ir tāds pats?