[저번]에 이어 이번에는 크롬개발자 깨알팁
가끔 아래와 같이 찍힌 로그를 복사하고 싶을 때가 있다.
이럴 때 보통 그냥 drag해서 선택한 다음에 ctrl + c , ctrl + v로 하는데 이러면 나중에 정리해야 하고 불편하다. 그 때는 copy라는 메서드를 쓰면 객체가 클립보드에 저장된다.
copy(obj);
근데 문제는 변수에 담기지 않은 상태 즉, 위에 처럼 이미 로깅된 객체를 어떻게 copy메서드를 쓴단 말인가? -_-;
이 때. 알고 있으면 도움되는 깨알팁.
내가 저장하고 싶은 객체에 오른쪽 마우스를 클릭하면 아래(Store as Global Variable)처럼 나옴.
이를 선택하면 global영역에 임시 변수로 저장된다.
그리고 나서 copy(temp1); 하면 됨.
토요일인가? 트위터에서 t3js[링크]라는 프레임워크를 만들었다는 트윗을 보고 이건 뭔가하고 주말에 와이프가 드라마를 보는 틈을 타 잠깐 살펴봤다.
t3js을 만든 사람이 니콜라스 자카스[링크]라고 다수의 JS책을 쓰고 JS관련 컨설팅을 하다가 최근에 프로필을 보니 BOX에서 수석 아키텍트를 하고 있다. 이 사람 낸 책 중 번역서는 대부분 봤는데[링크] 다 괜찮았던 책이고 아티클도 꾸준히 쓰는 편이라 신뢰감이 있었다.
먼저, 간단하게 설명을 한면 t3js는 아래 4가지를 알 필요가 있다.
Application - Module과 service을 관리하고 메시지를 전달한다. 모듈간의 커뮤니케이션과 라이프사이클등등 .(하나만 존재)
Module - 흔히 얘기하는 Component같은 역할이다. 돔에 이벤트를 바인딩하는등 application의 비지니스 로직을 담당한다.
Behavior - Module의 중복되는 부분을 뽑아 behavior을 만든 후 moudule에서 사용한다.(사실 module의 공통 부분이라고 생각하면된다)
Service - 유틸리티 같은 코드를 집합이다.(비지니스 로직을 제외한 외부 라이브러리 등등)
이 4가지의 역할을 다이어그램으로 표시하면 아래와 같다.
특징은 보는 것과 같이 module간 커뮤니케이션을 할 수 없고 Application을 통해서만 모뮬간 커뮤니션을 한다. 그리고 jQuery의 의존성을 가지며, 제거할 예정이고 [이슈]에 다양한 라이브러리를 사용할 수 있도록 제안하는 내용이 있어 어떻게 변할지는 모르겠다.
개인적으로 생각하는 이런 류의 프레임워크들에게 기대하는 포인트는 어떻게 메세지를 관리하는가 이다.
규모가 커지면 커질수록 메시지 관리 이슈가 너무 많다.
그래서 이런 문제를 사용자가 덜 겪도록 혹은 해결할 수 있도록 프레임워크에서 적절하게 제어해줘야하는데 t3js는 이런 문제를 실제로 고민했는지 모르지만, 내가 느끼기에 그런 고민을 한 것 같다.
그렇게 생각한 이유가 프레임워크를 만들면 기능을 넣고 싶은 유혹이 많은데... 대표적으로 메세지가 아니라 이벤트처럼 beforeA, afterA와 같은 걸 만들고 싶다. 근데 이걸 만들게 되는 순간 헬.. 그리고 다수개의 모듈을 관리하는 객체를 만들어서 관리하고 싶어지는데.. 이것도 만드는 순간 처음에는 좋아보이지만 헬 열림.
여튼 전체적으로 최대한 간단하게 메세지를 처리하려고 한 디자인이 나뻐보이지 않는다. 그렇다고 세련됐다고 보기 힘들어 아쉽다.
그리고 다른 괜찮았던 점은 처음 코드를 볼 때 왜 module context라는 객체가 필요할까 라는 고민이 있었다.아래와 같이 module context객체는 사실상 application의 메서드를 호출하는 수준이다.
broadcast: function(name, data) { this.application.broadcast(name, data); }, getService: function(serviceName) { return this.application.getService(serviceName); },
그래서 이건 뭘까라는 고민하다가 테스트 작성하는 [문서]를 보고 테스트 때문임을 알았다. 괜찮은 아이디어.
아쉬운 점은 module의 사용법이 굉장히 어색하다.
먼저, 사용 가능한 이벤트가 한정적이고, 아래와 같이 이벤트를 처리하는 방식이 [data-type]속성으로 처리하는데 너무 어색하다.
<footer id="footer" data-module="footer"> <button id="clear-completed" data-type="clear-btn">Clear completed</button> </footer>
Application.addModule('footer', function(context) { return { onclick: function(event, element, elementType) { if (elementType === 'clear-btn') { // Do something } } }; });
나라면 elementType을 굳이 로직으로 처리해야 하나라는 생각이 들었다. 이런건 사실 delegate을 써서 안에서 처리해야 하는 내용일 것 같은데 아쉬웠다.
코드가 간단해서 간만에 재미있게 봤네.
ps. 근데 왜 t3인거지?
angular는 아주 옛날에 우연히 알게됐다. 그 당시에 자바스크립트 테스트에 엄청 관심이 많았던 때인데 google test blog에서 [공개]된 [jstestdriver]라는 도구를 보고 신선해 하며 좋아했다.[당시 사용기]
그래서 당시 개발자인 [misko]의 블로그를 보며 많은 도움을 받았다. 블로그 내용이 대부분은 테스트에 대한 내용이고 일부분은 흔하지 않은 FE Test에 대한 내용들이라 많은 인사이트를 얻곤 했다.
그러던 중 misko는 angular라는 자바스크립트 라이브러리를 만들었다며 [공개]를 했다. 지금은 해당 동영상이 없지만, 기억을 더듬어서 생각해보면 한 10분(?)만에 자바스크립트 없어 마크업과 속성으로만 자동완성(or TODO List)을 완성하는 동영상이였다. 지금 생각해보면 현재의 [directive]였던 것 같다.
그때 솔직한 느낌은 "이걸 누가 쓰지?"라는 생각을 했다.
그 이유는 당시의 상황은 IE6을 지원했던 시절이고, mail, calender..와 같이 나름 복잡한 UI들이 들어 있는 서비스를 개발하는 상황에서 단순히 프로그래밍 없이 속성으로 개발을 한다는 건 뭔가 현실을 알지 못하는 개발자가 만든 느낌이였다.
(참고로 예전 만큼은 아니지만, 아직도 angular을 좋아하는 편은 아니다)
한참이 지난 지금 시점에서 보면 angular는 전세계에서 손꼽히는 프레임워크가 됐다. 그래서 한편으론 어느 정도는 "misko가 정말 시대를 앞선 사람이였구나?.."라는 생각을 한다.
그리고 많은 사람들이 angular을 높게 평가하는 기능이 2 way binding인데 개인적으론 이 기능보다 misko의 백그라운드에서 나온 특징이라고 생각하는데.. DI을 통해 mocking하여 testability을 높여 주는 설계를 할 수 있게 해준걸 높게 평가한다.
이렇게 주저리 주저리 쓰게 된 계기가 지난 주말에 잠깐 angular 2을 보면서 "한번 더 뭔가 변하는구나.."는 생각이 들어 옛날 생각이 나서... 정리하게 됐다. ㅎㅎ
ps. backbone에 대한 추억이 있는데 언제 한번 정리해야겠다.
this에 대한 글들이 너무 많아서 굳이 설명하지 않아도 되는데 오늘 글을 읽다가 이상한 내용이 있어서 정리도 할 겸해서 글을 쓴다.
전에 함수형 자바스크립트[링크] 봤는데 최근에 보고 싶은 부분이 있어서 다시 보다가 잘못된 부분을 발견했다. 나의 책을 습관 중에 하나가 안다고 생각하는 부분을 건너 읽는데 이번에 자세히 보다가 발견. -_-;
어쨌든, 59 page에 보면 아래와 같은 글이 있다.
var bFunc = function(){return this}; var b = {name : "b", fun : bFunc}; b.fun(); //=> Window 같은 어떤 객체
"의도치 않은 일이 발생했다. 객체 인스턴스 외부에서 함수를 만들었다면 this는 전역 객체를 가리킨다. 따라서 나중에 bFunc를 b.fun필드로 바인딩해도 this객체는 b자신을 가르키지 않는다."
이건 완전 잘못된 설명이다. 처음에 번역이 잘못됐나하고 원서를 봤는데 역시 잘못되어있다. 그래서 재미있게 읽고 있는데 약간의 실망감이 들었다.
일단 많은 사람들이 this가 저자처럼 만들어 질 때 결정된다고 생각하는데 절대 아니다. this는 호출할 때 결정된다. 그래서 같은 함수는 어떻게 호출하냐에 따라 this가 결정되고 this는 실행환경에서는 변경되지 않는다.
위의 예를 들면, bFunc()을 호출하면 저자가 말한 것 처럼 global이다. node.js는 global, 브라우저는 window다. 근데 b.fun();을 호출하면 b객체를 가르킨다. 그럼 b.fun과 bFunc가 다른가? 똑같다. 즉, 호출하는 방법에 따라 this가 결정된다.
그럼 어떻게 결정될까?
복잡하게 설명하면 복잡한데 기본적으로 호출하는 메서드의 "."앞이 this고 없으면 global이다.
즉, b.fun()은 .앞에 b이기 때문에 this가 b이고, bFunc()는 없기 때문에 global(window)가 된다. 이것만 알아도 this을 이해하는데 대부분은 이해된다.
요약하면,
호출할 때 method의 "."앞부분이 this이고 없으면 global이다. this는 실행될 때 결정되고 실행 환경속에서는 변경할 수 없다.
