Danh sách câu hỏi của đề

Câu hỏi: FER202 Phát triển web Front-End với React – Bộ ôn tập cuối kỳ số 2

50 câu trắc nghiệm kèm lời giải của môn FER202 - Phát triển web Front-End với React, xếp đúng thứ tự trong đề.

Danh sách câu hỏi

20/50 câuCòn 30
AFlux enforces unidirectional data flow, while MVC allows bidirectional data flow.
BMVC enforces unidirectional data flow, while Flux allows bidirectional data flow.
CBoth Flux and MVC enforce unidirectional data flow.
DBoth Flux and MVC allow bidirectional data flow.
Lời giải
Đáp án đúng: "Flux enforces unidirectional data flow, while MVC allows bidirectional data flow.". Flux là kiến trúc Facebook đề xuất cho ứng dụng React, buộc dữ liệu đi theo một chiều (unidirectional data flow): view phát action, dispatcher chuyển action tới store, store cập nhật rồi view render lại; view không được sửa store trực tiếp. Trong MVC, controller và view đều có thể cập nhật model, model lại báo ngược cho view, nên dữ liệu đi hai chiều (bidirectional) và khó lần theo khi ứng dụng lớn. Phát biểu "MVC enforces unidirectional data flow, while Flux allows bidirectional data flow." đảo ngược vai trò của hai kiến trúc. "Both Flux and MVC enforce unidirectional data flow." sai vì MVC không ép luồng một chiều. "Both Flux and MVC allow bidirectional data flow." sai vì mục tiêu cốt lõi của Flux chính là loại bỏ luồng hai chiều để trạng thái dễ dự đoán.
Mở trang câu hỏi này →
A<ErrorBoundary>
B<Suspense>
C<LoadingComponent>
D<Provider>
Lời giải

Đáp án đúng: "<Suspense> ". React.lazy cho phép tải một component theo kiểu động, tách nó thành một chunk riêng chỉ được tải khi cần; trong lúc chunk đang tải, component lazy tạm "treo" (suspend), và component Suspense bao ngoài sẽ hiển thị giao diện thay thế đặt trong thuộc tính fallback, chẳng hạn chữ đang tải hoặc vòng quay, cho tới khi mã tải xong. "<ErrorBoundary> " sai vì error boundary là component tự viết để bắt lỗi khi render, kể cả khi tải chunk thất bại; nó thường được dùng kèm nhưng xử lý trạng thái lỗi chứ không phải trạng thái đang tải. "<LoadingComponent> " sai vì React không có component dựng sẵn nào tên như vậy; đó chỉ là tên một component tự đặt mà ta có thể truyền vào fallback. "<Provider> " sai vì Provider của Context hay của react-redux dùng để cung cấp dữ liệu dùng chung cho cây component, không liên quan đến việc tải mã.

Mở trang câu hỏi này →
3What is Redux Thunk used for?4 lựa chọn
ATo manage asynchronous actions in Redux.
BTo log every action dispatched to the Redux store.
CTo split reducers into simpler functions.
DTo handle side effects in React components.
Lời giải
Đáp án đúng: "To manage asynchronous actions in Redux.". Redux thuần chỉ cho dispatch đối tượng action và reducer phải là hàm thuần đồng bộ, nên không có chỗ đặt lời gọi API; Redux Thunk là middleware cho phép dispatch một hàm (thunk) thay cho đối tượng, hàm này nhận dispatch và getState, có thể chờ fetch xong rồi mới dispatch action thành công hoặc thất bại. Redux Toolkit cài sẵn thunk và cung cấp createAsyncThunk dựa trên chính cơ chế này. Phương án "To log every action dispatched to the Redux store." là việc của middleware ghi log như redux-logger. Phương án "To split reducers into simpler functions." là việc của combineReducers hoặc chia slice. Phương án "To handle side effects in React components." nói về phía component, nơi tác vụ phụ được xử lý bằng useEffect; thunk xử lý logic bất đồng bộ ở tầng Redux chứ không nằm trong component.
Mở trang câu hỏi này →
A<Suspense loader={<div>Loading...</div>}> <LazyComponent /> </Suspense>
B<Suspense fallback={<div>Loading...</div>}> <LazyComponent /> </Suspense>
C<Await fallback={<div>Loading...</div>}> <LazyComponent /> </Await>
D<Loading fallback={<div>Loading...</div>}> <LazyComponent /> </Loading>
Lời giải

Đáp án đúng: "<Suspense fallback={ <div>Loading...</div> }> <LazyComponent /> </Suspense>". Component nạp lười bằng React.lazy phải nằm trong ranh giới Suspense; trong lúc tệp mã của nó còn đang tải, React hiển thị thứ được truyền qua prop fallback (ở đây là khối chữ Loading...), tải xong thì thay bằng LazyComponent. Phương án chứa "<Suspense loader=" sai vì Suspense không có prop loader, React bỏ qua nó, nên trong lúc chờ không có giao diện chờ nào được chỉ định. Phương án chứa "<Await fallback=" nhầm sang component Await của React Router, dùng để chờ một promise trả về từ loader; nó không bọc component lazy và cũng không nhận prop fallback. Phương án chứa "<Loading fallback=" dùng một component không có sẵn trong React; dù tự định nghĩa component Loading, nó cũng không bắt được trạng thái tạm treo khi tải mã như Suspense.

Mở trang câu hỏi này →
Afetch(url).then((response)=>{ return response.json();} ).catch(error => console.log(error))
Bfetch(url).then(response => response.catch(error => console.log(error)))
Cfetch(url).catch(error => {{ console.log(error) }})
Dfetch(url).then(response => { throw new Error() }).catch(error => console.log(error))
Lời giải

Đáp án đúng: "fetch(url).then((response)=>{ return response.json(); } ).catch(error => console.log(error))". fetch trả về một Promise; then nhận response và trả về response.json(), cũng là một Promise, còn catch đặt ở cuối chuỗi bắt mọi lỗi ném ra ở bất kỳ bước nào trước nó, như lỗi mạng làm fetch bị reject hay lỗi phân tích JSON, rồi ghi ra console. Cần nhớ fetch không reject khi server trả 404 hay 500; muốn coi đó là lỗi thì kiểm response.ok rồi tự ném lỗi trong then. Cách viết "then(response => response.catch(" sai vì response là đối tượng Response chứ không phải Promise, không có phương thức catch, gọi vào sẽ gây TypeError. "fetch(url).catch(error => {{

Lời giải
console.log(error)
}
}
)"

bắt được lỗi mạng nhưng không bao giờ đọc dữ liệu trả về; cặp ngoặc nhọn lồng nhau chỉ là một khối lệnh thừa. Cách viết "then(response => { throw

Lời giải
new Error()
}
)"

luôn ném lỗi kể cả khi yêu cầu thành công, nên catch chỉ ghi ra một lỗi rỗng thay vì xử lý dữ liệu.

Mở trang câu hỏi này →
AIt allows direct modification of the DOM
BIt makes synchronous code asynchronous.
CIt helps solve the "callback hell" problem by allowing chains of asynchronous operations.
DIt ensures data is always instantaneously available.
Lời giải
Đáp án đúng: "It helps solve the "callback hell" problem by allowing chains of asynchronous operations.". Promise là đối tượng đại diện cho kết quả tương lai của một thao tác bất đồng bộ, ở một trong ba trạng thái pending, fulfilled, rejected; mỗi lần gọi then trả về một Promise mới nên các bước có thể nối thành chuỗi phẳng và gom lỗi về một catch, thay vì lồng callback trong callback thành hình kim tự tháp khó đọc (callback hell). "It allows direct modification of the DOM" sai vì sửa DOM là việc của DOM API hoặc React, Promise chỉ quản lý luồng bất đồng bộ. "It makes synchronous code asynchronous." sai vì bọc mã đồng bộ trong Promise không làm nó chạy song song; hàm executor vẫn chạy đồng bộ ngay lập tức, chỉ các callback của then được hoãn lại. "It ensures data is always instantaneously available." sai vì Promise sinh ra chính là để xử lý dữ liệu CHƯA có ngay, kết quả đến sau và có thể thất bại.
Mở trang câu hỏi này →
AInitial, Running, Completed
BStarting, Paused, Finished
CPending, Fulfilled, Rejected
DWaiting, Processing, Error Answer
Lời giải
Đáp án đúng: "Pending, Fulfilled, Rejected". Một Promise trong JavaScript luôn ở một trong ba trạng thái: pending (đang chờ) khi vừa được tạo và thao tác bất đồng bộ chưa xong; fulfilled (đã hoàn thành) khi resolve được gọi với một giá trị, lúc đó các hàm trong then chạy; rejected (bị từ chối) khi reject được gọi hoặc có lỗi, lúc đó catch chạy. Khi đã chuyển sang fulfilled hoặc rejected thì Promise được coi là settled (đã ngã ngũ) và không bao giờ đổi trạng thái nữa. "Initial, Running, Completed" sai vì đây là tên gọi tự đặt, không phải thuật ngữ của Promise, và nó không phân biệt được thành công với thất bại. "Starting, Paused, Finished" sai vì Promise không có trạng thái tạm dừng, nó cũng không tách kết quả thành công và lỗi. "Waiting, Processing, Error Answer" sai vì chuẩn không có các tên này, và thiếu hẳn trạng thái thành công.
Mở trang câu hỏi này →
Aresponse.data()
Bresponse.json()
Cresponse.jsonText()
Dresponse.body.json()
Lời giải
Đáp án đúng: "response.json()". Hàm fetch trả về một Promise cho object Response; phần thân của response là một luồng dữ liệu, nên phải gọi phương thức json() để đọc hết thân và phân tích (parse) nó thành object JavaScript, và chính phương thức này cũng trả về Promise, vì vậy ta thường nối tiếp bằng then hoặc dùng await trước nó. "response.data()" sai vì Response của Fetch API không có phương thức data; thói quen đọc thuộc tính data đến từ thư viện axios, nơi dữ liệu đã được parse sẵn và data là thuộc tính chứ không phải hàm. "response.jsonText()" sai vì không tồn tại phương thức này; thứ gần nhất là text(), trả về thân dưới dạng chuỗi thô. "response.body.json()" sai vì body là một ReadableStream, không có phương thức json; việc đọc và parse phải gọi thẳng trên response.
Mở trang câu hỏi này →
AState
BProps
CContext
DRef
Lời giải
Đáp án đúng: "Props". Props (thuộc tính) là cơ chế truyền dữ liệu một chiều từ cha xuống con: component cha viết giá trị như thuộc tính trên thẻ của con, component con nhận chúng qua tham số props và chỉ được đọc, không được sửa. Khi cha render lại với giá trị mới, con nhận props mới và render theo. Phương án "State" là dữ liệu riêng do chính component quản lý và thay đổi bằng hàm setter; state của cha thường được đưa xuống con nhưng phải đi qua props. Phương án "Context" cũng đưa dữ liệu xuống cây, nhưng dùng khi dữ liệu cần tới nhiều tầng sâu để khỏi truyền props qua từng cấp, không phải khái niệm cơ bản cho quan hệ cha con trực tiếp mà câu hỏi nhắm tới. Phương án "Ref" dùng giữ một giá trị không gây render lại hoặc trỏ tới phần tử DOM, không phải kênh truyền dữ liệu từ cha xuống con.
Mở trang câu hỏi này →
AProps are mutable, while state is immutable.
BState is used for passing data between components, while props are used to manage component behavior.
CProps do not change after the initial render, while state can change over time.
DState is used for rendering UI, while props are used for functionality.
Lời giải
Đáp án đúng: "Props do not change after the initial render, while state can change over time.". Props là dữ liệu component cha truyền xuống, component con chỉ đọc chứ không tự sửa; state là dữ liệu nội bộ do chính component quản lý và thay đổi qua setState hoặc hàm set của useState, mỗi lần đổi thì component render lại. Props vẫn có thể nhận giá trị mới khi cha render lại, nhưng đối với component con chúng là bất biến (read-only), nên phát biểu này nắm đúng ý chính của sự khác biệt. "Props are mutable, while state is immutable." đảo ngược: props mới là chỉ đọc, còn state được cập nhật. "State is used for passing data between components, while props are used to manage component behavior." cũng đảo vai, vì truyền dữ liệu giữa các component là việc của props. "State is used for rendering UI, while props are used for functionality." sai vì cả props lẫn state đều được dùng để render giao diện; khác biệt nằm ở ai sở hữu dữ liệu và ai được thay đổi nó.
Mở trang câu hỏi này →
AWhen components require simple, independent state values.
BWhen performing initialization and cleanup actions
CWhen there is complex state logic, several sub-values, or when the upcoming state depends on the previous state
DWhen sharing data across a component hierarchy without prop
Lời giải
Đáp án đúng: "When there is complex state logic, several sub-values, or when the upcoming state depends on the previous state". useReducer gom mọi cách thay đổi state vào một hàm reducer nhận state cùng action và trả về state mới; component chỉ dispatch action mô tả chuyện gì đã xảy ra. Cách này hợp khi state là object có nhiều giá trị con liên quan nhau, khi có nhiều kiểu cập nhật, hoặc khi state kế tiếp tính từ state trước, vì logic nằm tập trung, dễ kiểm thử và tránh các lời gọi set rời rạc làm state mâu thuẫn. "When components require simple, independent state values." là đúng trường hợp nên dùng useState, gọn hơn cho một con số hay một cờ boolean. "When performing initialization and cleanup actions" là việc của useEffect với hàm cleanup trả về. "When sharing data across a component hierarchy without prop" là việc của Context với createContext và useContext, tránh truyền prop qua nhiều tầng.
Mở trang câu hỏi này →
AsetState
BgetState
CupdateState
DmodifyState
Lời giải
Đáp án đúng: "setState". Trong class component, state được cập nhật bằng this.setState: phương thức này gộp đối tượng mới vào state hiện tại rồi lên lịch render lại component; với function component, useState trả về cặp state và hàm cập nhật như setCount, đóng vai trò tương tự, và quy ước đặt tên setX cũng bắt nguồn từ setState. "getState" là phương thức đọc state của Redux store (store.getState()), chỉ đọc chứ không cập nhật state của component. "updateState" không phải API có sẵn của React, chỉ là một tên tự đặt. "modifyState" cũng không tồn tại trong React; sửa thẳng this.state hay biến state mà không qua setState thì React không biết để render lại giao diện.
Mở trang câu hỏi này →
APrevent unnecessary component re-renders
BAutomatically synchronize component state with global state
CGuarantee object references don't change during re-rendering
DSimplify the process of context management
Lời giải
Đáp án đúng gồm hai ý: "Prevent unnecessary component re-renders" và "Guarantee object references don't change during re-rendering". React.memo bọc một component để React bỏ qua việc render lại nó khi các prop không đổi (so nông từng prop), còn useMemo ghi nhớ kết quả tính toán và trả về đúng đối tượng cũ ở các lần render sau chừng nào mảng phụ thuộc chưa đổi, nhờ đó tham chiếu object hay mảng thường giữ nguyên; chữ Guarantee là nói quá, vì tài liệu React coi useMemo chỉ là tối ưu hiệu năng và React có thể bỏ giá trị đã nhớ, nhưng giữ ổn định tham chiếu vẫn là công dụng được tính ở đây; hai thứ thường đi cùng nhau vì nếu mỗi lần render lại tạo object mới để truyền xuống thì React.memo so prop sẽ luôn thấy khác. "Automatically synchronize component state with global state" sai vì cả hai chỉ là công cụ tối ưu hiệu năng, không đồng bộ state với store toàn cục; việc đó thuộc về Redux hay Context. "Simplify the process of context management" sai vì chúng không quản lý Context; một component đã bọc React.memo vẫn render lại khi giá trị Context mà nó đọc thay đổi.
Mở trang câu hỏi này →
A<Route path="/users?id" element={<User />} />
B<Route path="/users/:id" element={<User />} />
C<Route path="/users/{id}" element={<User />} />
D<Route path="/users/#id" element={<User />} />
Lời giải

Đáp án đúng: "<Route path="/users/:id" element={ <User /> } />". Trong React Router v6, một đoạn đường dẫn bắt đầu bằng dấu hai chấm là tham số động (dynamic segment): đường dẫn /users/123 khớp với mẫu này và giá trị 123 được gán cho tham số id; bên trong component User, ta lấy nó bằng hook useParams, nhận object có id là chuỗi "123". "<Route path="/users?id" element={ <User /> } />" sai vì phần sau dấu hỏi là query string, React Router không dùng nó để so khớp đường dẫn, nên mẫu này không bắt được /users/123. "<Route path="/users/{id}" element={ <User /> } />" sai vì cặp ngoặc nhọn là cú pháp tham số của framework khác như ASP.NET, còn React Router coi đây là chữ thường cần khớp nguyên văn. "<Route path="/users/#id" element={ <User /> } />" sai vì dấu thăng mở đầu phần hash của URL, không phải ký hiệu tham số trong path.

Mở trang câu hỏi này →
ARoutes is for styling, and Route is for defining event handlers.
BRoutes is for managing state, and Route is for rendering components.
CRoutes is used to wrap Route components and define the application's routes, while Route is used to define an individual route.
DRoutes is for client-side logic, and Route is for server-side logic
Lời giải
Đáp án đúng: "Routes is used to wrap Route components and define the application's routes, while Route is used to define an individual route.". Trong React Router v6, Routes là vùng chứa bao các Route con: mỗi khi URL đổi, nó xét toàn bộ cây Route bên trong, chọn route khớp nhất và render element của route đó; còn mỗi Route mô tả một tuyến riêng lẻ bằng prop path và prop element (component sẽ hiện), có thể lồng nhau để tạo route con hiển thị qua Outlet. Phương án "Routes is for styling, and Route is for defining event handlers." sai vì cả hai không liên quan tới định kiểu giao diện hay xử lý sự kiện. Phương án "Routes is for managing state, and Route is for rendering components." đúng một nửa ở chỗ Route quyết định component nào hiện, nhưng Routes không phải công cụ quản lý state. Phương án "Routes is for client-side logic, and Route is for server-side logic" sai vì cả hai cùng chạy phía client trong trình duyệt, chúng chia việc theo quan hệ bao chứa chứ không theo client và server.
Mở trang câu hỏi này →
A<Route>
B<Router>
C<Link>
D<Navigation>
Lời giải

Đáp án đúng: "<Route> ". Trong React Router v6, mỗi thẻ Route khai báo một tuyến (route) gồm path là đường dẫn cần khớp và element là component hiển thị khi khớp, các Route được đặt trong Routes để thư viện chọn ra tuyến phù hợp. "<Router> " là bộ định tuyến bao ngoài cung cấp ngữ cảnh lịch sử điều hướng (BrowserRouter, HashRouter là các biến thể của nó); nó cần có nhưng không khai báo tuyến cụ thể nào. "<Link> " tạo liên kết điều hướng tới một đường dẫn mà không tải lại trang; nó dẫn người dùng tới một route chứ không định nghĩa route. "<Navigation> " không phải component của React Router; thư viện có Navigate để chuyển hướng bằng mã và NavLink cho liên kết có trạng thái đang chọn.

Mở trang câu hỏi này →
ATo set up a simple static web server that serves data to clients.
BTo encrypt data during transmission between client and server.
CTo manage client authentication and session data.
DTo provide a full-featured backend for the React application.
Lời giải
Đáp án đúng: "To set up a simple static web server that serves data to clients.". json-server dựng nhanh một server giả lập từ một tệp JSON: mỗi khoá trong tệp thành một endpoint REST, client gọi GET, POST, PUT, DELETE như với backend thật. Nó giúp front-end phát triển và thử luồng giao tiếp client-server khi backend chưa sẵn; dữ liệu nó phục vụ chỉ là nội dung tệp, không có logic nghiệp vụ, nên được xem là một server đơn giản phục vụ dữ liệu. Nói chặt hơn, json-server vẫn ghi thay đổi ngược vào tệp nên không tĩnh tuyệt đối, nhưng đây vẫn là mô tả sát nhất. "To encrypt data during transmission between client and server." là việc của HTTPS và TLS. "To manage client authentication and session data." sai vì json-server không có sẵn đăng nhập hay phiên. "To provide a full-featured backend for the React application." sai vì nó không có phân quyền, kiểm tra dữ liệu hay cơ sở dữ liệu thật, chỉ dùng cho phát triển và thử nghiệm.
Mở trang câu hỏi này →
Aconst MyComponent = () => { const dispatch = useDispatch(); return <div>My Component</div>; };
Bconst MyComponent = () => { const dispatch = useDispatch; return <div>My Component</div>; };
Cconst MyComponent = () => { const dispatch = dispatch(); return <div>My Component</div>; };
Dconst MyComponent = () => { const dispatch = useDispatch(); return <div>My Component with {dispatch}</div>; };
Lời giải

Đáp án đúng: "const MyComponent = () => { const dispatch = useDispatch(); return <div>My Component</div>; };". useDispatch là hook của React Redux, phải GỌI nó ở cấp cao nhất của function component để nhận về hàm dispatch của store, sau đó dùng dispatch(action) trong các hàm xử lý sự kiện để gửi action tới reducer. Phương án viết "dispatch = useDispatch;" thiếu cặp ngoặc gọi hàm, nên biến dispatch chỉ giữ chính hàm hook chứ không phải hàm dispatch của store, gọi dispatch(action) về sau là gọi hook sai chỗ. Phương án viết "const dispatch = dispatch()" gọi một biến ngay trong câu khai báo chính nó; hằng const còn ở vùng chết tạm thời (temporal dead zone) nên ném ReferenceError, và cũng không hề dùng useDispatch. Phương án hiển thị "My Component with {dispatch}" lấy được dispatch đúng cách nhưng lại nhúng một hàm vào JSX làm nội dung con; React không render được hàm và sẽ cảnh báo, nên đó không phải cách dùng useDispatch đúng.

Mở trang câu hỏi này →
A{ "name": "John Doe", "age": 30, "city": "New York" }
B{ 'name': 'John Doe', 'age': "30", 'city': 'New York' }
C{ name: "John Doe", age: 30, city: "New York" }
D{ "name" = "John Doe", "age" = 30, "city" = "New York" }
Lời giải
Đáp án đúng: "{ "name": "John Doe", "age": 30, "city": "New York" }". JSON có cú pháp chặt hơn đối tượng JavaScript: mọi khoá phải là chuỗi đặt trong nháy kép, chuỗi giá trị cũng dùng nháy kép, khoá và giá trị ngăn bằng dấu hai chấm, các cặp ngăn bằng dấu phẩy; số như 30 để trần. Phương án đúng thoả đủ các điều đó nên JSON.parse đọc được. "{ 'name': 'John Doe', 'age': "30", 'city': 'New York' }" sai vì JSON không chấp nhận nháy đơn cho khoá hay chuỗi; riêng age thành chuỗi "30" thì hợp lệ nhưng nháy đơn đã đủ làm hỏng. "{ name: "John Doe", age: 30, city: "New York" }" là cú pháp đối tượng JavaScript hợp lệ, nhưng không phải JSON vì khoá không nằm trong nháy kép. "{ "name" = "John Doe", "age" = 30, "city" = "New York" }" sai vì JSON dùng dấu hai chấm giữa khoá và giá trị, dấu bằng không có nghĩa gì trong JSON.
Mở trang câu hỏi này →
ASOAP (Simple Object Access Protocol)
BRPC (Remote Procedure Call)
CMVC (Model-View-Controller)
DRESTful (Representational State Transfer)
Lời giải
Đáp án đúng: "RESTful (Representational State Transfer)". REST là phong cách kiến trúc do Roy Fielding mô tả cho dịch vụ web: mọi thứ là tài nguyên định danh bằng URL, thao tác qua các phương thức HTTP chuẩn như GET, POST, PUT, DELETE, giao tiếp không lưu trạng thái (stateless) và thường trao đổi dữ liệu dạng JSON; dịch vụ tuân theo các nguyên tắc đó được gọi là RESTful. "SOAP (Simple Object Access Protocol)" sai vì SOAP là một giao thức riêng, gói thông điệp trong phong bì XML và mô tả dịch vụ bằng WSDL, là cách tiếp cận khác hẳn REST. "RPC (Remote Procedure Call)" sai vì RPC xoay quanh việc gọi thủ tục, tức hướng hành động, còn REST hướng tài nguyên. "MVC (Model-View-Controller)" sai vì đó là mẫu thiết kế tổ chức mã bên trong một ứng dụng, tách dữ liệu, giao diện và điều khiển, không phải phong cách thiết kế giao tiếp giữa các dịch vụ web.
Mở trang câu hỏi này →