node module을 처음 접해서 사용하다 보면 많은 사람이 갖게 되는 질문인데, 다음 글에 간단명료하게 정의되어 있다.

Difference between “module.exports” and “exports” in the CommonJs Module System – Stack Overflow

결국, 다음 코드로 간단히 설명된다.

var module = { exports: {} };
var exports = module.exports;

// your code

return module.exports;

exports의 property에 설정된 것은 문제없지만, exports 자체를 다른 것으로 설정해서 바꿔버리면 module.exports와의 연결고리가 끊어지게 되므로 이점 주의해야 한다.

좀 더 자세히 설명해놓은 글: Node.js Module – exports vs module.exports

module.exports.*exports.* 모두 다 함께 쓸 수 있다고 해서 번갈아 혼합해서 쓸 필요는 없고, module.exports.*의 존재 자체는 이해하되 일관성 있게 exports.*를 애용해서 사용해 줄 것을 권장한다.

꼬리표:
Function.prototype.throttle = function(n) {
  var fn = this;
  var throttled = false;
  return function() {
    if (throttled) return;
    throttled = true;
    fn.apply(null, arguments);
    setTimeout(function() {
      throttled = false;
    }, n);
  };
};

가령 window.onscroll event에 심어놓은 function이 불필요하게 너무 자주 실행되는 것을 방지하려는 목적으로 사용될 수 있는데, 간단한 사용법으로 다음과 같이 적용할 수 있다.

var logTest = function() {
  console.log('test');
};

window.onscroll = logTest.throttle(1000);

이렇게 해놓으면, 최대 1초에 한 번씩만 등록된 함수가 실행되면서 콘솔에 해당 메시지가 찍히는 것을 볼 수 있다. 비슷한 함수로 Underscore.jsLo-Dash에서도 모두 throttle이란 이름의 함수를 함께 제공하고 있음.

따온 곳: Functional Javascript Tools & Tricks – Tim Ruffles on Vimeo

가끔 웹페이지에 걸려있는 링크를 타고 들어가 보면 타이머를 걸어 놓고서 일정 시간이 지난 후에야, 가령 특정 form의 자료 입력과 같은, 작업을 진행할 수 있게 해 놓은 곳과 마주치곤 한다. 보통 링크 클릭을 통한 광고와 수익의 창출을 목적으로 이런 현상이 퍼지는데, 이럴 때마다 불편함과 함께 은근 짜증을 일으키게 한다.

그래서 이런 때를 대비해서 아래와 같은 JavaScript timers의 지연 시간을 아주 짧게 써는 실험 목적의 주문을 만들어 봤다. 주문이 잘 먹히면 더딤 없는 쾌속 진행의 길을 뚫을 수 있다. (물론, 사이트에서 어떤 추가 확인장치를 해 놓은 곳이라면 이것도 별 소용이 없겠지만.)

var originalInterval = this.setInterval, originalTimeout = this.setTimeout;
this.setInterval = function(func, delay) {
  originalInterval(func, 10);
};
this.setTimeout = function(func, delay) {
  originalTimeout(func, 10);
};

이를 이용한 간편 사용 목적의 bookmarklet: fastTimer – 가속기가 달린 고장난(?) Timer.

꼬리표:

CSS3에서 새로 소개된 rem(root em) unit은 em unit과 마찬가지로 상대성을 띤 Relative length units 중 하나지만, 기존 부모 요소를 기준으로 한 em unit과 달리 root element, 그러니까 html element를 기준으로 그 크기 값이 정해지면서 부모 요소의 중첩으로 생기는 뻥튀기의 부작용을 걱정할 필요가 없다는 것이 장점이다.

그래서, 어느 하나의 요소를 기준으로 또 다른 요소의 상대적 크기를 정해주고 싶을 때 많이 사용되는데, 문젠 언제나 그렇듯 IE < 9을 포함해서 아직 만족스럽지 못한 rem unit의 브라우저 지원 상황을 고려해서, 미지원 브라우저에서도 인식되도록 적절한 대응 값을 함께 정의해 줘야 하는 성가심이 있다.

이런 상황에서 SaasLESS 혹은 Stylus와 같은 CSS pre-processor의 힘을 빌린다면 효율적인 CSS 작성에 큰 도움이 된다는 것은 이미 잘 알려져 있다. 하나의 좋은 본보기로, CSS pre-processor를 써서 rem unit의 fallback을 구현한 예.

한편 아래는 실험 삼아 지금 한창 논의되고 있는 CSS VariablesCalc() function만을 써서 rem unit의 fallback을 구현해 보았는데, 여기에 꼭 안성맞춤으로 CSS polyfill임을 자처하면서 지금 한창 개발중인 또 하나의 CSS preprocessor인 Myth의 힘을 빌려서 바로 적용해 보았다.

:root {
  var-base-font-size: 10;
  var-body-font-size: 14;
  var-heading1-font-size: 18;
}

html {
  font-size: calc(var(base-font-size) / 16 * 100%);
}

body {
  font-size: calc(0px + var(body-font-size));
  font-size: calc(0rem + var(body-font-size) / var(base-font-size));
}

h1 {
  font-size: calc(0px + var(heading1-font-size));
  font-size: calc(0rem + var(heading1-font-size) / var(base-font-size));
}

이렇게 작성된 CSS는 Myth를 통해 다음과 같이 변환된다.
CSS Variables와 Calc() function을 써서 rem unit의 fallback 구현하기 제목의 글 마저 읽기 »

보통 JavaScript function을 작성하다 보면, 경우에 따라 딱히 정해져 있지 않은 수의 parameters를 받아서 처리해야 할 때가 있다. 이럴 땐, 아래 코드처럼 전달된 각 parameter의 타입을 확인해서 전달받지 못한 놈은 미리 정해진 기본값을 지정해서 사용하는 패턴이 많이 쓰인다.

function foo(a, b) {
  a = typeof a !== 'undefined' ? a : 'default_a';
  b = typeof b !== 'undefined' ? b : 'default_b';
  ...
}

이런 사용 패턴의 쓰임새가 점점 늘어남에 따라, ECMAScript 6에선 parameters에 default values를 아주 쉽게 지정할 수 있는 용법이 제안되었는데, 그 사용 예를 들면 다음과 같다.

/* ECMAScript 6에 포함된 Default Function Parameters */
function multiply(a, b = 1) {
  return a * b;
}

multiply(5); // 5

참고로, ES6의 default function params 웹브라우저 지원 상황을 보면, Firefox(v.15 이상)에서만 지원해서 아직 실제로 사용하기엔 이른 아쉬움이 있다.

그런데 이렇게 function에 전달할 parameters의 개수가 가령 세 개 이상으로 늘어나면 이에 대응하는 각 parameter의 타입을 확인하는 과정도 늘어날 수밖에 없고, 또 전달된 parameters의 순서도 그 결과 값에 중대한 영향을 미치게 된다. 이는 실제 function 사용 시 parameter의 순서를 착각해서 다르게 전달한다면 커다란 문제를 일으키게 될 소지가 있으므로 주의해야 한다.
JavaScript function의 default parameters 설정 법 제목의 글 마저 읽기 »