https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Promises
Promises를 사용한 우아한 비동기 프로그래밍
Promise 는 이전 작업이 완료될 때까지 추가 작업을 연기하거나 실패에 응답할 수 있도록 하는 JavaScript 언어의 비교적 새로운 기능입니다.
=> 이전에 간단히 나왔을때 그냥 콜백함수를 사용하는 것보다 획기적으로 코드 복잡성을 줄여주었다. 콜백 지옥을 탈출 시켜준다.
Promise는 무엇입니까?
기본적으로 Promise는 작업의 중간 상태를 나타내는 객체입니다. 사실상 어떤 종류의 결과가 미래의 어느 시점에서 반환될 것이라는 약속 입니다.
Promise와 관련하여 가장 일반적인 참여 중 하나는 Promise를 반환하는 Web API를 사용하는 것입니다.
해당 버튼의 핸들러 getUserMedia()는 사용자의 카메라와 마이크에 액세스하기 위해 호출 합니다.
=> 해당 기능은 마이크, 스피커의 권한 및 차단, 보안 등 복잡한 과정이 거치기 때문에
시간이 오래 걸릴 수 있습니다.
getUserMedia()은 브라우저의 기본 스레드에서 이루어 지기 때문에 getUserMedia()반환 될 때까지 전체 브라우저가 차단됩니다 !
약속이 없으면 사용자가 카메라와 마이크에 대해 무엇을 할지 결정할 때까지 브라우저의 모든 것을 사용할 수 없게 됩니다.
따라서 사용자를 기다리는 대신 선택한 장치를 활성화 MediaStream하고 선택한 소스에서 생성된 스트림에 대해 직접 반환하면 사용 가능하게 되면 해결되는 를 getUserMedia()반환 합니다.promiseMediaStream
function handleCallButton(evt) {
setStatusMessage("Calling...");
navigator.mediaDevices.getUserMedia({video: true, audio: true})
.then(chatStream => {
selfViewElem.srcObject = chatStream;
chatStream.getTracks().forEach(track => myPeerConnection.addTrack(track, chatStream));
setStatusMessage("Connected");
}).catch(err => {
setStatusMessage("Failed to connect");
});
}=> 아 그래서 화상 채팅으로 완벽히 접속이 되기 전에 버퍼링이 걸리는 거구만 그래서 그 버퍼링 표시를 해주는 거고 Calling...으로 이걸로.
=> 프로미스가 오케이! axios 처럼 성공과 실패를 가져와서 그에 따라 코드를 실행하는 거인거는 알겠음
=> 그런데 이게 callback 함수들이랑 무슨 차이가 있는거임 ?
=> 콜백 함수들도 결국에는 성공하면 안에 있는 친구를 발생시키는 건데..
=> 만약 아예 그냥 함수는 동기적으로 작동하고 아예 프로미스는 비동기적으로 작동한다고 도장이 찍혀 있으면 모를까 ...
+) 수정
=> 옆 동네 홍선이와 한길좌 검수를 통해 기존 callback 시스템과 promise의 차이와 어떤 경쟁력이 생기는지 깨달을 수 있었다.
=> js는 호이스팅처럼 다양한 위치의 함수들에 영향을 받는 괴팍한 친구이다. 이 이유로 js를 싫어하는 사람(한길좌) 도 있다.
=> 아무튼 callback 함수를 여러개 겹쳐 쓰다보면 아 .. 예전에 이벤트 회오리? 같은 에러가 발생했는데 그 에러의 원인을 찾을 수 없었다. 그것도 연관이 있을 수 있을듯 ... 아무튼 ...
=> 이렇게 에러가 발생해도 어디라고 콕 찝어서 해결할 수 없는 경우가 발생한다.
=> 그런데, 만약 promise로 성공시 .then , 실패시 .catch로 블록을 한정 짓게 된다면 코드의 실행 과정을 명확히 파악하고 제한할 수 있다.
=> 그리고 .then의 함수에는 result, resolve 인자가 특정되어 있기 때문에 다른 위치의 함수들의 범람을 허용하지 않는다.
=> 콜백 지옥을 해결하기 위해 promise가 나왔다고 해서 콜백 지옥은 여러 함수들이 겹쳐있는 걸 생각했는데 promise는 이 여러겹 합쳐진 물리적인 걸 해결하는게 아닌 콜백 지옥으로 생긴 불명확성을 해결하려고 나온 문법이다.
=> 추가로 이 겹쳐지는 코드 복잡성을 해결하는 건 async와 await라고 ...
아무튼,
여기서 중요한 것은 getUserMedia()카메라 스트림이 아직 획득되지 않은 경우에도 호출이 거의 즉시 반환 된다는 것 입니다. handleCallButton()함수가 이미 호출한 코드로 반환된 경우에도 getUserMedia()작업이 완료 되면 사용자가 제공한 핸들러를 호출합니다. 앱이 스트리밍이 시작되었다고 가정하지 않는 한 계속 실행될 수 있습니다.
=> 왜냐면 아무것도 렌더링이 되지 않는다면 이용자들은 바로 이상하다고 생각하고 이탈을 해버린다.
=> 이 고민이 이제 다음 턴에 나온다
