Handle partial failures in optional widgets with Promise.allSettled()

Use Promise.allSettled() for independent optional widgets so one failed request does not hide the other widgets' successful results.

A hackathon dashboard might show a required project result plus optional weather and resource cards. Decide which pieces the user needs to finish the task. An unavailable optional card should have its own failure state, while the required result should follow its own loading and failure contract.

Keep independent outcomes separate

MDN documents Promise.allSettled() as waiting for all input promises to settle and returning their outcomes in input order. Each outcome has either a fulfilled value or a rejection reason. Completion order does not change which slot belongs to which request.

const widgets = [
  { name: 'resources', task: Promise.resolve(['Guide']) },
  { name: 'weather', task: Promise.reject(new Error('Unavailable')) }
];

const outcomes = await Promise.allSettled(widgets.map(w => w.task));
for (const [index, outcome] of outcomes.entries()) {
  const name = widgets[index].name;
  if (outcome.status === 'fulfilled') {
    console.log(name, outcome.value);
  } else {
    console.log(name, 'Could not load this optional widget.');
  }
}

These tasks are deterministic fixtures, not calls to an actual weather service. Replace the console output with a separate UI update for each named widget. Keep the name mapping beside the request list so later edits cannot swap two results accidentally.

Make real requests reject when appropriate

When replacing the fixture with fetch(), inspect response.ok before parsing. MDN's Fetch guide explains why an HTTP error can otherwise appear as a fulfilled response. allSettled() classifies promise outcomes; it does not decide whether an HTTP response meets your application's success contract.

It also does not provide a timeout or cancel requests. A request that remains pending keeps the combined wait pending. Design request cancellation and time limits explicitly for the real services you use. If widgets need to appear as soon as each completes, update them individually instead of waiting for the entire group to finish.

Test partial availability

Rehearse both successful widgets, each single failure, and both failures. Confirm that a failed card names its own problem and that successful content remains visible. Add one deliberately slow fixture to see whether the loading state matches your intended experience.

Keep a required submission request outside this optional-widget group when its failure must stop the workflow. Write that dependency in the README. For planning a rehearsal, the English Stavleak organizer toolkit offers checklists and templates that you can adapt to your event.