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

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

대부분의 사용자가 XMLHttpRequest를 사용하여 비동기 요구를 하는 것처럼 보이지만 동기 요구를 실행할 수 있는 기능이 있다는 것은 그럴 만한 타당한 이유가 있을 수 있음을 나타냅니다.그렇다면 타당한 이유가 뭘까요?

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

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

HTML 5 규격이 발전함에 따라 더 인기를 끌 수 있을 것 같습니다.웹 어플리케이션이 웹 워커에 액세스 할 수 있는 경우, 개발자가 전용 웹 워커를 사용하여, Jonathan이 말한 것처럼, 하나의 요구가 다른 요구보다 먼저 이루어지도록 동기 요구를 하는 것을 예측할 수 있습니다.현재 1개의 스레드 상태에서는 요청이 완료될 때까지 차단되므로 이상적인 설계는 아닙니다.

업데이트:

아래는 더 나은 비동기식 요청 처리가 등장함에 따라 요청이 완료될 때까지 사용자의 작업을 의도적으로 차단할 의도가 없는 한 동기식 요청을 사용할 이유가 없음을 암시했지만 전달에는 실패했습니다.

나쁘게 들릴 수도 있지만 사용자가 페이지를 떠나기 전 또는 액션을 수행하기 전에 요청(또는 일련의 요청)이 발생하는 것이 중요한 경우가 있습니다.다른 코드 실행을 차단하는 것(뒤로 버튼을 막는 것 등)은 잘못 설계된 시스템의 오류/유지보수를 줄일 수 있습니다.즉, 와이파이에서는 본 적이 없습니다.ld 및 피해야 한다고 강조합니다.

라이브러리는 약속과 마찬가지로 콜백을 통한 프로세스 체인으로 동기성을 가장합니다.이는 브라우저가 사용자에 대한 응답성을 유지할 수 있는 논블로킹 이벤트를 주문하려는 대부분의 개발 요구에 부합합니다(양호 UX).

Mozilla 문서에서 설명한 바와 같이 동기 요구를 사용해야 하는 경우도 있습니다.다만, 이러한 경우에 비콘(IE/Safari에서는 이용할 수 없음)을 사용하는 회피책도 기재되어 있습니다.이것은 실험적인 것이지만, 만약 그것이 표준 수용에 도달한다면, 동기 요구 관에 못을 박을 수도 있다.

---

모든 종류의 트랜잭션 처리 또는 필요한 작업 순서에서 동기 호출을 수행할 수 있습니다.

예를 들어, 노래를 재생한 후 로그아웃하도록 이벤트를 사용자 지정하려고 합니다.로그아웃 조작이 먼저 이루어지면 노래가 재생되지 않습니다.이 작업을 수행하려면 요청을 동기화해야 합니다.

또 다른 이유는 Web Service를 사용하는 경우, 특히 서버에서 계산을 수행하는 경우입니다.

예:서버에 값이 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이므로 동작순서가 중요하며 동기화가 필요합니다.

---

동기 콜이 일반적인 현실 세계의 예에서 정당화될 수 있는 경우는 거의 없습니다.예를 들어 login(로그인)을 클릭한 후 사용자가 로그인해야 하는 사이트의 일부를 클릭할 때 발생할 수 있습니다.

다른 사람들이 말한 것처럼 브라우저가 잠기므로 가능한 한 멀리 떨어지십시오.

다만, 동기 콜 대신에, 유저는, 현재 로딩중의 이벤트를 정지하고 나서, 그 외의 조작을 실행하는 경우가 많습니다.어떤 면에서는 첫 번째 이벤트가 두 번째 이벤트가 시작되기 전에 종료되기 때문에 이것은 동기화입니다.이를 수행하려면 xml 연결 개체에서 abort() 메서드를 사용합니다.

요청이 받아들여지는 동안 사용자의 브라우저를 차단하는 것을 고려한다면 동기 요청을 사용하십시오.

요구의 시리얼화가 목적인 경우 이전 요구의 onComplete 콜백을 다음 줄에 실행함으로써 비동기 요구를 사용하여 이 작업을 수행할 수 있습니다.

UI를 차단하는 것이 정확히 바람직한 동작인 경우가 많습니다.

여러 필드가 있는 앱을 사용하고 일부 필드는 이 필드의 값 및 기타 필드 값을 입력으로 제공하는 원격 서버에 대한 xmlhttp 호출에 의해 검증되어야 합니다.

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

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

기본적으로 문제는 차단되지 않은 UI 환경과 데이터 손상 위험 중 어떤 것이 더 중요한가 하는 것입니다.답은 W3C가 아닌 애플리케이션 개발자에게 있습니다.

완전히 기능하기 위해 첫 번째 리소스에 의존하는 페이지의 다른 정적 리소스보다 먼저 가변 위치에 있는 리소스를 로드해야 할 때 사용하는 동기 XHR 요청의 용도를 알 수 있습니다.사실, 저는 이러한 XHR 요청을 저만의 작은 서브프로젝트에 구현하고 있습니다.한편 JavaScript 리소스는 특정 파라미터 세트에 따라 서버상의 다양한 위치에 존재합니다.후속 JavaScript 리소스는 이러한 가변 리소스에 의존하며, 이러한 파일은 다른 신뢰할 수 있는 파일이 로드되기 전에 로딩되도록 보장해야 하며, 따라서 애플리케이션이 완전히 만들어져야 합니다.

vol7ron의 답변에 따라 아이디어 기반이 확장됩니다.트랜잭션 기반 절차는 동기 요청을 해야 하는 유일한 시점입니다.그 외의 대부분의 경우, 비동기 콜은, 콜 후에 필요에 따라서 DOM 를 갱신하는 경우에 적합합니다.대부분의 경우 사용자 기반 시스템 등 특정 기능을 "부정 사용자"가 로그인 할 때까지 잠글 수 있습니다.이러한 기능은, 비동기 콜 후에, DOM 갱신 순서에 의해서 언록 됩니다.

마지막으로 이 문제에 대한 대부분의 개인들의 의견에 동의한다고 말할 수 밖에 없습니다.동기의 XHR 요구는 가능한 한 피해야 합니다.동기의 동작 방식에서는 브라우저가 동기 호출로 잠깁니다.동기요구를 실장할 때는 페이지 로딩이 실제로 이루어지기 전에 HEAD 섹션에서 브라우저가 정상적으로 잠기는 방식으로 해야 합니다.

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

2015년 현재 javascript 앱의 인기가 높아지고 있습니다.일반적으로 로컬 파일을 로드할 때(그리고 XHR을 사용하여 파일을 로드할 경우) 이러한 앱에서는 로드 속도가 너무 빨라서 코드가 비동기 파일과 너무 복잡해지는 일이 거의 없습니다.물론 비동기화가 최선의 방법일 수도 있지만(인터넷에서 콘텐츠를 요청하거나, 매우 큰 파일을 단일 배치로 로드하거나), 그렇지 않으면 동기화가 잘 작동합니다(또한 훨씬 사용하기 쉬울 수도 있습니다.

이유:

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

확실히 부하가 걸렸을 때 작동시키고 싶군요.

동기 콜은, 코드에 복잡함을 더하는 일 없이, 이것에 매우 적합합니다.그것은 간단하고 간단하다.

결점:

유일한 단점은 모든 데이터가 로드되거나 타임아웃이 발생할 때까지 브라우저가 잠긴다는 것입니다.문제가 되고 있는 Ajax 어플리케이션의 경우, 초기 데이터가 모두 로드될 때까지 어플리케이션은 아무 소용이 없기 때문에 큰 문제가 되지 않습니다.

다른 방법?

그러나 많은 브라우저가 javascript가 사용 중일 때 모든 창/탭을 잠그는 것은 어리석은 브라우저 설계 문제이지만, 결과적으로 느린 네트워크에서의 블로킹이 사용자가 Ajax 페이지가 로드되기를 기다리는 동안 다른 탭을 사용하지 못하게 하는 것은 예의에 어긋난다.

다만, 최근의 브라우저에서는 동기화가 삭제되거나 제한되고 있는 것 같습니다.누군가가 항상 나쁘다고 판단했기 때문인지, 아니면 브라우저 작성자들이 이 주제에 대한 WC 작업 초안을 보고 혼란스러웠는지 모르겠다.

http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/ #the-open-module은 블로킹모드 사용 시 타임아웃을 설정할 수 없는 것처럼 보이게 합니다(섹션 4.7.3 참조).직감적으로 반대되는 것 같습니다.IO를 차단할 때마다 적절한 시간 초과를 설정하는 것이 예의인데, 사용자가 지정한 시간 초과로 차단 IO를 허용하지 않는 이유는 무엇입니까?

I/O 차단은 상황에 따라 중요한 역할을 하지만 올바르게 구현해야 한다고 생각합니다.하나의 브라우저 탭 또는 창이 다른 모든 탭 또는 창을 잠그는 것은 허용되지 않지만, 이것이 브라우저 설계 결함입니다.수치심을 느껴야 할 곳에 수치심을 느껴라.그러나 경우에 따라서는 개별 탭 또는 창이 몇 초 동안 응답하지 않는 경우도 있습니다(예: IO/HTTP GET 차단 사용). 예를 들어 페이지 로드 시 많은 데이터가 필요할 수 있습니다.블로킹 코드를 적절히 실장하는 것이 가장 깨끗한 방법일 수 있습니다.

물론 이 경우 비동기 http gets를 사용하여 동등한 함수를 얻을 수 있지만 어떤 종류의 goofy 루틴이 필요할까요?

저는 다음과 같은 방법을 시도해 보겠습니다.

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

그런 다음 6개의 http get 각각에 대한 완료 콜백은 각각의 "Done" 플래그를 설정합니다.또한 각 콜백은 다른 모든 완료된 플래그를 체크하여 6개의 HTTP가 모두 완료되었는지 확인합니다.마지막으로 완료된 콜백은 다른 모든 콜백이 완료된 것을 확인하면 REAL init 함수를 호출하여 모든 데이터를 취득한 시점에서 모든 것을 셋업합니다.

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

onload()에서는 첫 번째 http get이 실행됩니다.콜백에서는 두 번째 콜백이 실행됩니다.콜백에서는 세 번째 콜백이 계속되며 각 콜백이 다음 HTTP GET을 실행합니다.마지막 1개가 돌아왔을 때 실제 init() 루틴을 호출합니다.

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

하늘이 무너지다.

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

사용자 이름이 아직 존재하지 않는지 확인하는 동안 사용자 이름을 검증하기 위해 사용합니다.

이를 비동기적으로 실행하는 것이 더 낫다는 것을 알지만, 이 특정 검증 규칙에는 다른 코드를 사용해야 합니다.제가 더 잘 설명할게요.검증 셋업에서는 데이터의 유효 여부에 따라 true 또는 false를 반환하는 검증 함수를 사용합니다.

함수는 되돌아가야 하기 때문에 비동기 기술을 사용할 수 없기 때문에 동기화할 뿐이며, 서버가 너무 눈에 띄지 않도록 신속하게 응답해 주었으면 합니다.AJAX 콜백을 사용하는 경우 나머지 실행은 다른 검증 방법과는 다르게 처리해야 합니다.

때로는 다른 사람에게 달려있는 행동을 하기도 합니다.예를 들어 작업 B는 A가 완료된 경우에만 시작할 수 있습니다.동기식 접근은 일반적으로 경주 조건을 피하기 위해 사용된다.동기 콜을 사용하는 것이 서로 의존하는 비동기 콜의 모든 상태를 체크하는 복잡한 로직을 작성하는 것보다 간단한 구현일 수 있습니다.

이 접근법의 문제는 액션이 완료될 때까지(요구가 반환, 종료, 로드될 때까지) 사용자의 브라우저를 "차단"하는 것입니다.그러니 조심해서 사용하세요.

코드를 개발할 때 동기 호출을 사용합니다.요구가 서버 간에 전송되는 동안 수행한 작업이 오류의 원인을 모호하게 할 수 있습니다.

동작하고 있을 때는 비동기식으로 합니다만, 중단 타이머와 실패 콜백을 포함하려고 합니다.왜냐하면...

SYNC와 비동기: 차이점은 무엇입니까?

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

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!

함수는 ★★★★★★★★★★★★★★ becausedoSomething비동기적으로 작업을 수행하며 작업이 완료되기 전에 되돌아옵니다.를 해야 결과가 나옵니다.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!');
    }
});

따라서 두세 가지 일을 동시에 해야 한다는 사실만으로 동기화할 필요는 없습니다(단, 대부분의 사람들이 동기 코드를 사용하는 것이 더 쉽습니다).

동기 XMLHTTP 요구를 사용하는 이유

호출된 함수가 완료되기 전에 결과가 필요한 경우가 있습니다.다음 시나리오를 고려해 주십시오.

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

코드Calling Code」)를할 수 합니다(「Calling Code」console.info및( 「 」 ） 。lives…는, 「내부」에서할 수 .lives이 남아있습니다.lives그래서 여부를 알 수 .true ★★★★★★★★★★★★★★★★★」false함수가 완료되기 전에 결과를 얻는 유일한 방법은 동기 요청을 실행하는 것입니다.

~로Sami Samhuri하고 있는 매우 에 서버 할 수 .기능이 종료되기 전에 서버 요구에 대한 응답이 필요한 매우 현실적인 시나리오는onbeforeunload이 이벤트는 창이 닫히기 전에 실행되는 앱의 마지막 기능이기 때문입니다.

동기 콜은 필요 없습니다만, 간단하게 사용할 수 있기 때문에, 어쨌든 사용하고 있습니다.

제발 하지마.동기 호출은 브라우저를 잠그고 앱을 무응답 상태로 만듭니다.하지만 당신이 옳아요.비동기 코드가 더 어렵습니다.하지만 훨씬 쉽게 대처할 수 있는 방법이 있습니다.동기 코드만큼 쉽지는 않지만 점점 가까워지고 있습니다. 약속.

다음은 예를 제시하겠습니다.3번째 코드세그먼트를 실행하기 전에 2개의 비동기 콜이 모두 정상적으로 완료되어야 합니다.

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.'));
    }
  });
}

다음 항목도 참조하십시오.Promise를 사용하여 더 나은 JavaScript를 작성합니다.

XMLHttpRequest 는 전통적으로 비동기 요구에 사용됩니다.경우에 따라서는 (디버깅 또는 특정 비즈니스 로직의 경우) 1페이지에 있는 비동기 콜의 전부 또는 여러 개를 변경하여 동기화할 수 있습니다.

JS 코드의 모든 것을 변경하지 않고 작업을 수행하고자 합니다.하면 이 할 수 있습니다.되어 있는 1하거나, 1 행의 비동기/동기 할 필요가 .var행행중 。

Firefox(및 모든 비 IE 브라우저)는 비동기 XHR 타임아웃을 지원하지 않습니다.

1. 스택오버플로우 설명
2. Mozilla Firefox XMLHttpRequest

HTML5 WebWorker는 타임아웃을 지원합니다.따라서, WebWorker 에의 동기 XHR 요구를 타임 아웃으로 랩 해, 타임 아웃 동작으로 비동기식 XHR 를 실장할 수 있습니다.

forEach(및 for 루프)를 사용하여 연속적으로 호출된 URL 목록에 대한 비동기 요구가 나머지 요청을 취소하는 상황이 있었습니다.싱크로나이즈로 전환했더니 정상적으로 작동합니다.

동기 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 요구를 사용하는 것은 모바일애드버타이즈먼트 비즈니스에서는 일반적인 관례입니다.

애플리케이션을 구축하는 기업(일명 "퍼블리셔")은 수익을 창출하기 위해 광고를 내보내는 경우가 많습니다.이를 위해 앱에 광고 SDK를 설치합니다.많은 것들이 존재합니다(MoPub, Ogury, TapJob, AppNext, Google Ads AdMob).

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

유저에게 광고를 제공할 때는, 특히 비디오를 재생할 때는, 보다 부드러운 체험이 필요하게 됩니다.버퍼링이나 로딩은 일절 발생하지 않습니다.

이 문제를 해결하려면precaching사용됩니다.미디어(사진/비디오 등)가 웹 뷰의 배경에 동기적으로 로드되는 위치.

왜 비동기적으로 하지 않는 거죠?

1. 이는 글로벌하게 인정된 표준의 일부입니다.
2. SDK가 수신합니다.onload사용자에게 언제 광고를 제공할 수 있는지 알 수 있는 이벤트

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

여기 한가지 좋은 이유가 있다.그 후 결과에 따라 입력 type=file에 click()을 호출하여 http 요청을 하고 싶었습니다.비동기 xhr 또는 가져오기에서는 이 작업을 수행할 수 없습니다.콜백은 "user action" 컨텍스트를 잃기 때문에 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();
        }
    });
}

왜냐면chrome.webRequest.*.addListener는 비동기 핸들러를 지원하지 않습니다.

언급URL : https://stackoverflow.com/questions/2088318/is-there-any-reason-to-use-a-synchronous-xmlhttprequest