Wyrenderuje reactowy element w węźle drzewa DOM, czyli najpierw przekaże element DOM do ReactDOM.createRoot(), a następnie przekaże element reactowy do root.render().

Wyrenderuje reactowy element w węźle drzewa DOM, ale nie przekaże elementu DOM do ReactDOM.createRoot(), a następnie nie przekaże elementu reactowego do root.render().

Nie wyrenderuje reactowego elementu w węźle drzewa DOM.

Nie wyświetli się napis: Witaj, świecie!

Wyświetli się migający i potem znikający napis: Witaj, świecie!

tablica, wiersz, kolumna;

kolekcja, dokument, klucz;

komórka, klasa, tabela;

wiersz, komórka, tablica;

nie stosujemy żadnych pojęć

Po lewej i po prawej jest kod JavaScript;

Po lewej kod TypeScript, ponieważ nie zastosowano statycznego typowania; Po prawej kod JavaScript, ponieważ zastosowano statyczne typowanie.

Po lewej i po prawej jest kod TypeScript;

Po lewej kod JavaScript, ponieważ zastosowano statyczne typowanie; Po prawej kod TypeScript.

Po lewej kod TypeScript, ponieważ zastosowano statyczne typowanie; Po prawej kod JavaScript.

Autoryzacja to dodatkowy, inny sposób na uwierzytelnienie stosowany w celu zwiększenia bezpieczeństwa.

Autoryzacja i uwierzytelnianie to proces potwierdzania deklarowanej tożsamości użytkownika, często za pomocą tajnych informacji.

Autoryzacja i uwierzytelnianie mogą polegać na wprowadzeniu adresu e-mail na stronie logowania Google.

Uwierzytelnienie odpowiada na pytanie „Kim jesteś?”, czyli pozwala na potwierdzanie tożsamości. Natomiast autoryzacja odpowiada na pytanie „Co możesz zrobić?”, co stanowi kontrolę dostępu do zasobów.

Autoryzacja to proces potwierdzania tożsamości użytkownika, zwykle przez wymaganie od niego nazwy użytkownika i hasła, co prowadzi do tego, że uwierzytelnianie nie jest już potrzebne.

a) nie mogą być używane jako konstruktory (nie zadziała słówko new);

b) nie są bindowane do this ani super, a więc nie powinny być używane jako metody, nie są też odpowiednie do wywołania przez call, apply czy używania metody bind;

c) nie mają wsparcia dla słów kluczowych yield, arguments ani new.target;

d) odpowiedzi a)–c) są prawdziwe.

e) wszystkie odpowiedzi a)–c) są błędne.

a. Wywołuj hooki tylko z najwyższego poziomu kodu. Nie wywołuj hooków z wewnątrz pętli, warunków czy zagnieżdżonych funkcji.

b. Wywołuj hooki tylko z wewnątrz reactowych komponentów funkcyjnych. Nie wywołuj hooków z wewnątrz zwykłych javascriptowych funkcji (poza własnymi hookami).

c. a i b są fałszywe

d. a i b są prawdziwe

e. prawdą jest tylko a

• nie ma czegoś takiego jak kaskadowość;

pierwszeństwo zawsze mają style pochodzące z arkuszy zewnętrznych;

pierwszeństwo w oddziaływaniu na te same elementy strony stylów z różnych źródeł, a jeśli w dokumencie jest więcej źródeł stylów, to pierwszeństwo mają te, które znajdują się "bliżej" formatowanego elementu;

nie wiadomo co ją określa, nie zostało to bliżej określone;

pierwszeństwo w oddziaływaniu na te same elementy strony stylów z tych samych źródeł, a jeśli w dokumencie jest więcej źródeł stylów, to pierwszeństwo mają te, które znajdują się "dalej" formatowanego elementu;

Przy Fetch trzeba zająć się dwiema obietnicami, a przy Axios można uzyskać dostęp do wyniku JSON bezpośrednio z obiektu odpowiedzi przez właściwość data.Ponadto, Fetch nie wyrzuca błędów sieciowych, a Axios tak. Axios może monitorować postęp ładowania danych, czego nie umożliwia Fetch.

Różnic jest co najmniej kilkanaście, ale decydujące znaczenie mają obowiązujące standardy i preferencje programistów.

Pomimo wielu wad i niedogodności związanych z pisaniem kodu i jego wykonywaniem, jest to jak dotąd najbardziej popularne rozwiązanie.

Tylko i wyłącznie ze względu na możliwość pisania krótszego kodu.

Żeby pisać czystszy i bardziej zwięzły kod, choć nie ma to dużego znaczenia dla wykonywania kodu, bo poza tym istotnych różnic brak.

Po lewej jest kod napisany bez zastosowania JSX, a po prawej jest kod napisany w JSX;

Po lewej jest kod JavaScript, ponieważ zastosowano statyczne typowanie; Po prawej jest TypeScript.

Po lewej jest kod TypeScript, ponieważ nie zastosowano statycznego typowania; Po prawej jest kod JavaScript, ponieważ zastosowano statyczne typowanie.

Po lewej jest kod napisany w JSX, a po prawej jest kod bez zastosowania JSX.

Po lewej jest kod TypeScript, ponieważ zastosowano statyczne typowanie; Po prawej jest kod JSX.

nie jest możliwe złamanie tej zasady, gdyż utrudniałoby to analizę formatowania elementów;

nie można złamać tej zasady, gdyż pojawiłoby się zbyt wiele błędów;

zasada ta nie obowiązuje od HTML 5, który wyklucza kaskadowość;

można złamać tę zasadę poprzez odpowiednie znaczniki;

zastosowanie polecenia !important, gdy pojawia się ono po wartości cechy, to taka cecha będzie miała pierwszeństwo przed innymi, nawet gdy ma niższy priorytet;

może to być każdy format, jednak rozmiar jest ograniczony;

JSON (fizycznie BSON o maksymalnym rozmiarze 16 MB);

nie ma takiego formatu i może przyjmować dowolny rozmiar;

nie można go określić i nie można określić jego rozmiaru;

zdefiniowanym przez użytkownika i o rozmiarze przez niego zdefiniowanym;

W React należy dodać atrybut value na elemencie formularza.

React należy dodać atrybut selected do dowolnego znacznika.

W React należy dodać atrybut selected do znacznika select.

W React nie należy dodać atrybutu value na elemencie formularza.

Nie można poprawnie zbudować komponentu kontrolowanego w formularzu reactowym.

Zostały napisane z wykorzystaniem modyfikowanego HTMLa, a zastosowanie klamr w obydwu fragmentach kodu jest prawidłowe.

Zostały napisane z wykorzystaniem czystego TypeScriptu, a zastosowanie klamr w obydwu fragmentach kodu jest błędne.

Zostały napisane z wykorzystaniem JSX, czyli rozszerzenia składni JavaScriptu o możliwość wstawiania znaczników, a dowolne wyrażenie JavaScriptowe można osadzić w JSX poprzez otoczenie go klamrami.

Zostały napisane z wykorzystaniem czystego JavaScriptu, a zastosowanie klamr w obydwu fragmentach kodu jest błędne.

Zostały napisane z wykorzystaniem czystego JavaScriptu, a dowolnego wyrażenia JavaScriptowego nie można osadzić w JSX poprzez otoczenie go klamrami, dlatego kod napisany po prawej stronie jest błędny.

w JS nie ma takiej możliwości;

tak, ale nie zawsze to jest możliwe;

w JS Event Loop działa błędnie;

nie, ponieważ JS jest wielowątkowy;

w przypadku asynchroniczności działa zasada LIFO (Last In First Out);

Tak, ponieważ może zachodzić potrzeba ukrycia komponentu, mimo iż został on już wyrenderowany przez inny komponent. Aby to umożliwić, należy zwrócić zamiast niego wartość null. Zwrócenie wartości null w metodzie render danego komponentu nie ma wpływu na wywoływanie metod cyklu życia tego komponentu.

Nie, ponieważ nie ma poprawnego sposobu na ukrycie komponentu. Komponent zawsze musi być widoczny.

Tak, ponieważ może nie zachodzić potrzeba ukrycia komponentu, mimo iż został on już wyrenderowany przez inny komponent. Aby to umożliwić, należy zwrócić zamiast niego error. Zwrócenie error w metodzie render danego komponentu nie ma wpływu na wywoływanie metod cyklu życia tego komponentu.

Tak, ponieważ może nie zachodzić potrzeba ukrycia komponentu, mimo iż został on już wyrenderowany przez inny komponent. Aby to umożliwić, należy zwrócić zamiast niego wartość true. Zwrócenie wartości true w metodzie render danego komponentu nie ma wpływu na wywoływanie metod cyklu życia tego komponentu.

Tak, ponieważ może zachodzić potrzeba ukrycia komponentu, mimo iż został on już wyrenderowany przez inny komponent. Aby to umożliwić, należy zwrócić zamiast niego wartość false. Zwrócenie wartości false w metodzie render danego komponentu nie ma wpływu na wywoływanie metod cyklu życia tego komponentu.

posiadają swoją specyfikację i nie spełniają żadnych reguł;

niejednolity interfejs komunikacyjny, brak podziału na aplikacje klient-serwer, bezstanowość, cache danych, odseparowane warstwy;

jednolity interfejs komunikacyjny, podział na aplikacje klient-serwer, bezstanowość, cache danych, odseparowane warstwy;

nie posiadają swojej specyfikacji i nie spełniają żadnych reguł;

podział na aplikacje klient-serwer, bezstanowość, cache danych, odseparowane warstwy, wysyłanie kodu do aplikacji klienta;

Po lewej kod TypeScript, ponieważ nie zastosowano statycznego typowania; Po prawej kod JavaScript, ponieważ zastosowano statyczne typowanie.

Po lewej i po prawej jest kod TypeScript;

Po lewej kod JavaScript, ponieważ zastosowano statyczne typowanie; Po prawej kod TypeScript.

Po lewej kod TypeScript, ponieważ zastosowano statyczne typowanie; Po prawej kod JavaScript.

Po lewej i po prawej jest kod JavaScript;

Funkcja reducer pełni rolę obiektu store architektury Flux. Dzięki temu, że jest to funkcja, można jej jednocześnie użyć jako funkcji wywołania zwrotnego, którą store uruchomi w momencie gdy zostanie rozgłoszona jakaś akcja. Funkcja ta przyjmuje dwa parametry: state oraz action.

Redux jest uzależniony od ReactJS. W zasadzie nie można go używać z innymi frameworkami JavaScript.

Redux nie może być opisany przez trzy fundamentalne zasady: 1) stan całej aplikacji przetrzymywany jest w drzewie obiektów wewnątrz pojedynczego obiektu store, 2) jedynym sposobem na zmianę stanu jest wywołanie akcji, która zwraca obiekt opisujący co powinno się stać, 3) aby określić, jak drzewo stanu transformowane jest przez akcje trzeba tworzyć "czyste reducery".

Funkcja reducer nie pełni roli obiektu store architektury Flux. Dzięki temu, że jest to funkcja, można jej jednocześnie użyć jako funkcji wywołania zwrotnego, którą store uruchomi w momencie gdy zostanie rozgłoszona jakaś akcja. Funkcja ta nie przyjmuje żadnego parametru.

Redux może być opisany przez trzy fundamentalne zasady: 1) stan całej aplikacji nie jest przetrzymywany w drzewie obiektów wewnątrz pojedynczego obiektu store, 2) niejedynym sposobem na zmianę stanu jest wywołanie akcji, która nie zwraca obiektu opisującego co powinno się stać, 3) aby określić, jak drzewo stanu transformowane jest przez akcje nie trzeba tworzyć "czystych reducerów".

useState, useEffect, useContext, UserInfo, Comment, preventDefault, Axios i Enzyme;

useState, useEffect, useContext, useReducer, useCallback, useRef, useTransition i useId;

React DOM, React.createElement, UserInfo, Comment, preventDefault, useLayoutEffect i useMemo;

combineReducers, useImperativeHandle, react-google-oauth, react-router-dom, useDebugValue i useTransition;

Redux, mapStateToProps, componentDidMount, mapDispatchToProps, combineReducers i Flux;

nie jest to typ MIME albo Content-Type, to jest typ HTTP danych;

nie jest to poprawne stwierdzenie, bo nie ma czegoś takiego jak response header;

nie sposób tego określić;

jest to poprawne stwierdzenie;

typ pliku nigdy nie ma znaczenia, gdyż zawsze to jest ten sam typ;