Fetch가 Wait Twice를 요구하는 이유 이해하기✨

JavaScript의 fetch API는 HTTP 요청을 만드는 데 널리 사용되지만 때로는 두 개의 wait 문이 필요한 이유를 이해하기가 약간 까다로울 수 있습니다. 이전에 가져오기 작업을 해본 적이 있다면 다음과 같은 코드를 접했을 수도 있습니다.

const response = await fetch('https://api.example.com/data');
const data = await response.json();

이를 분석하여 이 패턴이 필요한 이유를 이해해 보겠습니다. ?

가져오기의 2단계 프로세스 ?️

가져오기 API는 네트워크 요청을 비동기식으로 처리하도록 설계되었지만 동작은 두 가지 주요 단계로 나뉩니다.

1. 응답 가져오는 중 ?

   • fetch를 호출하면 네트워크 요청이 완료되면 Response 객체로 확인되는 Promise가 반환됩니다.
   • 이 단계에서는 응답 본문을 처리하지 않습니다. 요청이 성공했고 헤더를 사용할 수 있는지만 확인합니다.

2. 응답 본문 읽기 ?

   • Response 객체에는 실제 콘텐츠를 읽기 위한 .json(), .text(), .blob() 등의 메서드가 있습니다.
   • 본문 읽기가 비동기식이므로 이 메소드는 Promise도 반환합니다. 이는 메인 스레드를 차단하지 않고 대규모 페이로드를 효율적으로 처리하는 데 필요합니다.

첫 번째 대기 중에 무슨 일이 발생합니까? ⏳

const response = wait fetch(url);를 작성하면 다음과 같은 일이 발생합니다.

1. 네트워크 요청 전송됨: ?

   • 브라우저가 지정된 URL에 대한 HTTP 요청을 시작합니다.
   • 여기에는 도메인 이름 확인, TCP 연결 설정, HTTP 헤더 및 본문 전송(POST 요청용)이 포함됩니다.

2. 수신된 응답 메타데이터: ?

   • 가져오기 호출은 서버가 상태 줄(예: HTTP/1.1 200 OK)과 헤더로 응답하면 해결됩니다. 이 시점에서:
     • 상태(예: 200, 404, 500) 및 상태 텍스트(예: "OK" 또는 "Not Found")를 사용할 수 있습니다.
     • Content-Type, Content-Length와 같은 응답 헤더 및 서버에서 보낸 모든 사용자 정의 헤더에 액세스할 수 있습니다.

3. 생성된 응답 개체: ?️

   • 브라우저는 응답에 대한 메타데이터가 포함된 응답 개체를 구성합니다. 여기에는 다음이 포함됩니다.
     • 헤더: response.headers를 통해 액세스할 수 있으며 이를 통해 Content-Type 또는 Authorization과 같은 특정 헤더를 검사할 수 있습니다.
     • 본문: 이 시점에서는 본문이 완전히 읽혀지거나 구문 분석되지 않았으며 읽을 수 있는 스트림으로 유지됩니다.

예를 들어 서버가 다음을 반환하는 경우:

   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Length: 123

   {"message": "Hello, world!"}

응답 개체에는 다음이 포함됩니다.

• 상태: 200 ✅
• statusText: "확인" ✅
• 헤더: 응답 헤더의 반복 가능한 컬렉션입니다(예: Content-Type: application/json).
• body: 아직 구문 분석되지 않은 읽기 가능한 스트림입니다.

두 번째 기다림 동안 무슨 일이 일어날까요? ?

const data = wait response.json();을 작성하면 다음 단계가 발생합니다.

1. 본문 스트림 읽기: ?

   • 응답 본문(아직 원시 형식)은 스트림으로 읽혀집니다. 사용하는 방법에 따라 원시 데이터가 그에 따라 처리됩니다.
     • .json(): 스트림을 JSON으로 구문 분석하고 JavaScript 개체를 반환합니다.
     • .text(): 스트림을 일반 텍스트 문자열로 읽습니다.
     • .blob(): 스트림을 바이너리 대형 객체로 읽습니다.

2. 구문 분석 및 해결: ?

   • json() 메소드는 원시 데이터(예: {"message": "Hello, world!"})를 사용 가능한 JavaScript 객체(예: { message: "Hello, world!" })로 구문 분석합니다.
   • 이 구문 분석 프로세스는 잠재적으로 큰 데이터를 처리하기 때문에 비동기식입니다.

3. 다짐 약속: ✅

   • response.json()에서 반환된 Promise는 구문 분석된 데이터로 확인되어 애플리케이션에서 사용할 수 있습니다.

두 개의 wait 문이 필요한 이유는 무엇입니까?

두 번 기다려야 하는 이유는 다음과 같습니다.

1. 첫 번째 대기(응답을 기다리는 중):

   • 가져오기 호출은 응답 데이터를 즉시 제공하지 않습니다. 그것은 당신에게 약속을 줍니다. Response 객체를 얻으려면 기다려야 합니다.

2. 두 번째 대기(본문 구문 분석):

   • .json() 메서드(또는 기타 본문 읽기 메서드)는 또 다른 Promise를 반환합니다. 구문 분석된 콘텐츠를 추출하려면 이를 기다려야 합니다.

대기 중 하나를 건너뛰면 예상치 못한 동작이 발생할 가능성이 높습니다.

• 첫 번째 대기 건너뛰기: 실제 Response 객체 대신 해결되지 않은 Promise로 작업하게 됩니다.
• 두 번째 wait 건너뛰기: 구문 분석된 데이터 대신 Promise를 받게 됩니다.

오류 처리의 예 ?️

가져오기 작업 중 오류를 올바르게 처리하는 방법은 다음과 같습니다.

const response = await fetch('https://api.example.com/data');
const data = await response.json();

일반적인 함정 ⚠️

1. 오류 처리 안함:

   • fetch는 404 또는 500과 같은 HTTP 오류에 대해 오류를 발생시키지 않습니다. response.ok 또는 response.status를 수동으로 확인해야 합니다.

2. 두 번째 기다림 건너뛰기:

   • await .json()을 잊어버리면 실제 데이터 대신 Promise로 작업하는 경우 버그가 발생할 수 있습니다.

3. 가져오기 API와 이전 API 간의 혼동:

   • XMLHttpRequest와 같은 이전 API에서 전환하는 개발자는 동기식 동작을 기대할 수 있지만 가져오기는 전적으로 Promise 기반입니다.

결론 ?

가져오기와 함께 두 개의 wait 문을 사용하는 것은 처음에는 중복된 것처럼 보일 수 있지만 이는 비동기식 설계의 논리적 결과입니다. 첫 번째 대기는 헤더와 메타데이터를 포함하여 응답이 수신되었는지 확인하고, 두 번째 대기는 응답 본문을 처리합니다. 이 흐름을 이해하면 보다 안정적이고 유지 관리가 쉬운 비동기 코드를 작성하는 데 도움이 됩니다. ?

위 내용은 Fetch가 Wait Twice를 요구하는 이유 이해하기✨의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!