코드 땜장이

 프로그래밍을 하다 보면, 두 배열 간의 연산이 필요한 경우가 많다. 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*/ }] const b = [{ x : 2 , y : 2 /* ,v: 4*/ } , { x

  나는 특이한 문제를 좋아하는 편이다. 오늘은 최근에 본 특이한 문제를 소개 한번 해보도록 하겠다.  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 = Number.MAX_SAFE_INTEGER + 1이면 된다.  x == 1 && x == 2 &am

  이벤트 버블링 및 이벤트 캡처는 이벤트의 흐름에 대해 설명 할 때 자주 언급 되는 단어이다. 하지만, 이벤트 캡처의 경우 특별한 설정 없이는 잘 상용 되지 않는 흐름이다 보니 해당 내용은 잘 모를 수 있다.  이번 포스팅에서 이야기 하고자 하는 내용은, 아래의 옵션이다.  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 이나 Array 이 일 수 있음 .

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