나도 맹글었다. PathUI SVG 버전

라파엘이 좀 손에 익으니, 금방 맹글게 되네..
오랜만에 삼각함수 검색했다. ㅇㅎㅎ

코드 좀 정리해서 모듈로 배포해야지.
샘플 페이지는 >>> 여기에

몇가지 코드 정리할 필요가 있다.
1) 옵션을 뺄수있는 설정들 정리
2) 주석 정리
3) 모듈 테스트

주석빼면 100줄도 안되네.. ㅇㅎㅎ

자바스크립트 정규식에 대한 고찰..

오늘 미투머니 테스트 코드를 작성하다가 그동안 안개속에 쌓였던, 정규식의 맘을 헤아리게 되어 몇가지 공유합니다. 제가 말하고자 하는 내용은 사실 이 포스트에 다 있어요.

정규식 RegExp Vs String

정규식은 기본적으로 문자열 패턴을 응용한 놈입니다. 그러니 당연히 String 객체와는 뗄레야 뗄수가 없는 놈입니다. 생각해보면 너무나 당연한 사실을 그동안 크게 신경 안쓰고 있다가 이제야 깨달았네요.

정리하면,

정규식은 2가지 형태로 사용할수있습니다.
1. 정규표현식 객체(RegExp)를 사용하는 방법
2. 문자열 객체(String)의 정규식 메소드를 이용하는 방법

메소드만 정리하면 대강 이렇습니다.

RegExp.test() - Boolean 값을 리턴
RegExp.exec() - 매칭된 값을 Array로 리턴
String.split() -
String.match() -
String.replace() -
String.search() -


RegExp.test() Vs RegExp.exec() 의 성능 차이

일반적으로 두 메소드 중에서, test() 메소드의 성능이 더 좋다고 얘기합니다. 왜 그럴까요? 그냥 성능이 좋다고 하니까 그려려니 하나요? 여기엔 이유가 있습니다. 바로 캡쳐링이라는 기능 때문입니다. 캡쳐링은 패턴으로 찾은 놈을 따로 저장하는걸 얘기합니다.

앞의 두 메소드의 리턴값이 하나는 Boolean 이고 하나는 Array 인 점이 바로 여기에 있습니다. 당연히, test 메소드가 리턴값이 Boolean 이므로, 성능이 더 좋겠죠? 네! 맞습니다. 하지만 단순히 리턴값의 사이즈가 작다고 성능이 더 좋다고 얘기할수는 없습니다. 왜냐면, 결국 RegExp 객체가 찾은 패턴을 모두 가지고 있기 때문이죠. 따라서, test() 메소드만을 사용한다고 성능이 좋아지는 것은 아니랍니다. 정확히 얘기하면, 어떻게 패턴을 정의하냐에 따라 달라지겠죠!!

예를 들어보겠습니다.

var str = "테스트 테스트1 테스트2 테스트3 테스트4";
var regx = /테스트\d/;

regx.test(str); // true
regx.exec(str);  // ["테스트1"]

위와 같이 실행하면 test()는 true, exec()는 [“테스트1”] 배열을 반환합니다. 그리고 여기서 하나더! 위에서도 잠깐 언급했지만 두 메소드 모두 결국 RegExp 전역 객체를 사용하게 됩니다.

그러니까, 각 메소드를 실행하고 아래와 같이 RegExp 객체의 $_ 와 $1 값을 확인해보면,
모두 같음을 확인할수있습니다.

RegExp.$_  // 테스트 테스트1 테스트2 테스트3 테스트4"  - 테스트할 문자열
RegExp.$1  // ""  - 캡쳐링된 문자열

이 얘기는 결국, test() 메소드와 exec() 메소드의 내부 구현은 같되, 리턴값만 다름을 의미합니다. 즉, 현재 까진 리턴 사이즈 말고는 성능이 같다는 얘기죠~!!

이제 좀 변형해봅시다. RegExp 객체에 패턴을 저장하기 위한 캡쳐링 옵션을 줘보도록 하지요. regx = /(테스트)/ 로 바꿔서 해봅시다.

var str = "테스트 테스트1 테스트2 테스트3";
var regx = /(테스트\d)/;

regx.test(str);  // true
regx.exec(str);  // ["테스트1", "테스트1"]
RegExp.$1;       //"테스트1"    - test(), exex() 모두 같음.

뭐가 다른지 감이 오나요? exec()가 뱉어내는 리턴값을 유심히 보세요. 아직 모르시겠나요?
캡쳐링은 매핑된 결과를 RegExp 객체가 내부에 저장한다고 앞서 말씀 드렸습니다.
바로 그 캡쳐링된 결과를 RegExp.$1, RegExp.$2 등으로 읽어올수있습니다.
물론 캡쳐링은 하나의 패턴안에서 괄호를 여러번 사용함으로써 저장할수 있습니다.

가령, 이렇게 쓸수도 있다는거죠!!

var str = "테스트 테스트1 테스트2 테스트3";
var regx = /(테스트)\s(테스트\d)/;

regx.exec(str);   // ["테스트 테스트1", "테스트", "테스트1"]

자 이제 exec()의 리턴값의 구성을 이해하시겠죠?

[매칭된 문자열, 캡쳐링된 첫번째값, 캡쳐링된 2번째값, 캡쳐링된 3번째 값, … , 캡쳐링된 N번째 값]

이젠 RegExp에 저장하지 않도록 비캡쳐링(?:xxx) 옵션을 주고 하나 더 해보죠.

var str = "테스트 테스트1 테스트2 테스트3";
var regx = /(?:테스트\d)/;

regx.test(str);  // true
regx.exec(str);  // ["테스트1"]
RegExp.$1;       //  ""    - test(), exex() 모두 같음.

자~~ 이젠 어떤 차이가 있지는 아시나요? 여전히 모르시겠다구요? 비캡쳐링(?:) 옵션을 사용해서 RegExp 에 찾은 패턴값을 저장하지 않았습니다. 그러니까 exec() 리턴값에도 찾은 패턴값이 넘어오지 않게 되죠?

자 그럼, exec() 리턴값의 구성을  한번더 정리해보죠~

[매칭된 문자열, RegExp.$1, RegExp.$2, RegExp.$3, … , RegExp.$N]

마지막으로 그럼,

도대체 성능과는 무슨 관계가 있는거냐?

이 질문에 답할 시간입니다. 이미 눈치채고 계신분이라면, 조용히 닫기버튼을 누르셔도 됩니다. test()와 exec() 메소드의 성능차이는 간단합니다. 이렇게 정리하도록 하죠!

“간단한 패턴 문자가 있는지 없는지를 확인할 땐, 비캡쳐링과 test() 메소드 조합을 사용해라!

되셨나요? 이렇게 얘기 할수도 있습니다.

“test() 메소드를 사용할때는 반드시 비캡쳐링 패턴으로 정의해라!”

그 이유는 앞서 주구장창 설명한 캡쳐링되어 저장된 값 때문입니다.

패턴 플래그 g 에 대한 고찰

이제 오늘 깨달은 것의 하일라이트!! 바로 g 플래그 옵션입니다. 패턴 플래그는 총 3가지가 있죠. i, g, m 뭐 다 아실꺼라 생각하고 각각의 설명은 생략합니다. 모르면 검색해보아요~

이제 g에 일반적으로 알려진 사실을 흔히 쓰는 예제로 보면, 아래와 같습니다.

var str1 = "No pain, No gain!";
var str2= str1.replace(/ain/g, "XXX"); // str2 = "No pXXX, No gXXX!"

즉, “g 옵션을 쓰면, 모든 패턴을 찾게 된다.” Global 의 G 가 바로 그 g 옵션인거죠..

그러면, 얼핏 이런 사실을 알고 있을때, 지금껏 제가 착각해왔던 것은 아래와 같은 겁니다.
앞에서 해왔던 예제를 이어봅니다.

var str = "테스트 테스트1 테스트2 테스트3";
var regx = /(테스트\d)/g;

regx.exec(str);  // ["테스트1", "테스트2", "테스트3"] 일까요???????

g는 글로벌 옵션이니까,.. 저렇게 나와야 하는게 아닐까?.. 하는거죠!! 결론부터 얘기하면 아닙니다! 왜인지는 아시겠죠? 아직도 그 이율 모르겠다면 앞에서 설명한 exec() 메소드의 리턴값 구성을 다시한번 보세요.

그러면 이렇게 해보죠..

var str = "테스트 테스트1 테스트2 테스트3";
var regx = /(테스트\d)/g;

regx.exec(str);  // 1번 실행, ["테스트1", "테스트1"]
regx.exec(str);  // 연속해서 두번 실행, ["테스트2", "테스트2"]
regx.exec(str);  // 연속해서 세번 실행, ["테스트3", "테스트3"]
RegExp.$1;  // "테스트3"

오잉? 저렇게 나올껄 예상 하셨나요? 올~~ 예상했다면, 당신은 규식이를 잘 하는 분입니다.
아직도 모르겠다구요? 글로벌 옵션이긴 하지만, 적어도 제가 기대했던 것과는 사뭇 다릅니다.

자 그럼 g 옵션의 비밀을 정리해보죠.. 정리하면,

패턴 플래그 g 옵션은 연속해서 패턴을 찾을때
다음 패턴 검색을 위해 RegExp 객체에 패턴 검색의 시작 위치를 저장해 둔다.


이해되셨나요? 앞에 예제를 곱씹어보세요~ ^^

test() 메소드와 exec() 메소드는 리턴값이 다른 만큼 분명 그 쓰임도 다릅니다.
따라서, 패턴을 어떻게 정의하느냐에 따라서 RegExp 객체에 얼마나 많은 정보가 캡춰링 되어 저장되는지 그 비효율성도 고민하셔야 합니다. 여기까집니다.

도움이 되셨나요? 도움이 되셨다면, 리플이나 광고라도 한번 눌러주세요.

IE에서 innerHTML 사용시 주의해야할 점

일단, 발행하기 전에 정리부터 하자..
예제는 나중에 정리하고.. 생각나는대로 써보면,..
대충 정리해보면 아래와 같다.

1. DOM 노드 캐싱
DOM을 캐싱할때는,.. 캐싱하려는 노드를 cloneNode(true)로 떠서 캐시하자..
그렇치 않으면, IE에서는 innerHTML로 해당 노드를 날렸을때,. 캐시한 노드까지 날라간다.
반면, IE외의 다른 브라우저에서는 innerHTML로 해당 노드를 날렸을때..
해당 노드만 날라가고, 캐시한 노드는 그대로 있다.
[하나 더 주의] – cloneNode를 할 경우, 바인딩된 이벤트는 복사되지 않는다.!

2. 메모리 누수
모든 브라우저가 innerHTML로 엘리먼트를 교체하면, 엘리먼트가 걸려있는 이벤트 핸들러들이
날아가 버린다. 보다 정확한 의미는 참조를 잃어버린다!!
때문에 참조를 잃어버린 이벤트 핸들러들은 영영 해제할 길이 없어 메모리 누수가 생긴다.

따라서, 엘리먼트 교체를 해야할 경우엔, 이벤트 핸들러를 먼저 제거해주거나..
앞에서 얘기한 노드를 캐싱하거나..
아니면, HTML로 날릴만한 엘리먼트엔 이벤트 핸들러를 걸지말고, 그 상위 노드에 걸어서
버블링 처리를 해라~!!

3. HTML 렌더링
HTML을 innerHTML로 재할당을 할경우, 브라우저는 재할당한 부분만 랜더링을 다시하게 된다.
이때, 구식브라우저(꼬진브라우저, 느린브라우저)인 IE6에서는 랜더링 할때, 생각보다 속도가 느리다.
그래서 아래와 같이 사용하게 되면,..

node.innerHTML = “<div>….중간생략 복잡한 디비전 태그 교체…</div>”
doSomethingHere();

doSomethingHere() 함수 안에서 새로 랜더링 되는 엘리먼트의 width나 height 등을 가지고 뭔 짓꺼리를 하게 되면,
IE6에서는 htmlfile 에러는 내뱉는다.

이유는 앞서 설명했듯이 랜더링 속도가 느려서 발생하는 문제로…
로드 된후, 실행시 까지 약간의 딜레이를 주거나,
인터벌울 돌려서 렌더링이 됐는지 체크를 한다.

난 걍 랜더링시 문제가 될경우에 한에서만 이렇게 쓴다.

el.innerHTML = sTpl;
var oInstance = this;
setTimeout(function(){
          oInstance._initialize();
}, 100);

4. htmlfile 에러
그밖에 IE6혹은 IE7에서 htmlfile 에러가 발생하는 경우가 있는데 아래와 같은 경우가 있다.

  1. 붙이려는 노드가 읽기 전용 속성의 태그이고, 거기에 ID 값을 부여해서 innerHTML 할 경우
    ** IE에서 COL COLGROUP FRAMESET HTML STYLE TABLE TBODY TFOOT THEAD TITLE TR 개체등은 ID 필드가 읽기전용 속성이고 그 외의 개체에서는 모두 읽기/쓰기가 된다.
  2. 기본 HTML 구조 규칙을 깨는 경우,
    예를 들면, LI 엘리먼트 하위에 다시 LI 노드를 자식으로 넣는 경우가 있겠다.
    이 경우는 실제로 겪었던 부분으로, li 자식 노드로 li를 넣는 바보같은 짓을 범했다. 이런 경우가 흔하지 않는 경우인데, 안타까운건 FF 에서는 li 하위에 li 를 짚어 넣어도 아무런 에러를 발생시키지 않는 다는 것이다. 


5. FireBug를 믿지마라!

보통 FireFox의 플러그인 인 firebug 를 이용해서 디버깅을 하게되는데, FF 는 너무나 관대(?)해서,
IE에서 뱉는 에러를 몇몇가지를 그냥 쌩까고 혹은 아~ 이건 개발자 실수니까,..스마트(?) 하게 알아서 정정해준다.
즉, FF만 믿고 개발했다가는 IE 호환성에 적신호를 받게 될것이다.
그렇다고, firebug 가 구리다는건 아니고, 간간히 중간중간 때때로, 생각날때, IE 브라우저로 테스트를 해보는 습관을 갖는게 좋겠다.

추천하는 바는 그냥  IE6 브라우저를 버리고 갔으면 한다. (그냥 개인적인 바램~ OTL… ㅜㅜ )
하지만 현실은 시궁창… ㅎㅎ