코드 땜장이

 개발을 하다보면, 한번만 실행 되어야 하는 함수들도 있고, 또는 자주 실행하게 되면 성능상 문제가 되는경우가 있어서 몇 번실행 하였는지에 대해서 플래그값을 유지하면서 실행 하여야 하는 함수들이 있습니다.  그러한 경우에 사용 할 수 있는 lodash 함수가 있어서 소개시켜드리려 합니다. 1. once 사용    여러번 실행한다고 해도 한번만 실행 되게 하는 함수 입니다. 초기화용 함수를 작성할 때, 사용 하면 아주 편리하게 한번만 실행 되게 만들 수 있습니다. 앞으로 소개할 두개의 함수보다는 자주 사용하진 않습니다. 그 이유는 초기화시라고 했는데, 초기화시에 이벤트를 발생하는 라이브러리, 프레임워크가 많기 때문이죠. 2. debounce 사용  위의 함수 실행된것을 보면 console.timeLog가 함수 실행 이후 1초뒤에 실행 된 것을 볼 수 있다. 또한 callTest('third')의 경우에는 두번을 연속으로 실행 하였으나 한번만 실행 되었다. debounce호 생성된 함수는 호출 된 후에 몇ms이후 동안 함수 호출이 없다면, 해당 함수를 평가해준다.  위의 경우에는 많은 곳에서 사용 될 수 있다. 예를 들면 블로그를 작성하는 도중에 자동 저장을 시켜주기 위하여 타이밍을 잡는 경우라던지? 아니면 아이디의 중복확인을 버튼없이 적절한 타이밍에 실행 시켜주는 경우이다.  즉 이벤트가 자주 발생하지만, 마지막 단락의 순간이 중요한 타이밍이고, 실시간성이 보장되지 않아도 되는 경우이다. 웹, 앱을 사용하다 보면 위의 경우는 꽤나 자주 사용 되는 방식이라는 것을 느 낄 수 있을 것이다.  앞으로 자주 쓰게 될 것이니 있다는 것을 알고만 있자. 3. throttle 사용 throttle의 경우에는 위의 스크린샷 만으로는 특징을 확인 하기가 어려울 수 있다. throttle은 이벤트리스너의 수행의 간격을 조정한다고 보면 된다. 1 ~ 30초 동안 매 100ms마다 이벤트가 발생한다고 보자. 하지만 이벤트를 전부 처리하기 위해서 900ms정도가 필요하고

 eval is evil...... latte is horse. eval이라는 것을 많이 쓰긴했었다. 아 라떼라고 해봤자 10년전? 좀 더 된 이야기 일 것이다. 10년전 군대이야기였으니 말이다. 지금 보고 있는 분의 웹개발을 공부하기 시작 했을 때가, 2013년? 정도라면 한 번쯤 코드에서 볼까말까 한 함수일 것이다. eval 함수에 대한 간단한 소개를 해보자. eval은 문자열 형태의 코드를 실행 할 수 있게 해준다. eval은 문자열의 형태의코드를 평가 할 수 있게 해준다. let value = eval ( '1+1' ) alert ( value ) // 2 let value = 5 eval ( 'value = 10' ) alert ( value ) // 10 eval ( 'let value = 10' ) alert (value) // Uncaught ReferenceError: value is not defined 위의 내용을 보면 적당히 감을 잡아볼 수 있을 것이다. 그런데 왜 썻을까? 저런 코드를... 아무리 보아도 합당한 내용이 떠오르지 않을 수 있다. 하지만, 그 옛날의 코드들이라면 이해 할 수 있을지 모른다. 뭐 실제로 나도 썼으니까...... 간단하게 얘기 하자면, 그 옛날은 프런트엔드 코드가 그렇게 아름답지만은 않았다. 뭐 지금도 몇몇 부분들에 대해서는 아름답다고는 말할 수 없지만...... 지금과는 달리 대부분의 로직들이 백엔드로 빠져있었고 백엔드에서 프런트엔드에 이런 상황에는 이런코드를 실행해 달라는 식으로 밀어넣었던 것이다. 즉 프런트엔드에서 백엔드와의 상호 작용으로 어떤 이벤트의 결과 데이터를 프런트엔드에서 확인 하여 이러한 상황에서는 이 함수를 실행 하여야 해! 이런식으로 능동적인 코드가 아닌. 백엔드에서 프런트엔드에서 이러한 데이터가 들어왔고 이러한 상황이니 프런트엔드가 실행할 코드를 짜서 내려주는 방식이었다. 그때는 그럴수 있었던게 프런트엔드가 할 일이 많았던 상황이 아니었다. 웹 개

 Observer 시리즈 중 세번째 Mutation Observer이다. 내 경험에서는 이용 빈도는 낮은 편이나, 현실에서도 그렇고 프로그래밍에서도 변화를 감지하는 것은 꽤 당황할 수 있는 요구라서 이런 내용도 있구나 라는 것을 인지 시키기 위해서 포스팅을 쓴다.  당연하게도 내가 제어하고 있는 엘리먼트의 변화를 감지할 필요는 많지는 않을 것이다. 하지만, 타인이 만든 라이브러리 특히 옛날에 만들어진 라이브러리를 사용을 하게 된다면, 사용해야 할 가능성이 꽤나 높다. 조금 더 자세하게 얘기해보자면 vue.js를 사용 하고 있는데, jQuery UI라이브러리를 사용 해야 하는 경우가 있을 수 있겠다.  뭐 당연하게도 위에 들은 예시는 최대한 있으면 안되는 행동이나 세상이 그렇게 깨끗하지는 않기에 예시를 들어보았다.   간단하게 예제를 만들어 보았다.  당연하게도 appendChild 함수나 setColor함수에 writeLog 함수를 작성하지 않고, MutationObserver를 통해서만 writeLog를 호출 한것으로 처리 되고 있다.

 DOM의 크기를 감시해보자!  DOM의 크기 변화를 감지해야하는 상황은 그렇게 많지는 않다. 하지만 언젠가는 필요할 때가 있다. 당연하게도 이런형태의 옵저버가 있다는 것은 아무리 미디어쿼리로 처리를 한다고 해도 한계가 있으니 스크립트에서 구현 하는 것밖에는 답이 없는 상황이던가, 미디어쿼리로 처리하는 것보다 스크립트에서 간단하게 처리가 되는 경우도 있다고 볼수 있을 것이다.  ResizeObserver의 적용 방법은 매우 간단하다. ResizeObserver 객체를 생성하면서 변경시 처리할 콜백 함수를 제공하고, 해당 객체로 감지한 DOM을 observe 해준다.  이렇게만 하면 완료가 된다. 간단하게 예제 하나만으로 사용 법을 다 익힐 수가 있으니 아래의 코드를 확인해보자. 예제 코드를 보면 정말로 별거 없는 코드이다. 하지만, ResizeObserver를 사용 하지 않고 옛날 코드스타일 대로 해당 기능을 구현한다고 생각하면, 꽤나 귀찮은 작업이면서 성능도 떨어질 것이므로 소개를 해보았다. 옛날코드 다시읽기 소재로 나중에 한번 옛날 코드를 소개해줄 기회가 있을지도 모르겠다.