코드 땜장이

 프로그래밍을 하다 보면, 두 배열 간의 연산이 필요한 경우가 많다. A배열에서 B배열에 있는 값을 제거한 C배열, A배열과 B배열에 같은 값만 추려낸 C배열, A배열과 B배열에 있는 값을 모두 갖고 있는 C배열.  차집합, 교집합, 합집합을 떠올렸다면 맞는 말이다. 지난 번에 소개한 lodash에 전부 가능하다.  차집합  1. _.difference  가장 간단한 함수이다. 두 배열 A와 B간의 차집합을 구한다. const a = [ 1 , 2 , 3 ] const b = [ 2 , 4 ] _. difference (a , b) // [1, 3]  A배열에서 B배열의 차집합을 구하기 때문에 1, 3을 구할 수 있다. 해당 함수는 원시값은 가능 하지만 레퍼런스 형에서는 아래처럼 모두 다른 값으로 판단 되기 때문에 전부 리턴한다. const a = [{ x : 1 } , { x : 2 } , { x : 3 }] const b = [{ x : 2 } , { x : 4 }] _. difference (a , b) // [{ x: 1 }, { x: 2 }, { x: 3 }]  2. _.differenceBy  특정 속성의 값을 비교하거나, 특정 값으로 변경하여 비교해야 하는 경우 필요하다. 바로 위와 같은 경우이다.  바로 아래와 같이 x를 확인하게도 만들 수 있다. const a = [{ x : 1 } , { x : 2 } , { x : 3 }] const b = [{ x : 2 } , { x : 4 }] _. differenceBy (a , b , 'x' ) // [{ x: 1 }, { x: 3 }]  또한 아래와 같이 특정 속성값이 아니라, 특정 속성들을 가지고 비교해야 할 수 있다. const a = [{ x : 1 , y : 2 /* ,v: 2*/ } , { x : 1 , y : 4 /* ,v: 4*/ } , { x : 2 , y : 2 /* ,v: 4*/ }] cons...

  나는 특이한 문제를 좋아하는 편이다. 오늘은 최근에 본 특이한 문제를 소개 한번 해보도록 하겠다.  x !== x const x = ? if ( x !== x ) { console . log ( 'Hello, world!' ) }  x를 정의해서 'Hello, world!'를 출력 할 수 있을까? !==는 불일치 연산자이다. 값과 타입을 다른지 판별을 한다. 그런데 x가 x가 아니게 만들라니 참 특이한 문제이다.   == 왜 쓰지 말라는 걸까?  물론 위의 문제를 해당 포스트에서 제기하였다. ===(일치연산자)는 만능이 아니다.  x = NaN 이게 된다면, x !== x의 값이 참이되게 된다.  x === x + 1 const x = ? if ( x === x + 1 ) { console . log ( 'Hello, world!' ) }  이 문제는 무엇일까? === 일치연산자인데 x와 x + 1이 현실에서 똑같을리 없다. 뭐 물론 x < x + 1 이 값이 참이 되는 경우는 C언어를 공부하다보면 알게 되었을 것이다. 뭐 그렇다 오버플로우이다.  자바스크립트에서 허용 되는 가장 큰값 Number.MAX_SAFE_INTEGER(9007199254740991)에 1을 더하면 어떻게 될까? 자바스크립트에서는 그냥 더해질 뿐이다. (9007199254740992)  그렇다면  Number.MAX_SAFE_INTEGER(900719925474099 1 )에 2 를 더하면 어떻게 될까? 결과는 900719925474099 2  우리가 계산으로 컴퓨터를 이겼다.    당연히 우리는 900719925474099 3 인 것을 알고있다.  뭐 내용을 따져보면 IEEE-754(부동소수점 어쩌고저쩌고)  Number.MAX_SAFE_INTEGER의 이상의 값에서는 반올림을 하기 때문이라고 한다.  즉, x ...

  이벤트 버블링 및 이벤트 캡처는 이벤트의 흐름에 대해 설명 할 때 자주 언급 되는 단어이다. 하지만, 이벤트 캡처의 경우 특별한 설정 없이는 잘 상용 되지 않는 흐름이다 보니 해당 내용은 잘 모를 수 있다.  이번 포스팅에서 이야기 하고자 하는 내용은, 아래의 옵션이다.  addEventListener(type, listener, useCapture ) 이벤트 리스터를 등록 할 때 useCapture인자를 줄 수 있는데, 이건 과연 뭘까? 간단하게 알아보자.  이벤트  이벤트는 무엇일까? 간단하게 말하면 javascript와 html간에 상호작용을 말할 수 있다. 가장 간단한 예로는 click이벤트 가 있을 것이다. html에서 click이 발생 했을때, javascript의 리스너를 통하여 어떤 행위를 하는 것. 뭐 물론 script에서도 event를 발생 시킬 수 있다.   이벤트의 흐름  이벤트의 흐름이라고 하면 이벤트가 발생 되는 순서라고 인지 하면 된다. 기본적으로 window객체에서 이벤트를 발생(트리거) 시켜야 한다. 자 여기서 생각을 해볼 만한 것이 있다. 과연 당신이 이벤트의 흐름을 개발해야 한다고 생각해보자. 이벤트의 시작은 window여야 한다. window에는 document(dom)을 갖고 있다.  간단하게 위와 같은 dom트리에서 DIV를 click하였다고 생각해보자.  그러면 DIV를 window에서 추적을 해보자.  window => document => html => body => div 이렇게 도달하게 된다. 자 그렇게 하고 나서 당신은 div에 연결되어있는 click 리스너를 실행 시켜줄 것이다.  그렇다면 body에도 click리스너가 등록 되어있다면 어떻게 할 것인가? div에 click리스너보다 body의 click리스너를 먼저 호출 할 것인가? div의 이후에 호출 할 것인가?  ...

  try...catch는 예외처리를 하기 위한 문법이다. 뭐 문법에 대한 설명을 할 것은 아니니, 필요하다면, 아래의 링크를 열어서 문법을 확인 해보도록 하자. https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Statements/try...catch   예외: 일반적 규칙이나 정례에서 벗어나는 일.  예외라는 말은 위에서 나타나는 것처럼 일반적 규칙에서 벗어난 일을 뜻한다. 하지만, 몇몇 개발자들은 예상이 불가능한 상황을 예외라고 생각하는 버릇이 있는 것 같다. 무슨말이냐 하면...  자신이 예상 가능하여 if...else로 처리 가능한 모든 상황은 예외라고 판단을 하지 않는 것 같다는 말이다. 나의 경험으로는 예전에는 try...catch를 해야 하는 상황을 오류로 인식했었다.  try...catch vs if...else  즉 내가 하고자 하는 말은 아래와 같다. 고객의 정보를 불러오는 api가 있고 거기에서 사용자의 이름을 가져오고자 한다. 그때의 코드를 if...else로만 처리한다면... // 고객 정보 불러오기 . fetch ( '/api/person/100' ). then ((response) => { // 해당 호출이 항상 성공 할 수는 없기에 예외 if (response. status === 200 ) { // 해당 호출의 결과가 JsonString 이 아닐 수 있음 . if (! checkJsonString (response. text ())) { return { errorCode : ` ${response. status } 0` , errorMessage : ' 응답 데이터를 파싱할 수 없음 .' } } else { const res = response. json () // 원하는 데이터는 Object 이나 ...

 tabindex는 해당 엘리먼트를 포커스 가능하게 해준다. 이름으로부터 알 수 있듯이, "tab"으로 접근 하게 되는 순서를 결정할 때 사용할 수 있다.  회원가입이나 로그인을 위하여 우리는 tab을 자주 활용한다. 기본적으로 사용자의 입력을 받는 input류의 태그들은 포커스(키보드 입력)를 받을 수 있다.  tabindex를 활용하면 포커스를 지원하지 않는 태그에도 불구하고 해당 엘리먼트에 포커스에 포커스를 지원을 할 수 있다. 마우스를 사용 할 수 없는 사용자에게 악영향을 끼치기 때문에 지양하자.  예/아니오 vs 아니오/예  퍼블리싱을하다보면, 디자인과 태그상에 논리적 순서가 맞지 않는 경우가 생기기도 한다. 예를 들면 나는 취소를 그 예로 들고 싶다.  예/아니오의 순서 논쟁은 꾸준히 있어왔다. 과연 누가 옳은 것인가? 이건 누가 옳다/틀리다를 말할 내용은 아니다. 서로 다를 뿐이다. 세간의 말에 따르면....  "예/아니오"의 경우 긍정을 하는 경우가 더 많으니, 예가 먼저온것이고,  "아니오/예"의 경우 예를 누르기 전에 부정할 수 있는 옵션이 있다고 알려주는 것이라고 한다.  아니오/예  내가 이야기하고자 하는 부분은 "아니오/예"를 개발할 때 생기는 디자인과 논리적 순서상의 오류이다.  간단하게 컨펌창을 퍼블리싱을 한다고 해보자. <div> <div> 어쩌고 저쩌고 동의 ? </div> <div><button> 아니오 </button><button> 예 </button></div> </div>  뭐 태그는 어찌되었든 "아니오/예"를 개발하는 경우 위와 같은 형태가 될 것이다. 개발자라서 정확히 어떠한 이유가 있는지는 몰라도, 디자이너들은 맥을 쓰는 것을 선호한다. 뭐 물론 개발자들도 맥을 선호하는 비중은 꽤나 높다. ...

 개발을 하다가 디버깅을 하기 위하여 console.log를 사용 합니다. 뭐 물론 console.log만을 사용하여 개발을 할 수도 있고, 틀린방향이 아닙니다. 하지만, 조금 더 편하게 개발을 해보자구요.  1. console.error / console.warn  이 정도는 다들 사용 하고 있는 함수들일 것 입니다. 뭐 물론 console.warn은 사용 빈도가 그렇게 많지는 않을 것 입니다. 그래도 에러가 나서 로그를 작성해야 하는 경우 console.error로 작성 해주는 것이 다른 개발자들 혹은 오래된 코드에서 문제가 발생한 것을 확실히 알 수 있게 해주어 오류를 파악하기 쉽기 때문에 매우 추천하는 바입니다.  console.log는 검은색 / console.warn은 노란색 / console.error는 빨간색으로 표기 된다.  2. console.time / console.timeEnd  만약에 이 함수를 모른다면 특정 코드가 얼마나 걸렸는지 확인을 하기 위하여 이렇게 사용 하였을 것 입니다.   뭐 물론 이렇게 하더라도 얼마나 오래 걸리는 함수를 확인하는 대에는 큰 문제가 없을 것 입니다.  하지만 위의 코드에는 두가지 문제가 있지요. 1. 1ms 미만으로 걸리는 작업에 대해서 확인이 불가능 하다. 2. startTime, endTime을 다른 개발자나 혹은 자기자신이 테스트를 하기위한 코드였는지 까먹는 것 입니다.  여기서 대안이 console.time / console.timeEnd 입니다.    3. console.table  데이터를 다루다 보면, 배열을 많이 다루게 됩니다.  console.table은 말처럼 배열과 같은 데이터를 table형태로 노출 시켜줍니다.  각각의 필드를 클릭하여 정렬도 가능하니, 데이터를 확인하는 것에도 꽤 편합니다.  4. console.trace  자바스크립트에서 함...

 지난 포스팅에 Shadow DOM이 어떠한 것인지 소개까지는 하였지만, 정작 사용법에 대해서는 언급을 하나도 하지 않았다. 이번 포스팅은 사용법 위주로 소개를 할 것이다.   기본 사용법 기본 사용법은 매우 간단한 편이다. <html lang ="en" > <head></head> <body> <div id ="app" > loading... </div> <script> setTimeout (() => { const app = document . getElementById ( 'app' ) const appTemplate = document . createElement ( 'div' ) appTemplate. innerHTML = ` <h1>Hello World!</h1> ` const shadowRoot = app. attachShadow ({ mode : 'open' }) shadowRoot. append (appTemplate) } , 3000 ) </script> </body> </html>  엘리먼트에 attatchShadow함수는 실행하게 ShadowRoot의 인스턴스를 리턴한다.  ShadowRoot는 DocumentFragment를 상속 받는데, DocumentFragment는 우리가 사용하는 window.document의 클래스인 Document와 유사한 클래스라고 보면 된다.  간단하게 append 함수를 이용하여 컨텐츠를 채워줄 수 있다. attatchShadow함수의 필수 속성은 mode로 'open', 'closed'양자 택일이다. 차이점이라고 하면 외부 스크립트에서 element.shadowRoot가 closed면 null, open이면 접근 가능하다 정...

  자 우리는 왜 유지보수를 어렵게 만들어야 하는가? 우리는 우리의 코드의 보안을 유지 할 필요가 있다. 그 중에서 가장 큰 이유로는 동료 및 고용주에게 인정을 받기 위함이 클 것이다. 내가 짠 코드를 나만 수정을 할 수 있게 되면 고용주는 나를 해고 하기 어려워지며, 동료들에게는 실력의 격차를 겸허하게 받아들이게 할 수 있을 것이다. 또한 소스가 유출이 된다고 하더라도, 꽤나 시간이 걸려서 해석을 할 수 밖에 없을 것이다.  이 포스팅을 따르게 된다면 단점으로는 동료들에게 수많은 수정 요청을 받아서 회사에서 나만 일하게 되는 상황이 벌어질 테니 주의 바란다.   변수명으로 장난치기  변수명으로 장난치는 것은 꽤나 전통적인 놀이이다. 실제로 당했던 변수명으로는 그 당시에 유행 하였던 아이돌 이름일 것이다.  아이돌 이름 function GirlsGeneration() { let taeyeon let sunny ... }  자 위와 같은 함수를 받아들였다고 치자. 과연 이것을 유지보수 하는 사람은 어떤 정보를 알 수 있을까? 당연하게도 함수 작성자의 취향이다.  하하하하 아주 좋은 변수명이다.  변수명에 그렇게 많은 정보를 넣을 수 있다니 대단 하다.  한 글자 변수 let g = this  이것 또한 참 재미있는 변수명 짓기 이다. 자 여기서 g는 뭐의 약자 일까? 가장 자주 쓸만한 단어는 global일 것이다. 만약에 저 코드에서 this가 window를 가리키고 있다면 global이라는 단어는 꽤 그럴싸 할 수 있다. 한 글자로 변수를 짓는 것은 소스를 컴파일없이 불러와야  하는 브라우저 입장에서는 조금이라도 빠르게 페이지를 로드 할 수 있게 해준다.  뭐 물론 아이돌 이름을 쓰지 말라고 한 동료 개발자에 억압에 못이겨서 girlsGeneration의 약자로 g를 쓴 것일 수 있다.  동의어의 반복  동료 개발자들...

  우리는 지난 시간 customElement를 생성하는 방법을 확인하였다. 하지만 지금까지 포스팅한 내용만 가지고는 웹 컴포넌트을 만들기에는 역부족 일 것이다.  가장 첫번째 문제로 직면할 내용이 위처럼 외부 css 정의 역시 내부 엘리먼트에 영향을 끼친다는 것이다. 이는 css를 작성함에 있어서 커스텀 엘리먼트의 하위 속성인지 전부 확인하며 피해서 css정의를 해야 한다는 게 큰 문제이다.  => 이는 당연하게도  document . getElementsByTagName ( 'div' )  와 같은 dom을 셀렉트하는 과정에서도 영향을 받는다.  이 내용은 컴포넌트를 만드는데에 있어서 큰 문제이다. 웹 컴포넌트를 만드는 입장에서도 외부에서 절대로 사용 안 할 만한 class, name, id등을 정의 하여야 한다.   DOM tree  브라우저는 우리가 작성한 html tag들을 가지고 DOM tree를 생성한다. 예시는 아래와 같다. <html> <head></head> <body> <div> div 1 </div> <div> div 2 <div> div 2 - 1 </div><div> div 2 - 2 </div><div> div 2 - 3 </div></div> </body> </html>  위와 같이 우리가 작성한 html은 위와 같이 브라우저가 해석하여 DOM tree를 만들고 해당 tree를 근거로 자식 노드들, 부모 노드, 형제들을 판단한다. TreeWalker . parentNode () TreeWalker . firstChild () TreeWalker . lastChild () TreeWalker . previousSibling () TreeWalker . nextSibling () Tr...

 html string을 dom으로 간혹 만들어야 하는 경우가 있을 것이다.  예를 들면  1. ckEditor와 같이 게시판을 만들때, 에디터를 적용 해야 하는 경우, html을 검색을 하게 하는게 아니라, 해당 내용에 적혀 있는 텍스트만을 기준으로 해야 하기 때문에 html에서 태그를 제외한 내용을 따로 저장을 해둬야 하는 경우도 있다.  2. html string을 분석하여 특정 처리를 해야하는 경우도 있을 것이다. 예를 들면 검색후 매칭 되는 글자의 하이라이트 처리나, 해당 html 문자열이 단 하나의 부모만 있는지 등...  뭐 위의 내용 말고도 필요한 경우는 있을 것이다. 뭐 옛날에는 xml을 파싱 해야 했을 때도 있었지만...   innerHtml function htmlStringToNodeList (htmlString) { const tempNode = document . createElement ( 'div' ) tempNode. innerHTML = htmlString return tempNode. childNodes }  위 처럼 현재 document에 문서에 연결되지 않은 dom을 하나 생성 후 innerHTML로 htmlString을 세팅을 하게 되면, 모든 자손을 제거하고 htmlString을 html로 파싱하고, 생성된 노드로 대체 되는 특성을 사용 한 것이다. 사용법이 매우 심플하고, 널리 쓰고 있는 방법이기에 꽤 추천 하는 코드이다. * 텍스트만 뽑고 싶다면 아래 처럼 return만 변경 해주면 된다. return tempNode. innerText 출처: https://developer.mozilla.org/ DOMParser function htmlStringToNodeList (htmlString) { return ( new DOMParser ()) . parseFromString (htmlString , 'text/html' ) ...