코드 땜장이

위의 코드는 Vue vs Svelte 간단하게 문법만 비교해보기 포스팅을 작성하면서 사용한 코드이다. React 공식 문서를 보는것이 좋긴 하지만 좀 와닿지 않는 부분이 있기도 하고 Functional Component기반으로 예제가 공식문서에 찾기 힘들어서 예전 예제로 작성해보려고 한다. 1. 시맨틱 슈거의 부재  vue를 공부해본 사람이라면 v-model이라는 키워드를 들어보았을 것이다. v-model="foo"은 :value="foo" @input="foo = $event" 이와 같이 풀어 쓸수 있다는 것도 알 것이다. react의 바인딩에는 v-model과 같은 시멘틱 슈거가 존재하지 않는다.    무슨말이냐 하면 아래와 같은 코드를 사용해야 한다는 것이다. <input type="text" value={foo} onChange={(event) => setFoo(event.target.value)}> 2. 데이터 타입 - numeric  아래의 코드를 보자. setA를 호출 할 때에 event.target.value를 숫자로 형변환 시키는 것을 볼수 있다.   당연하게도 html의 사용자 입력 가능한 값들은 숫자라고 하더라도 문자열이라는 것을 알 것이다. vue의 경우에는 .number라는 키워드를 이용할 수 있지만... react는 처리가 아래처럼 해야 할것 같다. < input type = " number " value = {a} onChange = {(event) => setA ( + event . target . value )} min = " 0 " max = " 10 " /> 3. 데이터 타입 - reference < select value = {selected} onChan...

위의 코드는 Vue vs Svelte 간단하게 문법만 비교해보기 포스팅을 작성하면서 사용한 코드이다. React 공식 문서를 보는것이 좋긴 하지만 좀 와닿지 않는 부분이 있기도 하고 Functional Component기반으로 예제가 공식문서에 찾기 힘들어서 예전 예제로 작성해보려고 한다. 느낌점은 아래와 같다.  오늘은 svelte가 이벤트를 핸들링 하는 방식중에 눈에 띄는점이 두가지가 보였다. 1. react에서 자식이 이벤트를 발생 시키는 방법은 없다. 부모가 자식에게 함수를 props로 전달하는 것을 자식이 적절한 순간에 실행 시켜주는 것으로 자식이 부모의 리스너를 해소 시켜 줄 수 있다. 코드는 아래와 같다. vue에서는 아래와 같은 코드를 좀 안좋게 보는 경향이 있고, 아래처럼 하지 않아도 된다. 위와 같은 방식을 사용 할 때에 자식 컴포넌트에 이벤트 리스너를 기본값을 생성 하여 함수를 전달 받지 않았을 때의 처리가 필수 처럼 보인다.  자 그러면 뷰에서는 어떻게 해야 할까요?   2. 아쉬운 점은 once키워드에 대한 부재이다. 한번만 실행 시키고 싶은 경우 addEventlistner의 once옵션을 이용 할 수 있다. https://developer.mozilla.org/ko/docs/Web/API/EventTarget/addEventListener 참 불편한 코드이다... 한번만 실행 되는 함수일 뿐인데...  위의 코드들을 vue스타일로 작성한 코드는 아래에 있다. 한번 확인해보고 적당히 판단 해보길 바란다.  아직은 깊은 수준내에서 비교하기가 학습이 되지 않아서, 한동안은 vue(2.X)와 react(functional component)로 각각 만들어본 어플리케이션 예제들을 한번 올려보려고 한다.

위의 코드는 Vue vs Svelte 간단하게 문법만 비교해보기 포스팅을 작성하면서 사용한 코드이다. React 공식 문서를 보는것이 좋긴 하지만 좀 와닿지 않는 부분이 있기도 하고 Functional Component기반으로 예제가 공식문서에 찾기 힘들어서 예전 예제로 작성해보려고 한다. 느낌점은 아래와 같다.  1. svelte에서 지원하는 Await block은 react에서도 지원 하지 않는다... 편해보이는데. 게다가 v-if, v-for와 같은 키워드를 지원 하지 않기 때문에 불편하다... 함수를 잘 만들어서 사용 해야겠다는 생각이 든다.  2. props사용 방식은 너무 좋은 경험이었다. 생성자 함수에 파라미터로 받을 줄은... 아주 자연스러운 형태여서 이해가 빠른 부분이긴 했지만, 초기화는 왜 defaultProps을 이용해야 했는지 별로였다.  3. v-if, v-for의 부제는 너무 불편했다. 또한 인라인 스타일은 왜 {{}} <- 어째서 두번 사용 해야 하는지... 불편해보였다. 뭐 다른 용도가 있겠지...    위의 코드들을 vue스타일로 작성한 코드는 아래에 있다. 한번 확인해보고 적당히 판단 해보길 바란다.  아직은 깊은 수준내에서 비교하기가 학습이 되지 않아서, 한동안은 vue(2.X)와 react(functional component)로 각각 만들어본 어플리케이션 예제들을 한번 올려보려고 한다.

위의 코드는 Vue vs Svelte 간단하게 문법만 비교해보기 포스팅을 작성하면서 사용한 코드이다. React 공식 문서를 보는것이 좋긴 하지만 좀 와닿지 않는 부분이 있기도 하고 Functional Component기반으로 예제가 공식문서에 찾기 힘들어서 예전 예제로 작성해보려고 한다.  위의 코드를 작성하면서 JSX표현법이 꽤나 어색하다는 생각이 너무 들었다. 뭐 이부분은 차차 익숙해져나가면 괜찮은 부분이기에 패스하도록 하겠다. 하지만 아쉽게도 react도 루트엘리먼트는 하나여야 한다는 점에서 좀 아쉬움이 들었다.  svelte가 꽤나 react 스럽다라고 생각이 드는 부분이 많다. 그도 그럴것이 svelte와 마찬가지로 data, watch, methods, computed 등등 코드에는 불필요한 선언(?)들이 필요 없어서 코드들이 간결해짐이 있다.  따라서 첫인상에 대한 아래의 평도 Vue vs Svelte와 같은 평가(?)를 할 수 밖엔 없을 듯 하다.  react vs (vue, svelte)의 차이중에 지금 눈에 띄는 것은 Hook 정도인가? 싶긴 하다.  vue, svelte 둘다 변수를 선언하고 템플릿에 바인딩 되어있으면 값의 변경 반영이 된지만, react hook을 이용하면 useState를 사용해야 처리가 되는것은 개발자가 신경 써야 하는 부분이 생긴것 처럼 보인다.  또한 계산된 속성, watch를 처리할 수 있는 useMemo의 경우에도 좀 특이했다. useMemo의 두번째 인자로 어떤 값들의 변화에 의해 해당 평가를 처리할 것인지 의존할 인자를 정의 해주어야 한다. 이부분도 개발자가 신경 써야 하는 부분이 생긴것 처럼 보인다.  뭐 물론 신경쓸수 있는 부분이 더 늘어남으로써 개발자가 직접 최적화 할 수 있는 부분이 더 많아 진것으로 볼수도 있겠지만...  위의 코드들을 vue스타일로 작성한 코드는 아래에 있다. 한번 확인해보고 적당히 판단 해보길 바란다....

 많은 개발자들이 label을 이용하거나 라벨을 이용하는 것처럼 여러가지 지원을 해준다. 하지만 몇몇 개발자 분들은!!!!! 사소한 부분을 신경을 쓰지 않기도 한다. 뭐 물론 아직 많이 사용하지 않는 혹은 아직 사용성에 신경쓸정도가 되지 않을 정도로 기능 우선적 개발이 필요한 경우가 있을 수 있지만... 몇몇 서비스의 경우 이미 오래되었음에도 불구하고, 신경을 안쓰는 곳이 있다.  웹을 공부를 하셨던 분이라면 html을 공부를 할 때, input과 관련 하여 label을 공부하게 될 것이다. 하지만 도덕 공부를 해도 쓰레기를 바닥에 버리는 것처럼 , 잘 신경 쓰지 않는 것 같다. 위의 코드를 보면 사용법은 간단하다. <input type ="radio" id ="html" name ="fav_language" value ="HTML" /> <label for ="html" > HTML </label> for와 id를 맞춰주기만 하면 label의 클릭이 input을 클릭한것처럼 처리가 된다. <label> <input type ="radio" name ="fav_language" value ="HTML" /> HTML </label> 혹은 for와 id를 제공하지 않고 label안쪽으로 input을 위치 시켜주어도 된다. <input type ="radio" id ="html" name ="fav_language" value ="HTML" /> <label for ="html" > HTML </label> 참고로 조심하여야 하는것이 같은 id와 for를 이용하면 안되는 것이다. 만약에 label에 for와 id를 사용 하는 ...

  일반적으로 텍스트가 놓일 공간에 대해서 lorem ipsum을 많이 쓰곤 한다. 안 써 보신분이라면 아래가 lorem ipsum이다. "lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." 위키에 따르면 변역은 아래와 같다. 참고로 구경해보자. " 역시 마찬가지로, 단순히 고통이라는 이유 때문에 고통 그 자체를 사랑하거나 추구하거나 소유하려는 자는 없다. 다만 노역과 고통이 아주 큰 즐거움을 선사하는 상황이 때로는 발생하기 때문에 고통을 찾는 사람이 있는 것이다. 간단한 예를 들자면, 모종의 이익을 얻을 수도 없는데 힘든 육체적 노력을 기꺼이 할 사람이 우리들 중에 과연 있겠는가? 하지만 귀찮은 일이 뒤따르지 않는 즐거움을 누리는 것을 선택한 사람, 혹은 아무런 즐거움도 생기지 않는 고통을 회피하는 사람을 누가 탓할 수 있겠는가? "  뭔소린지 모르겠다.  꼭 한때 유행했던, 키보드 추천타이핑으로 적은 시 같긴 하다.  개발을 하다보면 내용이 텍스트가 담겨져 있는 예제를 많이들 볼 수 있다. 뭐 적당히 내용이 중요하지 않은 곳에 넣기에 좋은 문구이다.  자 그러면...

 es6를 배우다 보면 뭐 물론... 지금은 자바스크립트겠지만... arrow function과 일반 function의 차이로 arguments가 없다라는 문장을 항상 볼 수 있다.  그런데... 배우는 입장에서 arguments? 그게 뭔데? 라는 생각을 해본적이 있을 것이다. 딱히 알았다고 해도 이걸 어따 쓰지... 이 생각도 들었을 것이다. 일단 parmeter와 argument의 차이를 알자. function foo (bar) { console . log (bar) } foo ( 3 )  위의 함수는 뭐 설명하기도 민망한 함수를 만들어 보았다. 뭐 설명 하는데 어려운 코드가 필요 한것은 아니니. foo를 3이라는 인자(argument)로 호출 하였다. foo라는 함수는 bar라는 매개변수(paramter) 를 console.log의 인자로 이용하여 호출 하고 있다.  자 여기서 arguments와 parameter는 큰 차이를 갖는다. function foo (bar) { console . log (bar) // 1 console . log (arguments) // Arguments(3) [1, 2, 3, callee: ƒ, Symbol(Symbol.iterator): ƒ] } foo ( 1 , 2 , 3 ) parameter bar를 이용해서는 하나의 값만 갖지만, arguments로 접근하여 Arguments 객체에 1, 2, 3값이 있는 것을 볼수있다. Arguments는 유사배열이라고 보면 된다. 인덱스가 있고, length가 있으며 iterable protocol을 만족 하고 있다. 여기서 특이한 호출 방법을 알려주자면 아래와 같다. function foo (bar) { console . log (bar) // 1 console . log (arguments) // Arguments(3) [1, 2, 3, callee: ƒ, Symbol(S...

  lodash를 사용하다보면 살짝 아쉬운 경우들이 있다. 현재 개발중인 프로젝트에서만 자주 사용 하는 함수들도 있을 것이고, 자주 사용 할 법한 함수임에도 불구하고, 어른들의 사정에 의해서 개발을 안함 함수도 있을것이다.  그럴때를 위하여 lodash mixin을 만들어서 라이브러리 사용자에게 편의를 주는 경우도 있으니 사용 방법을 아래에 작성해 보겠다.  개발을 하다보면, 오브젝트에서 특정값을 꺼내서 다른값과 비교하는  _.get( foo, 'bar' ) === 'blah'  이와 같은 코드를 많이 작성하게 될 것이다.   그럴때 그냥 함수 하나로 _.getEq( foo, 'bar, 'blah' ) 이와 같은 코드로 작성 할 수 는 없나? 이런생각이 들어서 lodash 문서를 아무리 찾아봐도, 그런 함수는 지원 하지 않고 그나마 lodash로만 처리 한다면 이와 같은 코드를 짤수 있을 것이다. _chain( foo ).get( 'bar' ).eq( 'blah' ).value()  뭐 위의 코드 보다  _.get( foo, 'bar' ) === 'blah'  이 코드가 더 짧으니 뭐...쓸 일 없는 함수겠지만 mixin을 사용한다면 다르다. const getEq = function ( object , path , other ) { return _.chain( object ). get ( path ).eq( other ). value () } _. mixin ( { getEq } ) const foo = { bar : 'blah' } _. getEq ( foo , 'bar' , 'blah' ) // true _. getEq ( foo , 'bar' , 'blahblah' ) // false 하지만 위의 코드는 lodash의 기존 함수를 응용한거 치고 아쉬운점이 있다. 그것은 무...

 lodash에는 더욱 함수형 프로그래밍 스타일로 코드를 짤 수 있게, 지원해준다. 간단하게 커링을 지원을 해주고, 반복에 대한 행위를  첫번째 인자로, 데이터를 마지막인자로 스왑해주는 정도이다.  자 위의 내용이 무엇인지 어떻게 좋은 방식인지 한번 검토해보도록 하자.  예전 포스팅을 본 사람들이거나 함수형프로그래밍을 공부 해보신분들이라면 커링이 무엇인지 알겠지만, 처음 듣는 분들이라면 생소할 내용이니 예를 들고 진행을 하겠다. 커링(Currying) const curry = func => (a , ...args) => args. length ? func(a , ...args) : (...args) => func(a , ...args) const sayBlah = curry ((msg , to) => ` ${msg} ${to} !` ) const sayHello = sayBlah ( 'hello' ) sayHello ( 'world' ) // ➜ hello world! sayHello ( 'sejiwork' ) // ➜ hello sejiwork! const goodByeMessage = sayBlah ( 'goodBye' , 'sejiwork' ) // ➜ goodBye sejiwork!  위의 코드를 적당히 보면 확인이 가능 하다. 함수 A가 2개의 인자를 기대 하였는데, 그 보다 적다면 함수의 평가를 후로 미루게 되며, 함수의 인자가 가득 차게 되면 평가를 하게 된다.  위의 코드를 lodash fp를 이용하여 간단하게 작성해보자. cdn으로 예제를 따라하게 된다면 아래의 cdn을 이용하도록하자. <script src ="https://cdn.jsdelivr.net/g/lodash@4(lodash.min.js+lodash.fp.min.js)" ></script> const sayBlah = _.curry((msg , to) ...

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

 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를 사용 하지 않고 옛날 코드스타일 대로 해당 기능을 구현한다고 생각하면, 꽤나 귀찮은 작업이면서 성능도 떨어질 것이므로 소개를 해보았다. 옛날코드 다시읽기 소재로 나중에 한번 옛날 코드를 소개해줄 기회가 있을지도 모르겠다.

 지난 번글로 position sticky를 소개 해보았다. 하지만 어떻게 써야 할지 감이 안잡하는 분들도 있을 것이다. 뭐 물로 사용 해분 본들도 있겠지...  그래서 이번에 scroll-snap-type과 같이 이용하여 재밌는 스크롤 액션을 만든것을 소개해 보겠다. 위의 코드를 간단하게 확인해보면 확인해야 할 키워드는  scroll-snap-type : y mandatory ; scroll-snap-align : start ; position : sticky ; 위 세 가지의 css속성이다. position: sticky만 사용 하는 경우 title의 위치를 스크롤되는 도중 어디에 위치 시킬지 결정 할 수 있는 것은 지난 포스트에서 안내를 하였다. scroll-snap-* scroll-snap 속성은 스크롤하는 행위를 멈추었을 때, 스크롤의 오프셋을 조정 할 수 있는 속성이다. 따라서 scroll에 영향을 받는 position: sticky속성과 케미가 좋다. scroll-snap-type scroll-snap-type은 어느 축에 맞출지와 엄격도를 지정 할 수 있다. 위의 속성정의에 따르면 y축에 scroll-snap을 맞추고 항상 snap효과를 주라는 요청이 되어있다. scroll-snap-align scroll-snap-align은 스냅 되는 대상의 영역(snap area)의 어디 기준으로 맞출지에 대해 결정을 해준다. 위의 속성으로 보면 article 클래스의 상단 영역에 맞추고자 하는 것이다. 조금만 더 깊에 들어가자면 snap area, snap position, scroll container와 같은 단어의 뜻을 알면 좋긴 하다만, 일단은 사용예제를 한번 보고 어떻게 써볼지에 대해 고민해보는것이 좋을 듯 하다.

  fixed fixed의 경우 컨테이닝 블록을 따져보아야 한다.  1. 뷰포트 * 뷰포트라는 말을 처음들어본 분이 있을지 모르니 간단하게 기기 해상도에 따른 화면 사이즈라고 보면 된다. 2. 특이상황에서의 조상      1) transform이나 perspective (en-US) 속성이 none이 아님.      2) will-change 속성이 transform이나 perspective임.      3) filter 속성이 none임. (Firefox에선 will-change가 filter일 때도 적용)      => filter가 none일 때에는 특정 조건이 뭔지 파악이 애매함.      4) contain 속성이 paint임. 위의 조건에 따라 생긴 컨테이닝 블록을 기준으로 top, right, bottom, left 요소를 사용 할 수 있다. position absolute의 컨테이닝 블록이 될 수 있다. 새로운 쌓임 맥락을 생성한다. sticky  가장 난해한 규칙과 행동을 보여주는 position 속성일 수 있다. sticky속성인 경우에는 스크롤이 가장 중요하다. 뭐 물론 테이블에도 이용이 가능하지만, 웬만해서는 요즘에는 테이블을 쓰지 않으니 설명은 생략 하겠다. sticky는 위의 예제를 보는 것이 좀 더 해당 속성에 잘 설명이 될 수 있다. 위의 예제 처럼 스크롤이 해당 영역을 지나가기 전에는 relative처럼 행동을 하지만 스크롤로 지나간 후 부터는 스크롤영역을 따라가는 것을 확인 할 수 있다. 이걸로 다음 포스팅에서는 재미있는 예제를 보여주도록하겠다.

 position을 주제로 하는 것은 꽤나 까다로운 내용이다. position을 바꿔 주는 것만으로 해당 엘리먼트의 특성이 매우 변하기 때문이다.  간단하게만 나열하면, 가장 큰 변경은 컨테이닝 블록이 변경 된다. top, left, botton, right 속성을 정의 할 수 있다. 새로운 쌓임맥락이 생성 된다.  꽤나 내용이 많고 응용 또한 많고 조심해서 써야 하는 주제이기 때문에 천천히 진행하고자 한다.  모든 태그들의 기본적인 position은 static이라고 보면 된다. 아직까지 필자는 다른 포지션을 갖는 태그는 본적이 없다. 뭐 물론 셀렉트 박스의 열린 옵션들 스크롤이나 파일 오픈시의 시스템 다이얼로그는 예외로 하자 그것들은 DOM으로써 제어가 불가능 하니....  위의 언급 중 컨테이닝 블록, 쌓임맥락을 처음 들어보는 분들도 있을 것이다. 간단하게만 설명 하겠다. 뭐 자세한 내용은 추후에 내용을 담을 수 있도록 노력해보겠다.  특정 요소의 크기나 위치에 관여 하는 것은 무엇인가? 아주 추상적이기 때문에 다시 예를 들겠다. 특정 태그 A태그의 height: 100%를 지정하였을 때, 어떠한 요소 기준으로 100%로라는 것일까? 바로 상위 부모 일수도 있고 더 위의 부모 일수도 있고, 뷰포트일 가능성도 있다. 즉, 특정 태그 A의 크기 위치에 관여 하는 것이 컨테이닝 블록이다.  쌓임 맥락은 무엇인가? A태그와 B태그가 겹치는 공간이 생기면 어떻게 할 것인가? 다들 z-index는 들어보았을 것이다. A태그와 B태그가 z-index가 같고 같은 부모를 공유 하고 있을때, 어떤 태그를 상위에 노출 시킬지에 결정 할 수 있다. 쌓임 맥락은 그 Z축을 개념화 한 것이다. static  위의 설명은 조금 새긴 했다. 가장 간단한 static을 설명 하자면, 그냥 컨텐츠의 일반 속성에 따라서 엘리먼트가 위치 한다. top, right, bottom, left 어떠한 요소도 사용이 불가능 하...

 요즘이 아닌 최소 5년전에 개발을 하던 분들은 아래의 코드들이 꽤나 익숙 할 것이다.  <a href ="javascript:" onclick =" foo () " > javascript: </a> <a href ="#" onclick =" foo () ;return false; " > # </a> <a href ="javascript:void(0)" onclick =" foo () " > javascript:void(0) </a>  요즘에는 함수를 실행하기 위해서 a태그를 이용하는 사람들은 거의 없을 것이다. 그러다 보니 위의 코드가 어색해 보인다. 당연하게도 요즘에서는 권장 되지 않는 방법이기도 하다. 하필 예전에는 왜 함수를 실행하기 위하여 a태그를 사용 하였을까?  생각해볼 만한 것은 button태그가 정상적으로 작동 안했다면? 이라고 생각이 들 뿐이다. 브라우저 버전에 따라서 버튼 모양이 달라졌다던가? 아니면 button의 기본 동작이 브라우저 별로 달랐다던가 하는 말이다.    위의 이미지만 확인해도 javascript: <- 이 것이 무엇을 뜻하는지는 감이 올 것이다. 당연하게도 위와 같은 행위는 잘 하지 않을 것이지만, 이런것이 가능하다. <a href ="javascript:void(0)" onclick =" foo () " > javascript:void(0) </a>  a태그를 이용하여 함수를 실행하기 위해서 사용 하기 위해서는 a태그 클릭시 기본적인 기능인 페이지이동을 막아야만 하였다. 따라서 위와 같이 javascript: pseudo protocol의 이용하되 평가값을 undefined를 이용 하여 페이지 이동을 막았다.  또한 예전에 href를 정의 안하는 꼼수는 사용 하지 못했다. 정의 안하면 현재 ...

가끔 퍼블리싱을 하다보면 vue.js의 root엘리먼트가 항상 있어야 하는 것은 거슬리는 일이기도 하다. 혹은 관련이있어서 같은 부모를 가져야 하는 태그들이 있을 수 있다. 물론 아직도 display: block, inline만을 사용 하고 있다면, 딱히 불편함은 없을 수 있겠지만... grid와 flex없이는 이제 퍼블리싱 못하는 몸이 되어버렸다... < div style =" display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); " > < div style =" background: red; " > test1 </ div > < div style =" background: green; " > test2 </ div > < ul > < li style =" background: blue; " > 1 </ li > < li style =" background: purple; " > 2 </ li > </ ul > </ div > 위 코드의 결과를 보자. 딱 보아도 잘못 된것만 같은 무언가가 만들어졌다. < div style =" display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); " > < div style =" background: red; " > test1 </ div > < div style =" background: green; " > te...

 웹 개발자라면, 특히나 프런트엔드 개발자라면 wasm은 익히 들었을 것이다. 하지만, 재미로는 많이들 사용 해봤겠지만, 주니어 개발자나 c/c++, rust를 습득하지 않았거나 오래 되신 분들은 재미로 해보기에는 조금 벅찰 수 있으니 포스팅을 작성한다.  위의 즉 이 글은 주니어 개발자, c/c++, rust를 사용하기 싫은 분 들이 대상이다. 아주 간단하게 맛만 보여드릴 테니, 자세한 내용은 다른 포스팅을 보고 습득 하시거나 책을 추천 드린다.  프런트엔드 개발자라면 최소 TypeScript를 들어 보았거나 들어보았을 것이다. 이 포스팅에서는 wasm을 TypeScript를 이용하여 작성 할 것이다.  해당 예제를 하기에 앞서서 최신버전의 Node.js를설치하기 바란다. npm init npm install --save @assemblyscript/loader npm install --save-dev assemblyscript npx asinit .  자 여기까지 왔다면 위와 같은 파일들을 얻을 수 있다. /assembly/index.js // The entry file of your WebAssembly module. export function add ( a : i32 , b : i32 ): i32 { return a + b ; }  위와 같은 함수를 볼 수 있다.  간단하게 위의 코드를 설명 하자면, add라는 함수를 외부에 노출을 시키며, a, b라는 인자를 받으며 각각의 타입은 i32(부호가 있는 32비트의 정수)이고, 인자 a, b를 받아서 i32타입으로 값으로 리턴한다.  간단하게 설명을 해보았는데, 답이 되었으면 좋겠다.  자 여기까지만 보면, 이걸로 속도테스트가 되나?? 이생각이 들 것이다. 맞다. 당연안되겠지 그러니 다음 함수를 추가하자. // The entry file of your WebAssembly module. export functi...