Feature Probes and Functional Fallbacks

Working case

An inspector exports case 47 after reviewing it. A plain server endpoint returns a download. On devices with a suitable file picker, the app offers Save to folder. One build checks that the picker function exists and then replaces the download button. The picker is present but the user cancels it, the permission is denied, or a managed web view blocks it. The export disappears. The right boundary keeps the server download as the ordinary path and treats direct file saving as an optional branch with an explicit return path.

Implementation boundary

function exportActions(capabilities) {
  return capabilities.filePicker ? ['server-download', 'save-to-folder'] : ['server-download'];
}
console.log(exportActions({ filePicker: false }).join(','));
// Output: server-download

Probe the exact API at the point of use and handle exceptions from invocation separately. Keep the server export authorization, content type, and filename policy independent of the browser branch. A probe for one method cannot establish support for the entire workflow: writing, closing, and error recovery may fail later. When the capability needs user activation, invoke it in the direct interaction path rather than after an unrelated asynchronous delay. Make cancellation a distinct user choice and do not label it as an application error. If an enhancement is security-sensitive, keep its fallback aligned with the same server permission checks.

Cost and boundaries

A capability probe is O(1); the expensive work is implementing and maintaining two task paths. A server export consumes network bytes and may duplicate a client-side save, but it preserves completion across browsers. A failed picker can leave a partial file, so write to a temporary destination where the API permits and communicate completion only after close succeeds. Track attempted and completed exports by path without logging private filenames. A fallback that is never exercised in release tests will rot even if its code remains present.

Failure trace

Run with the file picker missing, then present but throwing, then present but canceled. In each state, the authorized server download must remain available. Simulate a failed stream close after several chunks; the UI must not show a successful export. Change the account during export and reject the old response. Disable JavaScript and verify the normal link still starts the server path. On a touch device, make sure the optional picker is invoked from a direct gesture. Check keyboard focus after each cancellation and error.

Verification

The baseline export works without script.
Picker cancellation leaves a completion path.
A partial write never produces a success state.

Practice drill

Implement a case export button with a normal server link and a separate Save to folder action only when a probe succeeds. Use a 47-record export with a generated revision ID. Test capability absence, user cancellation, storage denial, network interruption, and a completed file. Record which path actually finished, not which path was merely offered. Keep the server endpoint as the authority for record scope on both paths.

Decision note

A capability probe selects an enhancement; it does not replace the baseline task or prove later operations will succeed.

Common Mistakes

Replacing the baseline link when an API exists.
Treating a user cancellation as successful export.
Using a browser-name string as a permission check.

Connected practice

Build Project: progressive case export release and review Web Development: components and compatibility quiz.