제 글에서는 sync -> promise -> async로 차례대로 바꾸기 위해 promise 코드를 다소 부자연스럽게 표현하였습니다.
재미있는 건 sync한 코드와 async한 코드 사이에 dualism이 존재하기 때문에 truwater이 말씀하신 코드가 더 좋은 코드라면, 이 코드를 그대로 sync코드로 옮기면 sync 코드도 더 좋은 코드가 나오게 됩니다. 이 부분에 대해서는 다음 글에서 좀 더 자세히 설명하겠습니다.
Promise를 봐도 이해가 안되는 점이 말씀하신 부분입니다.
C# 5도, ES7도 채택하는 async / await 모델은 기존 흐름과 큰 차이 없이 읽을 수 있는데,
Promise를 쓸 경우 조건에 따른 분기등을 처리할 때 이상해지는 느낌입니다.
(조건이 달라지면 catch로 빼야하나 뭐 이런 생각이)
개인적으로는 synchronize.js 같이 fiber를 통해서 async await를 미리 쓰는 쪽을 선호합니다.
ES6에 Generator도 추가가 되는데 왜 promise와 함께 두가지 종류의 비동기 프로그래밍 방식을 제공하는지 궁금합니다. ES7의 async가 generator와 promise로 구현되서 그런가요?
좋아요Liked by 2 people
좋은 질문이네요. Generator와의 관계는 3부에서 다루겠습니다!
좋아요좋아요
칼럼 잘 보고 있습니다. 감사합니다.
Promise의 일반적인 코딩 패턴은 아래와 같지 않을까요?
var fs = require(‘fs’);
var Promise = require(‘promise’);
var readFile= Promise.denodeify(fs.readFile);
var writeFile= Promise.denodeify(fs.writeFile);
readFile(‘config.json’)
.then(function (text) {
var obj = JSON.parse(text);
return writeFile(‘domain.txt’, obj.domain);
})
.then(function () {
console.log(“Done”);
})
.catch(function (reason) {
// 에러 처리
})
.done();
개인적으로는 Promise를 사용해서 많이 간결해 진다고 느끼고 있습니다.
좋아요좋아요
네 말씀하신 대로 짜는 게 좀 더 functional한 스타일입니다.
제 글에서는 sync -> promise -> async로 차례대로 바꾸기 위해 promise 코드를 다소 부자연스럽게 표현하였습니다.
재미있는 건 sync한 코드와 async한 코드 사이에 dualism이 존재하기 때문에 truwater이 말씀하신 코드가 더 좋은 코드라면, 이 코드를 그대로 sync코드로 옮기면 sync 코드도 더 좋은 코드가 나오게 됩니다. 이 부분에 대해서는 다음 글에서 좀 더 자세히 설명하겠습니다.
좋아요Liked by 1명
[…] 2부에서는 JSON 파일을 읽어 domain key 값을 다시 파일에 쓰는 코드를 sync, callback, […]
좋아요좋아요
Promise를 봐도 이해가 안되는 점이 말씀하신 부분입니다.
C# 5도, ES7도 채택하는 async / await 모델은 기존 흐름과 큰 차이 없이 읽을 수 있는데,
Promise를 쓸 경우 조건에 따른 분기등을 처리할 때 이상해지는 느낌입니다.
(조건이 달라지면 catch로 빼야하나 뭐 이런 생각이)
개인적으로는 synchronize.js 같이 fiber를 통해서 async await를 미리 쓰는 쪽을 선호합니다.
좋아요좋아요