kakasoo

또는, setTimeout은 call stack의 제어권을 빼앗는가? function b () { let i = 0; while(true){ console.log('in'); i++; if (i % 1000 === 0) { new Promise((res) => { setTimeout(() => { console.log('ok'); }, 3000); }) } } console.log('out'); } 이 함수에서 내부의 setTimeout이 있는 Promise는 동작하지 않는다. 호출 스택에 있을 b가 끝나지 않기 때문이다. setTimeout의 시간에 도달한다고 하더라도, 호출 스택이 비지 않으면 이벤트 루프는 이벤트 큐의 함수를 호출 스택으로 내보내지 않는다. 즉, setTimeout은 호출 스택의 최..

const varToString = varObj => Object.keys(varObj)[0] const someVar = 42 const displayName = varToString({ someVar }) console.log(displayName) 이게 가능할까 싶어서 찾아봤더니, 스택오버플로우에서 이런 코드를 발견했다. 변수의 이름을 알아내기 위해서 Function의 메서드를 사용해야 하나, arguments를 이용한 옛 방식을 써야 하나 했는데 의외다.

어떤 객체를 문자열로 변환한 것에 함수가 포함되어 있는 경우 JSON.parse는 사용할 수 없다. 이런 경우, 안타깝게도 정상적인 방법은 없다. 다만, 그나마 가능성이 있는 것이 바로 정규표현식으로, 아래와 같이 작성해볼 수 있다. const regex = /(?\s*\{[\s\S]+?\})\s*(?=,|})*/g; async가 있을 수도 없을 수도 있는 function 혹은 화살표 함수에 대한 정규 표현식으로, 이걸 사용해 함수 부분을 캐치한다. 그 후 String.prototype.replaceAll 로 함수 부분을 쓸 모 없는 아무 값으로 변환하는 것이다. 하지만 그나마 가능성 있다는 말처럼, 나는 이런 정규 표현식을 사용하여 문제를 해결하는 데에는 실패했다. 왜냐하면 내가 마주한 문제는 \r\n..

const first = 'first'; const second = 'second'; const expression= `(?

2.6.6. 비동기 임포트 ESM의 단점은, 모듈 식별자를 실행 중에 생성할 수 없다는 점, 모든 파일의 최상위에 선언되어 제어 구문 내에 포함될 수 없다는 점이다. 이는 사용자에 따라 다른 모듈을 불러야 하는 경우에 지나친 제약이 될 수 있다. 따라서 이를 극복하기 위해 비동기 임포트 ( 동적 임포트 ) 를 제공한다. if(true) { require(a); } else { require(b); } // strings-ko.js export const HELLO = '안녕하세요.' // strings-jp.js export const HELLO = '오하이요'; // strings-en.js export const HELLO = '하이' const SUPPORTED_LANGUAGES = ['ko', '..

ESM : ECMAScript 모듈 사실 CommonJS는 표준이 아니에요. 조금 역사를 이야기할 필요가 있는데, 아시다시피 JavaScript는 프론트 언어였습니다. 그런데 프론트에서는 HTML 문서 상에 script 태그를 이용해서 JavaScript 코드를 전역 상태로 사용하곤 했죠. 그러다 보니 당연히 모듈이 필요없었어요. 모든 게 하나의 전역 코드니깐요. 그렇지만 백엔드에서도 JavaScript가 쓰이기 시작하면서 모듈 시스템에 대한 고민이 생겨났고, 그 결과 사용자들이 고안해낸 게 CommonJS였죠. 그렇지만 이 CommonJS는 표준이 되지는 못했습니다. 아마도 그 이유는, ECMAScript가 프론트, 백에 따라 같은 언어, 다른 표기로 나뉘는 걸 꺼렸기 때문인 거 같아요. 그래서 ECM..

이 글은 Node.js 디자인 패턴 바이블이라는 책을 기반으로 하고 있어요. 이 글은 CommonJS에 대해서 말하고 있어요. 이 글은 원래 스터디 발표 용도로 작성된 거에요. 😎 require() : 해결 (resolve) 알고리즘 const myJsCode = require("./myJsCode"); // .js는 생략 가능하다. const path = require("path"); const express = require("express"); 해결 알고리즘은 크게 다음 세 가지로 나눌 수 있어요. 파일 모듈 : 상대 경로로 작성되었는가? 코어 모듈 : 파일 명만이 언급되었는가? 패키지 모듈 : 코어 모듈에서 해당 파일을 찾을 수 없는가? ( => node_modules) 우리는 require로 이..

Express의 구조 ( Router, Route, Layer ) 잠깐 쉬어가는 느낌으로, 그림을 가지고 설명합니다. 플로우 차트 기호 같은 걸 전혀 모르셔도 좋습니다. ( 애초에 프로그램 시작 말고는 그걸 따르지도 않았습니다. ) 지금 생각하니 괜히 코드를 넣었나 싶네요. 처음에 프로그램이 시작하면 express() 함수는 application을 만듭니다. application은 생성됨과 동시에 HTTP의 각 메서드들에 handler 함수를 등록하는 함수를 만듭니다. 이후 app.get, app.post 등과 같이 첫 번째 파라미터로 path를, 두 번째 파라미터로 handler 함수를 전달해주면 아까 생성된 함수들이 동작합니다. 앞에 get, post 등 HTTP 메서드 이름으로 함수를 실행합니다. ..

Router의 필요성 application은 어쩌면 Router라고 봐도 될지 모르겠습니다. 갑자기 이런 말을 하는 게 의아할 수 있겠습니다만, 사실 앞서 구현한 코드에는 Application 하나만이 존재할 뿐, 다른 Router는 존재하지 않습니다. "그래도 사용하는 데에는 아무런 문제가 없지 않았나요?" 그렇습니다. 아직 path 기능이 완벽하진 않고 ( 지금은 완벽하게 매칭되어야만 하니깐요. ), 그 외에도 추가해야 할 게 산더미처럼 많지만, 어쨌든 원하는대로 동작하는 것을 볼 수 있긴 했습니다. 그렇지만 이렇게 되면 결국 한 덩어리로 만드는 것입니다. 당연히 코드가 길어질수록 힘들어질 것입니다. 앞서 app이라는 함수에 if문으로 분기 처리하는 게 지저분했기 때문에 분리한 거잖아요? 결국 같은 ..

URL에 따라 다르게 동작하기 메서드에 대한 고민은 일단 접어둡시다. 메서드는 오직 GET 하나만 가능한 서버를 만들 겁니다. 일단 편의 상 경로는 아래처럼 세 가지가 있다고 가정하고 해봅시다. / /cats /dogs 세 가지 경로에 대해서 분기를 한다고 하면 이렇게도 가능할 것입니다. const TExpress = () => (req, res) => { console.log("Current URL is : ", req.url); if (req.url === "/") { res.setHeader("Content-Type", "text/plain"); res.end("root."); } else if (req.url === "/cats") { res.setHeader("Content-Type", "tex..

나는 express를 알고 있을까? const http = require("http"); const app = require("./app.js"); const server = http.createServer(app); server.listen(PORT, () => console.log("Server is opened.")); 일반적으로 node.js와 Express.js를 사용해 서버를 만든다면 위의 코드는 공통으로 들어갈 것입니다. 그렇기 때문에 위 코드를 이해하는 데에는 큰 어려움이 없을 것 같습니다. 그런데 공부를 하면서 헷갈리는 부분이 참 많았죠. 하지만 당장 서버를 만드는 데에 필요한 것 같지는 않아 방치하다 이제야 그 고민을 마주합니다. Framework는 뭐지? Server와 Express의..

소개 NestJS는 Express ( 또는 fastify ) 위에 추상화된 프레임워크로, 기존의 라이브러리와 호환되면서도 이전의 프레임워크보다 더 빠른 성능을 보여준다. NestJS의 특징에 대해서는, JavaScript 개발자마다 호불호가 갈릴 수 있는 부분이지만, ES6보다도 더 진보적인 JavaScript를 사용한다. 예컨대 NestJS에서 핵심이 되는 데코레이터 패턴은 ES7이며, 현재로서는 TypeScript의 도움 없이는 사용할 수가 없고, 객체지향이라는 점 역시도 쟁점이 될 수 있겠다. 그러나 JavaScript라는 언어에 어울리는가에 대한 문제를 차치하면, NestJS가 성능이나 확장성 등, 철학으로 내세운 부분에 있어서는 확실히 기존 프레임워크보다 낫다. 내가 기존의 API를 NestJS..