동기 XMLHttpRequest를 사용하는 이유가 있습니까?

대부분의 모든 사람이 XMLHttpRequest를 사용하여 비동기 요청을 수행하는 것처럼 보이지만 동기 요청을 수행 할 수있는 기능이 있다는 사실은이를 수행 할 유효한 이유가있을 수 있음을 나타냅니다. 그렇다면 그 타당한 이유는 무엇일까요?

HTML 5 표준이 진행됨에 따라 더 인기가있을 것이라고 생각합니다. 웹 애플리케이션에 웹 워커에 대한 액세스 권한이 부여되면 Jonathan이 말했듯이 특정 요청이 다른 요청보다 먼저 발생하도록하기 위해 전용 웹 워커를 사용하는 개발자가 동기식 요청을 할 수 있습니다. 한 스레드의 현재 상황에서는 요청이 완료 될 때까지 차단되므로 이상적인 설계가 아닙니다.

동기식 XHR은 사용자 데이터를 저장하는 데 유용합니다. beforeunload이벤트 를 처리하면 사용자가 페이지를 닫을 때 데이터를 서버에 업로드 할 수 있습니다.

비동기 옵션을 사용하여이 작업을 수행 한 경우 요청이 완료되기 전에 페이지가 닫힐 수 있습니다. 이를 동 기적으로 수행하면 요청이 예상대로 완료되거나 실패합니다.

최신 정보:

아래는 더 나은 비동기 요청 처리의 출현으로 요청이 완료 될 때까지 사용자가 어떤 작업을 수행하지 못하도록 의도적으로 차단하지 않는 한 동기 요청을 사용할 이유가 없다는 것을 암시했지만 전달에 실패했습니다. )

이것은 나쁘게 들릴 수 있지만, 사용자가 페이지를 떠나기 전 또는 작업이 수행되기 전에 요청 (또는 일련의 요청)이 발생하는 것이 중요한 경우가 있습니다. 다른 코드 실행을 차단 (예 : 뒤로 버튼 방지) 할 수 있습니다. 잘못 설계된 시스템에 대한 오류 / 유지 보수를 줄일 수 있습니다 . 즉, 나는 그것을 야생 에서 본 적이 없으며 피해야한다는 것을 강조합니다.

promise 와 같은 라이브러리 는 콜백을 통해 프로세스를 연결하여 동시성을 가장합니다. 이는 브라우저가 사용자에 대한 응답 성을 유지할 수 있도록하는 비 차단 이벤트 (좋은 UX)를 주문하려는 대부분의 개발 요구 사항에 적합합니다.

마찬가지로 모질라 문서에 명시된 가 동기식 요청을 사용해야 할 경우가 있습니다; 그러나 이러한 경우에 비콘 (IE / Safari에서는 사용할 수 없음) 을 사용하는 해결 방법도 나열되어 있습니다. 이것은 실험적이지만 표준 수용에 도달하면 동기 요청 관에 못을 박을 수 있습니다.

모든 종류의 트랜잭션과 같은 처리에서 또는 작업 순서가 필요한 모든 곳에서 동기 호출을 수행하고 싶을 것입니다.

예를 들어, 노래를 재생 한 후 로그 아웃하도록 이벤트를 사용자 정의하고 싶다고 가정 해 보겠습니다. 로그 아웃 작업이 먼저 발생하면 노래가 재생되지 않습니다. 이를 위해서는 요청 동기화가 필요합니다.

또 다른 이유는 WebService로 작업 할 때 특히 서버에서 수학을 수행 할 때입니다.

예 : 서버에 값이 1 인 변수가 있습니다.

 Step (1) Perform Update: add 1 to variable
 Step (2) Perform Update: set variable to the power of 3
 End Value: variable equals 8

단계 (2)가 먼저 발생하면 종료 값은 8이 아니라 2입니다. 따라서 작업 순서와 동기화가 필요합니다.

일반적인 실제 예에서 동기 호출이 정당화되는 경우는 거의 없습니다. 로그인을 클릭 한 다음 사용자가 로그인해야하는 사이트 부분을 클릭하는 경우 일 수 있습니다.

다른 사람들이 말했듯이 브라우저를 묶을 수 있으므로 가능한 한 멀리 떨어져 있습니다.

하지만 동기 호출 대신에 사용자는 현재로드중인 이벤트를 중지 한 다음 다른 작업을 수행하기를 원합니다. 두 번째 이벤트가 시작되기 전에 첫 번째 이벤트가 종료되기 때문에 이것은 동기화입니다. 이렇게하려면 xml 연결 개체에서 abort () 메서드를 사용합니다.

요청이 허용되는 동안 사용자의 브라우저를 차단하는 것을 고려한다면 반드시 동기 요청을 사용하십시오.

요청 직렬화가 목표 인 경우 비동기 요청을 사용하여 이전 요청의 onComplete 콜백이 다음 줄에서 실행되도록 할 수 있습니다.

UI 차단이 정확히 원하는 동작 인 실제 사례가 많이 있습니다.

여러 필드가있는 앱을 가져오고 일부 필드는이 필드의 값과 기타 필드 값을 입력으로 제공하는 원격 서버에 대한 xmlhttp 호출을 통해 유효성을 검사해야합니다.

동기 모드에서는 로직이 단순하고 사용자가 경험하는 블로킹이 매우 짧고 문제가 없습니다.

비동기 모드에서 사용자는 초기 필드의 유효성을 검사하는 동안 다른 필드의 값을 변경할 수 있습니다. 이러한 변경 사항은 아직 검증되지 않은 초기 필드의 값을 사용하여 다른 xmlhttp 호출을 트리거합니다. 초기 유효성 검사가 실패하면 어떻게됩니까? 순수한 혼란. 동기화 모드가 더 이상 사용되지 않고 금지되면 애플리케이션 로직이 처리하기가 어려워집니다. 기본적으로 잠금을 관리하려면 응용 프로그램을 다시 작성해야합니다 (예 : 유효성 검사 프로세스 동안 다른 항목 비활성화). 코드 복잡성이 엄청나게 증가합니다. 그렇게하지 않으면 논리 오류가 발생하고 궁극적으로 데이터가 손상 될 수 있습니다.

기본적으로 질문은 차단되지 않은 UI 경험이나 데이터 손상 위험이 더 중요한 것은 무엇입니까? 대답은 W3C가 아닌 응용 프로그램 개발자에게 달려 있습니다.

변수 위치의 리소스가 첫 번째 리소스에 의존하는 페이지의 다른 정적 리소스보다 먼저로드되어야 완전히 작동 할 때 사용되는 동기식 XHR 요청의 용도를 볼 수 있습니다. 사실, JavaScript 리소스는 특정 매개 변수 집합에 따라 서버의 가변 위치에 상주하는 반면 내 자신의 작은 하위 프로젝트에서 이러한 XHR 요청을 구현하고 있습니다. 후속 자바 스크립트 리소스는 이러한 가변 리소스에 의존하며 이러한 파일은 다른 의존 파일이로드되기 전에로드되도록 보장해야하므로 애플리케이션이 전체가됩니다.

그 아이디어 기반은 실제로 vol7ron의 답변으로 확장됩니다. 트랜잭션 기반 프로시 저는 실제로 동기 요청을해야하는 유일한 시간입니다. 대부분의 다른 경우에는 비동기 호출이 더 나은 대안입니다. 호출 후 필요에 따라 DOM이 업데이트됩니다. 사용자 기반 시스템과 같은 대부분의 경우 특정 기능은 로그인 할 때까지 "승인되지 않은 사용자"에 대해 잠길 수 있습니다. 이러한 기능은 비동기 호출 후 DOM 업데이트 절차를 통해 잠금 해제됩니다.

나는 마지막으로이 문제에 대한 대부분의 개인의 요점에 동의한다고 말해야합니다. 가능한 한 동기식 XHR 요청은 작동 방식에 따라 브라우저가 동기식 호출로 잠기므로 피해야합니다. 동기 요청을 구현할 때는 브라우저가 일반적으로 잠기는 방식으로 수행되어야합니다. 예를 들어 페이지로드가 실제로 발생하기 전에 HEAD 섹션에서 말입니다.

2015 년부터 데스크톱 자바 스크립트 앱이 인기를 얻고 있습니다. 일반적으로 로컬 파일을로드 할 때 (그리고 XHR을 사용하여로드하는 것은 완벽하게 유효한 옵션) 이러한 앱에서로드 속도가 너무 빠르기 때문에 비동기로 코드를 복잡하게 만드는 부분이 거의 없습니다. 물론 비동기가 갈 길 (인터넷에서 콘텐츠 요청, 정말 큰 파일 또는 단일 일괄 처리로 엄청난 수의 파일로드)이 필요한 경우가있을 수 있지만 그렇지 않으면 동기화가 잘 작동합니다 (사용하기 훨씬 쉽습니다). .

jQuery는 일부 상황에서 내부적으로 동기 AJAX를 사용합니다. 스크립트가 포함 된 HTML을 삽입 할 때 브라우저는 스크립트를 실행하지 않습니다. 스크립트는 수동으로 실행해야합니다. 이러한 스크립트는 클릭 핸들러를 첨부 할 수 있습니다. 핸들러가 연결되기 전에 사용자가 요소를 클릭하고 페이지가 의도 한대로 작동하지 않는다고 가정합니다. 따라서 경합 상태를 방지하기 위해 동기 AJAX를 사용하여 해당 스크립트를 가져옵니다. 동기식 AJAX는 다른 모든 것을 효과적으로 차단하므로 스크립트와 이벤트가 올바른 순서로 실행되도록 할 수 있습니다.

이유:

사용자가 상호 작용을 수행하기 전에 서버에서 다양한 데이터를로드하기 위해 6 개의 http get을 수행해야하는 ajax 애플리케이션이 있다고 가정 해 보겠습니다.

분명히 이것이 onload에서 트리거되기를 원합니다.

동기 호출은 코드에 추가 복잡성없이이를 위해 매우 잘 작동합니다. 간단하고 간단합니다.

약점:

유일한 단점은 모든 데이터가로드되거나 시간 초과가 발생할 때까지 브라우저가 잠긴다는 것입니다. 문제의 ajax 응용 프로그램의 경우 모든 초기 데이터가 어쨌든로드 될 때까지 응용 프로그램이 사용되지 않기 때문에 문제가되지 않습니다.

대안?

그러나 많은 브라우저는 자바 스크립트가 그 중 하나에서 바쁜 동안 모든 창 / 탭을 잠그는 데, 이는 어리석은 브라우저 디자인 문제입니다.하지만 결과적으로 느린 네트워크에 대한 차단은 사용자가 다른 탭을 사용하지 못하게하는 경우 정중하지 않습니다. ajax 페이지가로드되기를 기다리는 동안.

그러나 어쨌든 최근 브라우저에서 동기 가져 오기가 제거되거나 제한 된 것 같습니다. 누군가가 자신이 항상 나쁘다고 결정했기 때문인지, 아니면 브라우저 작성자가 WC 작업 초안에서 주제에 대해 혼란스러워했는지는 확실하지 않습니다.

http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#the-open-method 는 차단 모드를 사용할 때 시간 제한을 설정할 수없는 것처럼 보이게합니다 (섹션 4.7.3 참조). . 나에게는 직관적이지 않은 것 같습니다. IO를 차단할 때마다 합리적인 시간 제한을 설정하는 것이 정중한데, 왜 사용자 지정 시간 제한이 아닌 io 차단을 허용합니까?

내 의견은 IO 차단이 일부 상황에서 중요한 역할을하지만 올바르게 구현되어야한다는 것입니다. 한 브라우저 탭이나 창에서 다른 모든 탭이나 창을 잠그는 것은 허용되지 않지만 이는 브라우저 디자인 결함입니다. 수치심이 필요한 곳에 수치심. 그러나 일부 상황에서는 개별 탭 또는 창이 몇 초 동안 응답하지 않는 경우 (예 : IO / HTTP GET 차단 사용) 경우에 따라 완벽하게 허용됩니다 (예 : 페이지로드시, 아마도 많은 데이터) 어쨌든 무언가를하기 전에해야합니다. 때로는 적절하게 구현 된 차단 코드가이를 수행하는 가장 깨끗한 방법입니다.

물론이 경우에 동등한 기능은 비동기 http get을 사용하여 얻을 수 있지만 어떤 종류의 구피 루틴이 필요합니까?

이 라인을 따라 뭔가를 시도 할 것 같습니다.

문서로드시 다음을 수행하십시오. 1 : 0으로 초기화 된 6 개의 전역 "완료"플래그 변수를 설정합니다. 2 : 6 개의 백그라운드 가져 오기를 모두 실행합니다 (순서가 중요하지 않다고 가정).

그런 다음 6 개의 http get 각각에 대한 완료 콜백은 각각의 "Done"플래그를 설정합니다. 또한 각 콜백은 다른 모든 done 플래그를 확인하여 6 개의 HTTP가 모두 완료되었는지 확인합니다. 완료 할 마지막 콜백은 다른 모든 작업이 완료되었음을 확인한 후 REAL init 함수를 호출하여 모든 데이터를 가져 왔으므로 이제 모든 것을 설정합니다.

가져 오는 순서가 중요하거나 웹 서버가 동시에 여러 요청을 수락 할 수없는 경우 다음과 같은 것이 필요합니다.

onload ()에서 첫 번째 http get이 시작됩니다. 콜백에서 두 번째가 시작됩니다. 콜백에서 세 번째는 등등이며 각 콜백은 다음 HTTP GET을 시작합니다. 마지막 것이 반환되면 실제 init () 루틴을 호출합니다.

프로덕션 코드에서 동기 호출을하면 어떻게됩니까?

하늘이 무너진다.

진지하게, 사용자는 잠긴 브라우저를 좋아하지 않습니다.

사용자 이름이 이미 존재하지 않는지 확인하는 동안 사용자 이름을 확인하는 데 사용합니다.

비동기 적으로 수행하는 것이 더 낫다는 것을 알고 있지만이 특정 유효성 검사 규칙에 대해 다른 코드를 사용해야합니다. 나는 더 잘 설명한다. 내 유효성 검사 설정은 데이터가 유효한지 여부에 따라 true 또는 false를 반환하는 일부 유효성 검사 함수를 사용합니다.

함수가 반환되어야하므로 비동기 기술을 사용할 수 없으므로 동기식으로 만들고 서버가 너무 눈에 띄지 않도록 신속하게 응답하기를 바랍니다. AJAX 콜백을 사용했다면 나머지 실행을 다른 유효성 검사 방법과 다르게 처리해야합니다.

때로는 다른 사람에게 의존하는 행동이 있습니다. 예를 들어, 조치 B는 A가 완료된 경우에만 시작할 수 있습니다. 동기식 접근 방식은 일반적으로 경쟁 조건 을 피하기 위해 사용됩니다 . 때로는 동기 호출을 사용하는 것이 더 간단한 구현이고 복잡한 논리를 만들어 서로 의존하는 비동기 호출의 모든 상태를 확인합니다.

이 접근 방식의 문제는 작업이 완료 될 때까지 사용자의 브라우저를 "차단"한다는 것입니다 (요청이 반환, 완료,로드 등). 따라서 사용할 때 조심하십시오.

코드를 개발할 때 동기식 호출을 사용합니다. 요청이 서버와 통신하는 동안 수행 한 작업은 오류의 원인을 모호하게 만들 수 있습니다.

작동 할 때 비동기로 만들지 만 중단 타이머와 실패 콜백을 포함하려고합니다.

SYNC vs ASYNC : 차이점은 무엇입니까?

기본적으로 다음과 같이 요약됩니다.

console.info('Hello, World!');
doSomething(function handleResult(result) {
    console.info('Got result!');
});
console.info('Goodbye cruel world!');

때 doSomething이다 동기식 이 인쇄 것입니다 :

Hello, World!
Got result!
Goodbye cruel world!

경우 반면에, doSomething이다 비동기 이 인쇄 것입니다 :

Hello, World!
Goodbye cruel world!
Got result!

함수 doSomething가 작업을 비동기 적으로 수행하기 때문에 작업이 완료되기 전에 반환됩니다. 그래서 우리는 인쇄 후에 만 ​​결과를 얻습니다Goodbye cruel world!

비동기 호출의 결과에 의존하는 경우 콜백에 종속 코드를 배치해야합니다.

console.info('Hello, World!');
doSomething(function handleResult(result) {
    console.info('Got result!');
    if (result === 'good') {
        console.info('I feel great!');
    }
    else {
        console.info('Goodbye cruel world!');
    }
});

따라서 2 ~ 3 가지 일이 순서대로 발생해야한다는 사실만으로는 동기식으로 수행 할 이유가 없습니다 (대부분의 사람들이 코드를 동기화하는 것이 더 쉽습니다).

SYNCHRONOUS XMLHTTPREQUEST를 사용하는 이유는 무엇입니까?

호출 된 함수가 완료되기 전에 결과가 필요한 상황이 있습니다. 다음 시나리오를 고려하십시오.

function lives(name) {
    return (name !== 'Elvis');
}
console.info('Elvis ' + (lives('Elvis') ? 'lives!' : 'has left the building...');

호출 코드 ( console.info줄)를 제어 할 수없고 lives서버에 요청하는 기능을 변경해야 한다고 가정 합니다. 서버 내부에서 비동기 요청을 수행하고 완료 lives되기 전에 응답 을받을 수있는 방법이 없습니다 lives. 그래서 우리는 돌아올 지 true아니면false . 함수가 완료되기 전에 결과를 얻는 유일한 방법은 동기 요청을 수행하는 것입니다.

Sami Samhuri그의 답변에서 언급 했듯이 함수가 종료되기 전에 서버 요청에 대한 응답이 필요할 수있는 매우 실제 시나리오는 onbeforeunload이벤트입니다. 이는 창이 닫히기 전에 실행될 앱의 마지막 함수이기 때문입니다.

나는 동기화 호출이 필요하지 않지만 그들이 더 쉽기 때문에 어쨌든 그것을 사용합니다.

하지 마십시오. 동기 호출은 브라우저를 잠그고 앱이 응답하지 않는 느낌을줍니다. 그러나 당신이 옳습니다. 비동기 코드는 더 어렵습니다. 그러나이를 훨씬 쉽게 처리 할 수있는 방법이 있습니다. 동기화 코드만큼 쉽지는 않지만 점점 가까워지고 있습니다. Promise s.

다음은 예입니다. 두 개의 비동기 호출이 모두 성공적으로 완료되어야 세 번째 코드 세그먼트가 실행될 수 있습니다.

var carRented = rentCar().then(function(car){
  gasStation.refuel(car);
});

var hotelBooked = bookHotel().then(function(reservation) {
  reservation.confirm();
});

Promise.all([carRented, hotelBooked]).then(function(){
  // At this point our car is rented and our hotel booked.
  goOnHoliday();
});

구현 방법은 다음과 같습니다 bookHotel.

function bookHotel() {
  return new Promise(function(resolve, reject){
    if (roomsAvailable()) {
      var reservation = reserveRoom();
      resolve(reservation);
    }
    else {
      reject(new Error('Could not book a reservation. No rooms available.'));
    }
  });
}

참조 : 약속으로 더 나은 JavaScript 작성 .

XMLHttpRequest전통적으로 비동기 요청에 사용됩니다. 때로는 (디버깅 또는 특정 비즈니스 로직의 경우) 한 페이지에서 모든 / 여러 비동기 호출을 동기화하도록 변경하고 싶습니다.

JS 코드의 모든 내용을 변경하지 않고 수행하고 싶습니다. async / sync 플래그는 이러한 기능을 제공하며 올바르게 설계된 경우 코드에서 한 줄만 변경하거나 var실행 시간 동안 한 줄의 값을 변경하면 됩니다.

Firefox (및 아마도 모든 비 IE 브라우저)는 비동기 XHR 시간 제한을 지원하지 않습니다.

1. Stackoverflow 토론
2. Mozilla Firefox XMLHttpRequest

HTML5 WebWorkers 는 시간 제한을 지원합니다. 따라서 시간 초과 동작이있는 비동기식 XHR을 구현하기 위해 시간 초과가있는 WebWorker에 대한 동기화 XHR 요청을 래핑 할 수 있습니다.

forEach (및 for 루프)를 사용하여 연속적으로 호출 된 URL 목록에 대한 비동기 요청으로 인해 나머지 요청이 취소되는 상황이 발생했습니다. 동기식으로 전환했고 의도 한대로 작동합니다.

동기식 HTTP 요청을 사용하는 것은 모바일 광고 비즈니스에서 일반적인 관행입니다.

애플리케이션을 구축하는 회사 (일명 "게시자")는 종종 수익을 창출하기 위해 광고를 실행합니다. 이를 위해 앱에 광고 SDK를 설치합니다. 많은 것이 존재합니다 (MoPub, Ogury, TapJob, AppNext, Google Ads AdMob).

이러한 SDK는 웹보기에서 광고를 제공합니다.

사용자에게 광고를 게재 할 때 특히 원활한 경험 이어야 합니다. 동영상을 재생할 때 . 언제든지 버퍼링이나로드가 없어야합니다.

이를 해결하기 위해 precaching사용됩니다. 미디어 (사진 / 비디오 등)가 웹뷰의 백그라운드에서 동기식으로로드되는 위치입니다.

비동기식으로하지 않는 이유는 무엇입니까?

1. 이것은 전 세계적으로 인정되는 표준의 일부입니다.
2. SDK는 onload이벤트를 수신 하여 광고가 사용자에게 게재 될 "준비"상태인지 알 수 있습니다.

동기식 XMLHttpRequests 의 지원이 중단됨에 따라 광고 비즈니스는 다른 방법을 결정할 수없는 한 향후 표준을 변경해야 할 가능성이 높습니다.

동기식 XHR은 (비 프로덕션) 내부 도구 및 / 또는 프레임 워크 개발에 매우 ​​유용 할 수 있습니다. 예를 들어 다음과 같이 처음 액세스 할 때 코드 라이브러리를 동 기적으로로드하려고한다고 가정 해보십시오.

get draw() 
{
    if (!_draw)
    {
       let file;
       switch(config.option)
       {
           case 'svg':
              file = 'svgdraw.js';
              break;
           case 'canvas':
              file = 'canvasdraw.js';
              break;
           default:
              file = 'webgldraw.js';
       }

       var request = new XMLHttpRequest();
       request.open('GET', file, false);
       request.send(null);
       _draw = eval(request.responseText);
    }

    return _draw;
}

현기증에 빠져서 평가의 악을 맹목적으로 역류시키기 전에 이것은 로컬 테스트 용이라는 것을 명심하십시오. 프로덕션 빌드의 경우 _draw가 이미 설정되어 있습니다.

따라서 코드는 다음과 같습니다.

foo.drawLib.draw.something(); //loaded on demand

이것은 XHR 동기화 없이는 불가능한 일의 한 예일뿐입니다. 이 라이브러리를 미리로드하거나, 약속 / 콜백을 수행 할 수 있지만 동기화 XHR 없이는 lib를 동 기적으로로드 할 수 없습니다. 이런 종류의 것이 얼마나 많은 코드를 정리할 수 있는지 생각해보십시오.

도구 및 프레임 워크 (로컬에서 실행)에 대해이 작업으로 수행 할 수있는 작업의 한계는 상상력에 의해서만 제한됩니다. 그러나 JavaScript 세계에서는 상상력이 약간 제한되어 있습니다.

여기에 한 가지 좋은 이유가 있습니다. 결과에 따라 http 요청을 수행하고 싶었습니다. 입력 type = file에서 click ()을 호출합니다. 비동기 xhr 또는 fetch에서는 불가능합니다. 콜백은 컨텍스트 "사용자 작업"을 잃게되므로 click () 호출이 무시됩니다. 동기식 xhr로 베이컨을 구했습니다.

onclick(event){
    //here I can, but I don't want to.
    //document.getElementById("myFileInput").click();
    fetch("Validate.aspx", { method : "POST", body: formData, credentials: "include" })
    .then((response)=>response.json())
    .then(function (validResult) {
        if (validResult.success) {
            //here, I can't.
            document.getElementById("myFileInput").click();
        }
    });
}