JavaScript 콜백의 제어 역전: 약속이 답인 이유

콜백 함수는 다른 함수에 인수로 전달된 함수이며, 이 함수는 일종의 루틴이나 작업을 완료하기 위해 외부 함수 내에서 호출됩니다. 콜백을 호출하는 방법에는 동기식과 비동기식의 두 가지가 있습니다. 자바스크립트의 가장 기본적인 비동기 패턴입니다.

예:

A 및 B는 이제 기본 JS 프로그램의 직접 제어 하에 발생합니다. 그러나 C는 나중에 발생하도록 연기되고 다른 당사자(이 경우 ajax(..) 함수)의 제어를 받습니다. 기본적으로 이러한 종류의 제어권 이양은 프로그램에 정기적으로 많은 문제를 일으키지 않습니다.

그러나 빈도가 낮다고 해서 문제나 이슈를 무시할 수는 없습니다. 사실 이는 콜백 중심 디자인의 주요 문제 중 하나입니다. 이는 때때로 ajax(..) 또는 콜백 연속성을 전달하는 "파티"가 사용자가 작성한 함수가 아니거나 직접 제어하는 ​​함수가 아니라는 아이디어를 중심으로 전개됩니다. 많은 경우 타사에서 제공하는 유틸리티입니다.

귀하가 프로그램에 참여하고 프로그램 실행에 대한 통제권을 다른 제3자에게 넘겨주는 것을 “통제권 역전”이라고 합니다. 귀하의 코드와 타사 유틸리티 사이에 존재하는 암묵적인 "계약"이 있습니다. 이는 귀하가 유지해야 하는 일련의 사항입니다.

“통제 역전”의 문제점은 무엇입니까?

이 문제를 더 잘 이해하기 위한 예가 있습니다.

회사를 위한 여행 예약 웹사이트를 구축한다고 가정해 보겠습니다. 타사 라이브러리의 createBooking() 함수를 사용하는 '지금 예약' 버튼을 추가했습니다. 이 기능은 예약을 처리한 후 콜백을 호출하여 고객에게 확인 이메일을 보냅니다.

이 코드는 다음과 같습니다.

테스트 중에는 모든 것이 완벽하게 작동합니다. 사람들은 귀하의 웹사이트에서 여행 패키지를 예약하기 시작하고 모두가 귀하의 작업에 만족합니다. 어느 날 갑자기 상사로부터 중요한 문제에 관한 전화를 받았습니다. 고객이 패키지를 예약했고 한 예약에 대해 4개의 동일한 확인 이메일을 받았습니다.

문제 디버깅을 시작합니다. 확인 이메일을 보내는 코드 부분을 검토한 결과 모든 것이 올바른 것 같습니다. 그런 다음 추가 조사를 통해 타사 라이브러리의 createBooking() 유틸리티가 콜백 함수를 4번 호출하여 4번의 확인 이메일이 전송되었음을 확인했습니다.

타사 도서관 지원팀에 연락해 상황을 설명합니다. 그들은 이전에 이 문제를 겪은 적이 없지만 우선순위를 정하여 다시 연락할 것이라고 말합니다. 하루가 지나면 그들은 결과를 가지고 당신에게 다시 전화합니다. 그들은 라이브로 진행되어서는 안되는 실험적인 코드 조각으로 인해 createBooking() 함수가 콜백을 여러 번 호출하게 된 것을 발견했습니다.

문제는 해당 업체 측에 있었고 해당 업체에서는 문제가 해결되었음을 확인했습니다. 불편을 끼쳐드린 점 사과드리며, 앞으로는 이런 문제가 발생하지 않을 것임을 확인하였습니다.

솔루션을 찾은 후 이와 같은 원치 않는 문제를 방지하려면 다음과 같은 간단한 if 문을 구현합니다. 팀에서는 이에 만족해 보입니다.

그런데 QA 엔지니어 중 한 명이 "콜백을 호출하지 않으면 어떻게 되나요?"라고 묻습니다. 이런. 두 분 모두 그런 생각은 하지 못하셨을 텐데요!

콜백을 호출할 때 발생할 수 있는 모든 문제에 대해 생각하기 시작합니다. 다음은 몇 가지 문제 목록입니다.

• 콜백을 너무 일찍 호출

• 콜백을 너무 늦게 호출하거나 호출하지 않음

• 콜백을 너무 적게 또는 너무 많이 호출합니다(위 예의 문제와 같습니다)

• 발생할 수 있는 오류/예외를 삼가세요

• ...

다양한 상황에 맞게 코드에 많은 솔루션을 구현해야 한다는 점을 깨닫게 될 것입니다. 이렇게 하면 유틸리티에 전달되는 모든 단일 콜백에 필요하기 때문에 코드가 끔찍하고 지저분해집니다.

약속

제어 반전을 되돌릴 수 있다면 어떨까요? 프로그램의 연속성을 다른 당사자에게 전달하는 대신 작업이 언제 완료되는지 알 수 있는 기능을 반환하고 코드가 다음에 수행할 작업을 결정할 수 있다고 기대할 수 있다면 어떨까요?

Promise는 JavaScript에서 비동기 작업을 처리하는 강력한 방법을 제공하여 콜백 지옥 및 제어 반전과 같은 문제를 해결합니다. 콜백과 달리 Promises를 사용하면 코드 제어권을 포기하지 않고 비동기 작업을 관리할 수 있습니다.

패스트푸드 레스토랑에서 치즈버거를 주문해 보세요. 당신은 미래의 치즈버거에 대한 약속인 영수증을 받습니다. 기다리는 동안 결국 주문을 받게 될 것이라는 것을 알고 다른 작업을 할 수 있습니다. 마찬가지로 JavaScript의 Promise는 미래의 가치를 나타내며 코드가 원활하게 진행될 수 있도록 해줍니다.

레스토랑에 치즈버거가 떨어지면 알림을 받을 수 있는 것처럼 Promise도 실패를 우아하게 처리합니다. 이 구조를 사용하면 코드를 더 쉽게 읽을 수 있고 유지 관리할 수 있습니다.

여기서 Promise에 대해 자세히 다루지는 않겠지만 Promise를 사용하면 더욱 깔끔하고 안정적인 비동기 코드를 작성하여 JavaScript 애플리케이션의 전반적인 품질을 향상시킬 수 있습니다.

예를 들어 앞서 설명한 여행 예약 웹사이트의 경우 타사 유틸리티가 약속을 반환하면 다음과 같이 처리할 수 있습니다.

Promise가 일단 해결되면(성공적으로 완료되면) 영원히 그 상태로 유지됩니다. 그 시점에서는 불변의 값이 되며 필요한 만큼 여러 번 관찰할 수 있습니다. 이는 해결된 Promise를 의미하며, 해결된 값은 상태에 영향을 주지 않고 코드에서 여러 번 액세스하거나 사용할 수 있습니다. 이를 통해 Promise 변경이나 재평가에 대한 걱정 없이 애플리케이션의 다양한 부분에서 비동기 작업 결과를 처리할 수 있습니다.

프라미스는 콜백 전용 코드에서 발생하는 제어 반전 문제에 대한 솔루션입니다. 콜백은 제어의 반전을 나타냅니다. 따라서 콜백 패턴을 반전시키는 것은 실제로 반전의 반전 또는 제어의 반전입니다. 처음에 원했던 호출 코드로 제어권을 다시 복원합니다.

참고자료

• You Don't Know JS: 비동기 및 성능 - Kyle Simpson

• developer.mozilla.org

위 내용은 JavaScript 콜백의 제어 역전: 약속이 답인 이유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!