Coffeescript_javascript 기술 사용 방법 요약

Javascript의 로우키 동생으로서 Coffeescript는 정말 뛰어납니다. 이를 사용하면 개발 효율성을 높이고, 코드 오류를 줄일 수 있으며, 개발의 즐거움을 크게 높일 수 있다는 것이 핵심입니다. 가능하다면 내 프로젝트에 커피를 사용해야겠다는 생각이 점점 더 많아지고 있습니다.

그런데, 커피스크립트의 구문을 이해하고 시험해 볼 준비를 하고 나면 프로젝트에 어떻게 도입해야 할지 고민이 되시는 분들도 계실 텐데요.

상사처럼 코드를 지휘하세요

CoffeeScript는 다양한 멋진 배열 반복 방법을 제공합니다. 가장 좋은 점은 이것이 배열뿐만 아니라 jQuery 객체에서도 작동한다는 것입니다. 시적인 코드를 작성해 봅시다:

formValues = (elem.value for elem in $('.input')) 

이 코드 줄은 다음 Javascript로 변환됩니다.

var elem, formValues; 
formValues = (function() { 
 var _i, _len, _ref, _results; 
 _ref = $('.input'); 
 _results = []; 
 for (_i = 0, _len = _ref.length; _i < _len; _i++) { 
  elem = _ref[_i]; 
  _results.push(elem.value); 
 } 
 return _results; 
})(); 

솔직히 이런 코드를 작성하는 것은 처음에는 정말 두렵지만 일단 CoffeeScript의 마법을 받아들이기 시작하면 그 매력에 빠지게 될 것입니다.

일반적인 방법으로 바인딩

jQuery 콜백에서 "=""를 사용하면 메소드를 객체에 수동으로 바인딩하는 수고를 크게 줄일 수 있습니다. 몇 가지 코드를 살펴보겠습니다.

object = 
 func: -> $('#div').click => @element.css color: 'red' 

다음은 컴파일된 Javascript 출력입니다.

var object; 
var __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; }; 
object = { 
 func: function() { 
  return $('#div').click(__bind(function() { 
   return this.element.css({ 
    color: 'red' 
   }); 
  }, this)); 
 } 
}; 

코드의 @element는 object.element = $('#some_div')와 같이 다른 곳에 지정된 jQuery 객체를 가리킵니다.

"=>"를 사용하여 지정된 모든 콜백 함수는 자동으로 원본 개체에 바인딩됩니다. 그렇습니다.

2011년에는 함수를 이렇게 호출했습니다

이것 좀 보세요:

$.post( 
 "/posts/update_title" 
 new_title: input.val() 
 id: something 
 -> alert('done') 
 'json' 
) 

CoffeeScript를 사용하면 여러 매개변수를 여러 줄로 작성하여 호출할 수 있습니다. 쉼표와 중괄호는 선택 사항이므로 $.post() 및 $.animate()와 같이 jQuery에서 더 긴 서명이 있는 일부 메서드를 더 쉽게 읽을 수 있습니다. 또 다른 예는 다음과 같습니다.

$('#thing').animate 
 width: '+20px' 
 opacity: '0.5' 
 2000 
 'easeOutQuad' 

맛있는 커피죠? 첫 번째 매개변수는 익명 개체이므로 함수 호출에서 메타 괄호를 생략할 수도 있습니다.

초기화를 더 섹시하게 만들기

처음 jQuery를 사용하기 시작했을 때 페이지를 다음과 같이 초기화했습니다.

$(document).ready(function() { 
 some(); 
 init(); 
 calls(); 
}) 

CoffeeScript와 새 버전의 jQuery는 위의 코드를 더욱 멋지게 만들어줍니다.

$-> 
 some() 
 init() 
 calls() 

CoffeeScript의 함수 정의 구문은 이미 매우 훌륭하며 이러한 상황에서 사용할 수 있다는 점은 더욱 멋집니다. 콜백이 필요한 모든 함수 호출은 CoffeeScript에서 매우 간단하다는 것을 알게 될 것입니다.

사실 커피스크립트는 자바스크립트로 일대일로 번역이 가능하기 때문에 활용도가 매우 높은 언어입니다. 프로젝트에 도입하는 방법도 여러 가지가 있습니다. 여기서는 먼저 커피스크립트를 노드 프로젝트에 도입하는 방법을 요약하고, 각 방법의 장단점을 비교해보겠습니다.

커피 명령을 직접 사용하여 순수 커피스크립트 프로젝트 실행

일반적으로 커피스크립트를 언급하면 ​​자연스럽게 js의 그림자에서 벗어날 수 없는 자바스크립트의 동생이라는 생각이 들게 됩니다. 사실 독립된 언어라고 생각하시면 됩니다. 우리 모두는 노드 플랫폼에 전역적으로 커피 스크립트 패키지를 설치한 후 커피 명령을 통해 커피 스크립트 대화형 인터페이스에 들어갈 수 있다는 것을 알고 있습니다. 또한 이를 repl이라고 부를 수도 있습니다. 프로젝트가 완전히 커피로 작성된 경우 간단합니다. 예를 들어 입력 스크립트 이름이 "app.coffee"인 경우 다음을 실행하세요.

coffee app.coffee

注意，这里的扩展名coffee是不能省略的。

这个方式应该说是使用coffeescript最“官方”的方式。简单，直接！而且，一旦你以一个coffee文件作为项目的入口， 那整个项目就同时兼容coffee和js了。你在项目里可以任意require js或coffee文件及模块， 甚至可以在项目中的js文件中随便require coffee文件。并且在你引用无论是coffee还是js文件的时候都无需扩展名， 只要前面部分名称不冲突就行。

这个方式有个最大的问题就是，如果它作为一个模块，只能被用于coffee项目；如果他作为一个应用， 运行环境必须安装coffee-script。毕竟coffeescript现在还是一个小众语言，它作为模块时丧失了js用户实在可惜。

另一个也许存在的缺点是性能方面的，毕竟node里面只有js引擎，coffee代码需要先编译为js再运行， 这个过程是要消耗一点点时间的，尽管coffee到js的编译速度其实挺快的。不过这应该不是什么大问题， 一般来说，require都是写在文件的顶部，也就是应用在启动的时候就一气儿把该require的文件都require了， require的时候coffee就被编译成了js放到了js引擎中，那么编译消耗的那点时间都集中在了应用启动时， 运行时几乎不会遇到require新的coffee的情况了。node最常见的使用场景是web服务器，这就更没问题了。

在javascript项目中引用coffeescript

npm中的coffee-script既可以全局安装，也可以作为项目的一个模块安装。那coffee-script作为项目的一个模块有啥意义呢？ 其实是给项目添加了一个coffeescript的编译器，这个项目就可以在运行时随时编译coffee文件。

你一定希望像第一种方式里那样随便引用coffee文件。没问题，只需要注册一下。假如你的项目入口文件是app.js， 那么只需要在这个文件最前面加上这么一句：

require('coffee-script/register');

然后你就可以在项目中随便require coffee文件了。

这个方式本质上和第一种方式没啥区别，只不过coffee-script没安装在全局，因此你的模块可以独立存在， 作为应用也不需要环境安装好coffee-script了。

缺点嘛，我觉得最大的问题就是容易让代码有些乱，一会儿js，一会儿coffee，当然第一种方式也可能会这样， 不过都用coffee启动了里面应该不会写js了吧……总之我觉得一个项目还是把语言统一起来比较好 （遗憾的是我主要用这种方式，在一个已经用js写出了大体结构的项目里，我就想用coffee肿么办……）

性能问题上跟第一种方式一样，不多说了。

正统的方式——编译

一说编译，就感觉回到了正儿八经的C或Java的时代。的确，作为一个编译型语言，编译后再运行才是正道。 c有gcc，java有javac，cofee有coffee -c。

要编译一个cofee文件很简单，比如要编辑app.coffee这个文件，就在文件的当前目录执行：

coffee -c app.coffee

一个名为app.js的文件就出现在当前目录下了。这个指令也可以应用于目录， 比如你把项目中所有的coffee源文件放到了src目录下，那就执行：

coffee -c src

src目录及其各级子目录下的所有coffee源文件都会编译成js文件，放到和源文件相同的目录中。

不过对于大型项目，把源文件和编译结果文件放到一起可不太好。指定一个输出目录就行了：

coffee -c -o outputs src

这个指令的参数顺序有点奇怪。在coffee的帮助里是这么定义的：

coffee [options] path/to/script.coffee -- [args]

注意，所有的选项（options）都在coffee和文件路径之间。而最后的args是把目标文件作为脚本执行时给传递的参数。 也就是说所有的选项都放在coffee和文件名之间就可以了。 而-c这个选项是单独的，没有自己的参数，它只表示要把指令最后面提供的那个文件给编译了，所以写成这样也行：

coffee -o outputs -c src

假如想再加个选项，让编译结果不被自执行函数体包围，就是：

coffee -o outputs -c -b src

再假如想把所有源文件编译成一个名为out.js的目标文件，就是：

coffee -o outputs -c -j out src

如果每次改点代码都要这么执行指令也挺烦人的。coffee指令有一个选项-w可以监视源文件的变动而自动编译：

coffee -o outputs -c -w src

대규모 프로젝트의 경우 모든 개발자가 단 하나의 지시만으로 모든 컴파일 작업을 완료할 수 있도록 컴파일 방법을 미리 결정하는 것이 가장 좋습니다.

offee는 C 세계의 make와 유사한 자동화된 빌드 도구인 cake를 제공합니다. 그러나 공식 웹사이트에 명시된 바와 같이 cake는 매우 간단한 빌드 시스템입니다. 실제로 cake의 기능은 cakefile이라는 스크립트를 실행하는 것이며, cakefile 스크립트는 Coffeescript로 작성됩니다. 이 스크립트는 명령어와 해당 설명 및 실행 기능을 선언하는 데 사용되는 작업과 같은 매우 제한된 내장 기능만 제공합니다. 다른 하나는 순수 노드 프로젝트를 작성하는 것입니다. 컴파일을 완료하려면 node의 fs 모듈을 사용하여 커피 모듈에서 컴파일된 문자열을 출력하거나 child_process 모듈을 사용하여 쉘 명령을 실행해야 합니다. 실제로 케이크 구성의 대상이 반드시 커피일 필요는 없습니다. 실제로 노드 스크립트를 실행하고 자동화된 작업을 처리할 수 있기 때문입니다.

또한 유명한 Grunt 및 국내 fekit 등과 같이 커피 자동 편집을 완료할 수 있는 더 나은 타사 자동화 구성 도구가 있습니다.

이 정통 컴파일 방법은 가장 신뢰할 수 있으며 숙련된 프로그래머가 좋아해야 합니다. 이를 통해 팀은 고정된 개발 모델을 형성할 수 있습니다. 또한 컴파일된 프로젝트는 순수한 js 프로젝트가 되며, 애플리케이션으로 직접 실행되거나 다른 프로젝트에서 모듈로 참조되는 경우 추가 종속성이 필요하지 않습니다. 그리고 런타임에 컴파일을 할 필요가 없기 때문에 컴파일로 인한 성능 문제도 없습니다.

너무 번거롭다는 게 단점이다. 소규모 프로젝트를 수행하는 경우 cakefile을 생성하거나 grunt를 구성하는 데만 반나절이 걸리므로 그럴 가치가 없습니다.

jQuery, node.js, javascript에 커피스크립트를 도입하면서 커피스크립트에 대한 새로운 이해를 얻었나요?