Promise.all( ) 困境：什麼時候有用，什麼時候有害

在現代 JavaScript 開發中，處理非同步操作是一項常見任務。無論是發出 API 請求、查詢資料庫或讀取文件，使用非同步程式碼幾乎是不可避免的。開發人員遇到的常見工具之一是 Promise.all()。然而，我們中的許多人，包括我自己，可能會陷入嘗試使用 Promise.all() 的陷阱，只是因為它在那裡，而沒有真正理解它是否是我們特定用例的最佳解決方案。

1. 跟隨 Promise.all() 潮流

作為開發人員，很容易遇到新功能或工具，並認為它們應該在任何地方實現。我發現自己在 Promise.all() 中處於這種情況。在閱讀了它如何並行運行多個 Promise 並等待所有 Promise 完成後再繼續後，我渴望將其整合到我的程式碼中。在沒有完全理解是否有必要的情況下，我就跟風並儘可能地應用它。

很容易認為，既然它是一個強大的工具，它一定比更簡單的替代品更好。但我很快意識到，盲目應用 Promise.all() 而不考慮上下文並不總是能帶來最高效或可讀的程式碼。

2. 非同步 JavaScript 基礎知識

在我們深入探討 Promise.all() 何時有用之前，讓我們先看看非同步函數在 JavaScript 中是如何運作的。當您編寫非同步函數並使用await時，JavaScript允許該操作發生，而不會阻塞其餘程式碼。這意味著您可以啟動一項操作，然後在等待結果的同時繼續執行其他操作。

但是，如果您不小心，當操作可以獨立運行時，您最終可能會導致操作不必要地相互依賴。我發現自己處於 Promise.all() 的這種情況，認為並行運行所有非同步函數總是一個好主意。

範例：非同步函數的順序執行

const fetchData = async () => {
  const data1 = await getChart();   // Request #1
  const data2 = await getDetails(); // Request #2
};

即使在程式碼中 data1 和 data2 被依序獲取，瀏覽器仍然異步且幾乎同時發起這兩個請求。事實上，當我檢查“網路”選項卡時，我看到兩個請求大約在同一時間開始。這讓我意識到 JavaScript 已經可以並行處理事情了，而 Promise.all() 並不是必需的。

3.什麼時候應該使用Promise.all()？

儘管我最初急於在任何地方使用 Promise.all()，但在某些情況下它確實會大放異彩。當您需要等待多個非同步操作完成才能繼續操作時，它特別有用。

為什麼要用 Promise.all()？

1. 等待所有 Promise：如果多個非同步任務的結果相互依賴，或需要所有非同步任務完成才能繼續，Promise.all() 是理想的選擇。
2. 錯誤處理：Promise.all() 快速失敗－這意味著如果任何 Promise 失敗，整個操作都會被拒絕。當您想要確保一切都成功或沒有任何進展時，這會很有用。
3. 組合結果：如果您需要一次獲得所有 Promise 的結果（例如，將使用者資料與購買歷史記錄結合），Promise.all() 是完美的解決方案。

範例：使用 Promise.all()

const fetchData = async () => {
  const [data1, data2] = await Promise.all([getChart(), getDetails()]);
  console.log('Both requests completed'); // This runs only when both requests finish
};

在此範例中，getChart() 和 getDetails() 並行運行，並且函數會等到兩者都完成後再繼續。 Promise.all() 在這種兩個請求相關且需要一起完成的情況下非常完美。

4. 為什麼我不需要 Promise.all()

應用 Promise.all() 幾次後，我開始注意到它並不總是能讓我的程式碼變得更好。事實上，我把事情過於複雜化了。我有兩個獨立的 API 請求 — getChart() 和 getDetails() — 每個請求都有自己的載入微調器和結果，但我不必要地將它們捆綁在一起。

透過使用 Promise.all()，我強製程式碼在處理任一結果之前等待兩個請求完成，即使這些請求是獨立的並且不相互依賴。在這種情況下，Promise.all() 只會增加複雜性，而沒有任何實際好處。

5. When Promise.all() Might Be Overkill

Sometimes, Promise.all() is overkill. If your async functions are independent, meaning one doesn’t rely on the other to complete, then there’s no need to bundle them together. They can run in parallel just fine without waiting on each other, and you can handle their results independently. This realization hit me when I saw that JavaScript already handles asynchronous tasks efficiently without needing to group everything together.

When to Avoid Promise.all()

1. Independent Async Functions: If your requests don’t depend on each other, they can complete at different times, and you can handle their results separately. There’s no need to wait for all of them to finish together.
2. Individual Loading States: In my case, I had individual loading spinners for each request, but I was unnecessarily holding everything up by waiting for both requests. It’s better to handle each request separately and update the UI as soon as each one finishes.

Example: Independent Requests Without Promise.all()

useEffect(() => {
  getChart();   // Trigger first async request
  getDetails(); // Trigger second async request
}, []);

In this setup, both requests run in parallel without needing Promise.all(). You can show individual loading states and handle each result independently, which is exactly what I needed for my project.

6. Real-World Scenarios for Using or Avoiding Promise.all()

Let’s look at how these concepts apply to real-world scenarios.

Scenario 1: Fetching Related Data (Use Promise.all())

Imagine you’re building a dashboard where you need to show user information and user purchase history together. In this case, you’d want to wait for both pieces of information to load before rendering the UI. Here, Promise.all() is the right choice:

const fetchData = async () => {
  const [userInfo, purchaseHistory] = await Promise.all([
    fetchUserInfo(),
    fetchUserPurchaseHistory()
  ]);
  console.log('Both user info and purchase history loaded');
};

Scenario 2: Independent API Calls (Avoid Promise.all())

Now, let’s say you’re fetching chart data and table data for a dashboard, and these two pieces of information are independent of each other. You might want to show a spinner for the chart and a separate one for the table. In this case, there’s no need to wait for both requests to complete together:

useEffect(() => {
  getChart();   // Fire chart request
  getDetails(); // Fire table request
}, []);

Both requests are independent, and you handle each of them separately, updating the UI as soon as each one completes. Promise.all() isn’t necessary here.

Conclusion: Don’t Jump on the Bandwagon

Promise.all() is a powerful tool, but it’s not always the best solution. I jumped on the bandwagon initially, assuming that using it everywhere would make my code better. However, I quickly learned that in cases where async functions are independent and have their own loading states, Promise.all() can actually make things more complicated.

Key Takeaways:

• Use Promise.all() when you need to wait for multiple promises to resolve before proceeding.
• Avoid Promise.all() when async tasks are independent, and you can handle them individually without unnecessary waiting.

Ultimately, it’s important to understand when and why to use a feature like Promise.all() instead of just assuming it’s always beneficial. After stepping back and re-evaluating my use case, I found that sticking with independent async calls was the right approach.

以上是Promise.all( ) 困境：什麼時候有用，什麼時候有害的詳細內容。更多資訊請關注PHP中文網其他相關文章！