[Suggestion]: Wrong example in fetching data section on You Might not need a Effect Page
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- JavaScript
- Star
- 11.8k
- Fork
- 7.9k
- Merge trung bình
- 1 ngày 11 giờ
- Pull request đã merge (30 ngày)
- 11
Mô tả
Summary
In the Fetching Data Section of You might not need an effect is solving for different scenario with different problem altogether which will a create a confusion whether it requires a effect or not
Page
https://react.dev/learn/you-might-not-need-an-effect#fetching-data
Details
The Fetching Data Section of You might not need an effect is solving a different scenario with a different problem altogether.
In this code block:
function SearchResults({ query }) {
const [results, setResults] = useState([]);
const [page, setPage] = useState(1);
useEffect(() => {
// 🔴 Avoid: Fetching without cleanup logic
fetchResults(query, page).then(json => {
setResults(json);
});
}, [query, page]);
function handleNextPageClick() {
setPage(page + 1);
}
// ...
}
The documentation mentions that:
This might seem like a contradiction with the earlier examples where you needed to put the logic into the event handlers! However, consider that it's not the typing event that's the main reason to fetch. Search inputs are often prepopulated from the URL, and the user might navigate Back and Forward without touching the input.
It doesn't matter where page and query come from. While this component is visible, you want to keep results synchronized with data from the network for the current page and query. This is why it's an Effect.
This encourages people to add page as a dependency in the useEffect and also categorize the page change event as an effect altogether. But page changes are user events (wrt to the context like the results are shown in a table), and the documentation should encourage people to fetch data inside the change handler rather than using an effect (similar to how we encourage handling POST request on a form).
Regarding the URL scenario: let's say the user goes to page 3, navigates to a different page, and comes back again. The URL page param should be read inside the effect callback like this:
function SearchResults({ query }) {
const [results, setResults] = useState([]);
const [page, setPage] = useState(new URLSearchParams(window.location.search).get("page"));
useEffect(() => {
const urlSearchParams = new URLSearchParams(window.location.search);
const currentPage = urlSearchParams.get("page");
fetchResults(query, currentPage).then(json => {
setResults(json);
});
}, [query]);
function handleNextPageClick() {
setPage(page + 1);
fetchResults(query, page + 1).then(json => {
setResults(json);
});
}
// ...
}
This way, page can be removed as a dependency altogether, and the effect only runs whenever the query changes while always getting the latest page param value. When the page is changed by the user, the fetch should be invoked inside handleNextPageClick since page change is an event.
The earlier example will result in more confusion, and people will add things that should be inside the event handler into the effect with dependencies, making Event handlers sharing logic obsolete too. This also make the people aware on avoiding the "setState triggers effect" pattern for user events and follows the same principle on removing effects and using events properly as the article intended.
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu với phần Fetching Data của trang You Might Not Need an Effect và so sánh ví dụ trong đó với hướng dẫn xung quanh về event handler và việc chia sẻ logic. Xem lại các kịch bản URL và phân trang được đề xuất, sau đó chỉ cập nhật tài liệu nếu phần giải thích nhất quán phân biệt sự kiện do người dùng với việc đồng bộ hóa; hoàn thành khi ví dụ và phần văn bản xung quanh không còn đưa ra lời khuyên mâu thuẫn.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- javascript, react
- Lĩnh vực
- documentation
- Loại issue
- Tài liệu
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Ít trao đổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 48/100