사진에서처럼 두 개의 span 태그가 존재하고, '더보기' 라는 텍스트는 자식 태그에 삽입이 되어 있는 상태입니다. 아래에 적용된 CSS코드를 보겠습니다.
위의 그림은 background-image에 적용된 이미지의 url에 실제로 저장되어 있는 그림 파일입니다. 그림 파일이 많아질 경우에는 저런 식으로 하나의 파일에 모두 담은 후에, background-position을 이용해 원하는 위치에 있는 내역을 잘라서 가져오기도 합니다.
.more 클래스에서는 원하는 위치의 그림을 불러오고 display:block, width, height 속성을 적용해 그림 파일이 온전한 제 영역을 가질 수 있도록 설정하였습니다. block이나 inline-block 둘 중에 하나로는 반드시 설정해야 높이와 너비를 설정할 수 있으니 잊지마세요!
clip속성을 사용하기 위해선 반드시 position:absolute 를 설정해야한다는 점 기억해두세요!
다음으로는 클릭할 때 '더보기'와 '접기'가 번갈아가면서 나오도록 설정해보도록 하겠습니다.
.close 클래스에 대한 속성은 좌표값만 달라졌을 뿐 .more와 동일하게 적용이 되었습니다. 그리고 마우스가 올라갔다는 것을 보여주기 위해 cursor속성을 pointer로 설정을 해주었습니다. 좀 더 직관적으로 변했죠?
그리고 다음으로는 jQuery를 사용했는데요. .more 클래스가 클릭이 되었을 경우에, 각각 경우에 수를 따집니다. hasClass 속성을 이용해 클래스가 있는지 판별을 먼저 하고 그에 따른 값 변경을 해주게 됩니다. 여기서 뭔가 살짝 이상한데, .more에 클릭이 되었을 경우에 클래스 명이 .close로 변경이 되는데 여전히 클릭 이벤트는 .more가 받는다는 것입니다. 이 부분은 저도 왜 그런것인지 정확하게는 모르겠습니다. 혹시 아시는 분이 있다면 댓글로 정정해주시면 감사하겠습니다.
저의 블로그에서는 항상 맨 밑 바탕이 되는 div는 #wrapper로 지정합니다. 만약 제 블로그를 꾸준히 구독해주신다면, 이런 부분에서는 제 코드를 받아들이시는데 시간이 덜 걸리지 않을까 하네요.
우선 #wrapper는 오늘도 밑거름(?)이 되어주어야하기 때문에 width:500px; height:500px; 으로 설정해줍니다. 그 위에 갤러리같은 느낌을 주기 위해 #frame에서는 배경을 흰색으로하고, position을 이용해 적절히 위치를 이동시켜줍니다. 그리고 저는 항상 box-shadow를 이용해 그림자효과를 아주 살짝만 넣어주는데, 이렇게하면 하지 않았을 때와 차이가 은근히 많이 납니다. 막상 보면 티는 많이 나진 않지만 그래도 좀 더 현실감을 부여해줄 수 있죠.
그 다음으로 해야할 일은, 사진의 크기와 위치를 조절해주는 일입니다. 이미지는 인터넷에서 임의로 가져온거에요.
추가된 부분을 봐주세요. 이미지를 담고 있는 .img-wrapper에 먼저 width와 height를 195px로 지정해주었고, 그 안에 있는 이미지 태그에서는 inherit으로 그대로 물려받도록 했습니다. 즉 195px로 똑같이 설정을 해주었다는 거죠.
이미지태그로 어떤 이미지를 넣어 레이아웃을 꾸밀 때, 그 이미지를 담고 있는 상위 태그의 영역과의 관계를 잘 고려하시는게 좋다고 생각합니다. 무슨 말인가하면, .img-wrapper에 대한 width와 height를 설정하지 않은채로 바로
를 적용하게되면 어떻게 될까요?
그러면 이미지와 그 부모 태그와의 영역이 어긋나게 되버립니다. 그림을 참고해보세요.
이제 그림을 보시면, 부모에서 영역을 지정해 자식이 물려받지 않게된다면, 오른쪽의 그림처럼 영역이 어긋나버리게됩니다. 그렇지만 눈에 보이는 레이아웃은 크게 망가지진 않습니다. 왜냐하면 현재는 다른 태그들과의 영역 겹침 문제가 발생하지 않기 때문인데요, 이 경우에는 영역을 넘어가버린 부분에 대해서 나중에 추가적으로 레이아웃의 배치를 다시 맞춰줘야 할 수도 있습니다.
그래서 부모인 .img-wrapper에서 영역을 조절해주고, 자식도 같은 영역을 갖도록해 마치 하나인것처럼 보이게 해주었습니다. 이렇게하면 적어도 영역이 넘치는 overflow에 대해 걱정할 필요는 없어진 셈이죠.
HTML에 새롭게 .darkness, .btn-plus라는 div를 모든 .img-wrapper들의 자식으로 넣어주었습니다. 그 다음에는 CSS속성을 이용해서 색상이나 위치를 조절하는데요. 여기서 주목해서 보실 것은, 제가 바로 이전에 .img-wrapper에다가 position:absolute를 설정해주었습니다. 그리고 나서 위치를 이동시켰죠. 기억나시나요?
부모의 position 속성이 absolute, relative일 경우에 자식의 position이 absolute면 부모 요소의 맨 좌측 상단이 시작 기준점으로 적용됩니다.
그렇기때문에 .darkness의 position이 absolute로 설정되었을 때 부모의 좌측상단부터 적용되어 시작할 수 있었던 겁니다. 이렇게하지 않으면 무엇이 다르게 나타날까요?
잘 보이시나요? 바로 .img-wrapper와 #frame사이에 존재하는 저 얉은 흰색 영역, 저 부분을 .darkness가 가리게됩니다. 왜냐하면, .img-wrapper가 position:absolute를 갖고있지 않다면, .darkness의 position이 설정이 되었을 때 시작기준점을 누구에 맞추려고할까요? .img-wrapper가 아니라 바로 #frame입니다. 왜냐면 #frame이 position:relative를 갖고 있기 때문이죠. 만약에 #frame도 아무런 설정이 없다면 그 위의 부모로 다시 올라가서 찾겠죠. 결국 아무도 갖고 있지 않으면 윈도우창의 맨 좌측상단이 시작 기준점으로 설정이 되는 원리입니다. 너무나도 중요한 이야기이니 반드시 이해하고 넘어가세요.
그리고 .btn-plus는 원으로 만들어줄 것이기 때문에 radius속성을 이용을 했구요. span에서는 HTML단에서 + 라는 문자를 텍스트로 넣어주었습니다. 다시 말해서 이 텍스트가 마우스로 드래그되서 선택될 수 있다는건데 이건 상당히 거슬리지 않을 수 없죠. 그래서 마우스로 드래그를 하지 못하도록 하는 설정이 바로 user-select:none 입니다.
이제 여기까지 무리없이 잘 오셨다면, 남은 부분은 쉽게 넘어갈 수 있습니다. 마우스오버 효과만 넣어주면 마무리가 될 것 같네요. 여기서는 opacity와 scale만을 가지고 효과를 간단히 넣어보겠습니다.
.img-wrapper에 hover효과가 올라가게되면 .darkness에는 어두운 느낌을, .btn-plus에는 서서히 나타나는 효과를 넣어주었습니다. 주의해서 보셔야할 점은, hover에 대한 효과를 생각을 할 때, 마우스가 올라가는 것 뿐만이 아니라 마우스가 영역 밖으로 나갈 때의 효과까지도 같이 고려해야 한다는 점입니다.
마우스가 올라갔을 때는 :hover로 설정하면 그만이지만, 마우스가 밖으로 나가버리면 효과는 어떻게될까요? 바로 없어져버리게되죠. 이는 상당한 이질감을 느끼게합니다. 그래서 반대로 효과가 reverse하게 보이게하려면, 그에 맞는 시간에 대한 값과 기타 디폴트값을 애니메이션 효과를 주고싶은 요소에다가 넣어놓아야합니다. 예로 .btn-plus에 추가된 기본 속성 값들을 참고해보세요.
이로써 이번 마우스효과에 대한 포스팅도 끝났습니다.
도움이 되셨다면 다행이네요. 댓글은 언제든지 환영입니다. 앞으로도 더 많은 효과에 대해 다룰 예정이니 많이들 와주세요^^
지금 현재로써는 밑바탕이 되어줄 #wrapper div와 나머지 .clip div들에 대한 레이아웃만 설정되어 있는 상태입니다. 이 사각형들을 전부 삼각형으로 바꾸어준 후에 position을 이용해 적절히 배치를 해보겠습니다. 우선, 삼각형, 오각형, 육각형 등 사각형이 아닌 다른 특수한 도형을 그릴 때는 clip-path라는 것을 이용해야 합니다. clip-path는 좌표 값을 찍어 그 점들을 모두 잇고, 점과 점 사이로 연결된 선의 안쪽 영역을 도형의 모양이라고 간주합니다. 즉, 삼각형을 그리려면 좌표 3개가 필요하고, 이 3개의 좌표는 자동으로 이어지며 그렇게 생긴 선들의 안쪽 영역(삼각형 내부)이 화면으로 보여지게 될 영역이라고 간주되는 것입니다.
방금 바로 위에서 설명한대로, 사이트에 접속해 원하는 도형을 선택 후에 나온 코드를 그대로 복사 후 붙여넣기 하였습니다. 코드에 표현된 %는, 예를 들어 100% 50%라면, 해당 좌표는 x축으로 100%만큼, y축으로 50%만큼 이동했다는 뜻입니다. %의 범위는 현재 작업중인 태그의 크기입니다. 즉 100px의 div로 작업을 한다면 100%면 100px, 50%면 50px이 되겠죠.
이제 우리는 어떻게 삼각형을 그리는지 알았습니다. 이제는 여러가지 다채로운 도형들을 넣어보겠습니다. 제 코드를 보고 연습하시게 될 경우에는 이런 저런 다른 도형들도 커스터마이징해서 넣어보세요.
.clip에 설정된 z-index를 봐주세요. z-index는 같은 영역에 2개 이상의 요소들이 위치할 때, 어떤 것부터 먼저 보여줄지를 결정하는 속성입니다. z-index가 높을수록 우선순위가 높아집니다.
다음으로는, 새롭게 추가된 도형 클래스를 살펴보겠습니다. 먼저 예를 들어, .circle-1 클래스에는 .circle이, .close-1 클래스에는 .close 라는 식의 클래스가 모든 도형들마다 설정이 되어있습니다. 당장에는 필요없는 작업이지만, 이것은 만약의 상황에서, 같은 도형이 더 추가가 될 경우, 클래스 재사용을 위해 넣어둔 것입니다. 이렇게하면 나중에 삼각형을 10개를 그린다고 가정할 때 하나하나 일일히 속성을 부여해주지 않아도 되는 것이죠.
그리고 한 가지 더 궁금해하실 법 한 것은 바로 clip-path를 사용해 만든 도형의 border를 어떻게 적용하냐의 문제입니다. 이러한 것은 딱히 방법은 없습니다. 단지, 새롭게 같은 모양의 도형을 그 위에 하나 더 그리고, 크기를 약간 작게하면 뒤에 가려진 도형이 조금 노출이 되겠죠? 마치 테두리가 입혀진 것처럼요. 이러한 것은 현재 우리가 다루고 있는 예제에서는 코드의 양만 늘릴 뿐이라 생각되어 추가하지는 않았습니다. 관심있으신 분들은 따로 시도해보세요.
위의 사진은 .clip이 z-index 속성을 갖지 않았을 때 나타나는 모습입니다. 왜 z-index를 설정해주어야 하는지 이제 이해하시나요?
자, 이제 얼마 남지 않았습니다. 드디어 기다리던 애니메이션을 넣어줄 시간이 왔습니다. 그 전에, 이 이야기를 먼저 다뤄보도록 하죠. 우리는 여기서 우주의 빅뱅처럼, 가운데에서 사방으로 흩뿌려지듯이 퍼졌다가 다시 모아지는 애니메이션을 다루고 싶습니다. 그런데, 퍼졌다가 돌아올 때의 약간의 시간차를 느끼게 해주고 싶어요. 무슨 말인가하면,
위의 사진은 어떤 물체가 포물선 낙하운동을 하고 있을 때의 곡선입니다. 물체가 올라갈 때와 낙하할 때는 속도가 빨라졌다가 느려지거나 혹은 느려졌다가 빨라지는 운동을 하죠. 그러나 곡선의 최정점에서는 물체는 느린운동을 합니다. 마치 일순간 정지해 있는 것과 같은 착시를 불러일으키죠. 우리는 여기서 그러한 효과를 만들어보겠습니다.
animation의 animation-timing-function에는 animation의 진행속도를 설정할 수 있는데, 우리는 여기서 cubic-bezier라는 것에 집중을 해보겠습니다. cubic-bezier는 사용자가 임의의 운동 그래프를 커스터마이징할 수 있는 기능을 제공해주는데, 해당 링크로 들어가시면 직접 곡선을 그려볼 수 있는 화면이 나옵니다.
이제 거의 다 왔습니다. cubic-bezier효과를 사용하니 정점에서 마치 거의 멈춘 것 처럼 느리게 움직이는 걸 보실 수 있을겁니다. 이처럼 cubic-bezier는 매우 유용하게, 또 흔하게 사용되는 효과이니 기억해두시면 좋겠네요.
이제 남은 작업은 단 하나입니다. 각 도형을 적절히 움직이게끔 위치를 설정해주는 일만 남았습니다. 여기서 한 가지 더 추가하자면, 생동감을 넣어주기 위해 도형에 rotateZ 속성을 넣어주겠습니다. roateX는 X축을 기준으로, rotateY는 Y축을 기준으로 이미지를 상하 혹은 좌우 반전을 시키지만 rotateZ는 시계/반시계 방향으로 이미지를 돌릴 때 사용하는 속성입니다.
가장 상단의 #wrapper에 대한 기본적인 레이아웃을 만들어주었습니다. 작업은 400px · 400px에서 진행하려고 합니다. 그리고 #wrapper의 자식으로 #cover-img가 있는데, 이 것은 최초에 보여줄 화면을 나타내는 div입니다. position 속성을 주어서 부모인 #wrapper의 위치와 겹쳐지게끔 만들어 주시면 됩니다.
#slide-img div는 뒤에 가려져 있다가 마우스가 hover되는 순간에 나타나도록 설정할 영역입니다. 우선은 위치와 크기를 똑같이 설정해줘야 하겠죠.
여기서부터 이해가 중요합니다. 그 다음에는, #slide-img 안에 8개의 div를 그려넣도록 하겠습니다. 그리고 각각의 div는 폭이 50px, 높이가 400px이 되도록 설정을하고, 각각의 영역에 맞게 이미지를 나누어서 갖는 형태가 되도록 해보겠습니다. 즉, 이러한 형태가 되도록 만들어보는 겁니다.
원래의 이미지가 있다면, 우리가 원하는 형태는 위의 그림과 같습니다. 8개로 나누어진 div는 각 영역에 맞게끔 이미지를 잘라서 가지고 있고, 순번에 따라 번갈아가면서 위, 아래로 배치되어 대기 상태로 있게끔 하고 싶습니다.
설정된 background-position의 x좌표가 음수(-) 값임에 주의하세요. 우리가 이해하는 프로세스의 진행은 마치 하나의 이미지를 8개의 div가 영역별로 나눠갖는 것처럼 생각되지만, 실제로는 8개의 div가 모두 배경 이미지를 각각 가지고 있습니다. 기억이 나지 않으신다면 .slide에 설정된 내용을 확인하세요. 그렇기때문에, .slide-2부터 .slide-8은 시작위치가 점점 옆으로 옮겨지고 있습니다. 그 말은 다시 말해서 각 div에 설정된 배경이미지 또한 시작점이 옆으로 계속 밀린다는거죠. 결국에는 이미지가 계속해서 옆으로 8개만큼 겹치는 형태입니다. 그러나 겹치지 않는 이유는, 우리가 div의 넓이와 높이를 직접 설정해주어 겹치지 않게 해주었기 때문이겠죠. 이해하시나요?
그래서 예로 들어 .slide-2를 보자면, div의 시작위치는 top:40px 만큼, left:50px만큼입니다. 여기서 background-position을 50px만큼 양의 값으로 설정해버리면 이미지가 오른쪽으로 이동할까요, 아니면 왼쪽으로 이동할까요? 바로 오른쪽으로 이동합니다. 그러면 이미지의 시작지점이 오른쪽으로 밀리게되면 그 밀리는 만큼의 공간에는 어떤 것으로 채워지게 될까요? 직접 실행해보시는 것을 추천드립니다.
우리는 여기서 이미지가 분할되는 현상을 구현하고 싶은 것이기 때문에 background-position:-50px로 음의 값을 설정해주어 배경이미지를 왼쪽으로 이동시킬 필요가 있습니다. 그렇게하면 이미지가 어디서부터 보여질 것인지(-50px 지점부터) 제대로 설정할 수 있는거죠.
이제부터는 애니메이션을 설정해보겠습니다. 애니메이션은 jQuery를 사용하면 아주 간단하게 해결되는 문제이므로 한 번에 구현해보도록 하겠습니다.
먼저, 주석으로 감춰놓았던 #cover-img를 다시 불러와봅시다. 그러면 어떻게 되나요, 이미지가 두개가 겹쳐버리게 되죠? 이럴 때 사용하는 것이 z-index 기능입니다. z-index는 마치 x,y에 이은 3차 z축이 있다고 가정할 때, z축의 어디에 이미지를 위치시킬 것인지를 결정짓는 것과 같습니다.
그림과 같이 default의 값은 0입니다. 건물의 층의 높이와도 비유될 수 있겠습니다. #cover-img는 #slide-img보다 먼저 보여야하니까(위에 놓여야하니까) z-index의 값이 높게 설정이 되어야합니다. z-index의 값을 어떻게, 얼마나 크게 줘야하는지는 개발자의 마음입니다. 그러나, 향후의 어플리케이션의 규모가 확대될 수 있음을 감안해 충분히 쓰지 않는 건물의 층들을 만들어놓으면(z-index) 세입자가 들어왔을 때(클래스 혹은 아이디를 갖는 Html 태그) 들어갈 층이 없어서(z-index) 다시 재 작업을 할 수고를 덜 수는 있습니다.
그리고 추가된 부분을 보자면, jQuery를 이용해 #cover-img에 마우스가 올라갔을 때 각각의 클래스를 부여합니다. 그리고 #cover-img와 .slide에서는 transition 속성을 부여했습니다. 여기서(부모단에서) 속성을 부여하지 않고 직접 변화를 일으키는 곳에서(자식단에서) transition을 사용하게되면 어떤일이 발생하냐면, 예를 들어 hover의 경우라고 가정한다면, 마우스가 올라갈 때는 애니메이션이 잘 작동할지 몰라도 마우스가 영역 밖으로 나가는 순간 애니메이션이 종료되어 처음 상태 그대로 바로 돌아갑니다. 즉, reverse-animation 효과가 발생하지 않게 되는것입니다. 이 것은 애니메이션을 부여하실 때 꼭 고려해야 할 부분이므로 기억해두시면 좋습니다.
마지막으로 이것은 별 것은 아니지만, jQuery 부분에서 ES6에 새롭게 추가된 arrow function 기능을 사용했습니다. arrow function: () => {} 의 기능을 사용하려면 아직까지는 babel이라는 라이브러리가 필요한데, babel은 ES6를 ES5로 변환해주는 라이브러리입니다.
/* 추가된 부분 */ 을 주목해서 봐주세요. .line 클래스를 가지는 3개의 div를 추가해 width, height, margin를 갖고 있죠? 그리고 딱딱해보이지 않도록 역시 box-shadow와 border-radius를 설정해주었습니다.
여기서 주목할만한 부분은, #wrapper div의 상태 값이 position:absolute로 변경되었습니다. 이 이유는, CSS에서는 부모의 position 속성이 absolute 혹은 relative면 그 자식의 position이 absolute, relative일 경우 기준점이 부모의 좌측 최 상단에서부터(0,0 지점) 시작됩니다. 지금 보고 계시는 예제는 #wrapper의 시작 위치가 윈도우의 좌측상단으로 정해져있고 따로 움직이지 않았기때문에 여기서는 #wrapper의 position을 설정하지 않아도 괜찮습니다. 그런데 이 것을 움직이게 될 경우에는 자식 태그들을 position으로 움직이려면(특히 absolute의 경우) 정말 먼 길을 달려가야만 하겠죠? 그리고, 부모-자식 관계를 position으로 묶으면 추후에 코드 유지보수에도 많은 도움이 됩니다.
그리고 .line을 감싸는 #line-wrapper를 추가해 cursor에 대한 상태 값을 지정해 주었습니다. 이렇게 하지 않고 .line의 cursor를 변경하면, .line은 3개의 div이기 때문에 그 사이에 존재하는 공백(background)에서는 cursor가 적용되지 않습니다.
제 아무리 CSS가 날고 기어도 CSS는 CSS일 뿐, 액션에 대한 영역은 JS에게 맡겨야 하는 상황이 오게 마련이죠..
추가된 jQuery를 봐주시기 바랍니다. JavaScript를 쓰지 않고 jQuery를 사용한 이유는 jQuery가 DOM제어에 더 특화되어 있고 JavaScript를 사용하는 것보다 쉽게 구현할 수 있습니다. (편하신 분들은 JavaScript를 사용하셔도 괜찮습니다.)
.line들의 부모 div인 #line-wrapper를 클릭하게되면 각각의 아이디에 맞는 div를 찾아 각각 개별적인 클래스 네임을 부여해줍니다. toggleClass를 이용하면 경우의 수에 따라 addClass, removeClass를 매번 해줘야하는 상황을 피할 수 있죠. 저는 toggleClass를 더 선호하는 편입니다. 물론 내부적인 동작은 같을 겁니다.
추가된 CSS 코드에서는, 예를 들어, .line-top 클래스가 적용이 될 경우에 어떤 속성 값을 받을 건지를 설정을 해주었는데요. @keyframes를 사용하면 좀 더 복잡한 애니메이션 효과를 쉽게 구현할 수 있습니다. 직접 transform으로 구현해도 상관없지만 그럴 경우엔 transition까지 같이 사용해줘야하고, 애니메이션이 끝난 후에 상태를 어떻게 놔둘 것인지도 직접 정해줘야해서 까다로워지죠. forwards 속성을 지정하지 않으면 애니메이션이 끝남과 동시에 다시 처음의 상태로 돌아가게 됩니다. 저희는 이 다음의 애니메이션도 부여할 것이기 때문에 이대로 놔두겠습니다.
@keyframes에 대해 조금만 더 이야기를 확장해보자면, keyframes는 왜 나왔을까요? 단순히 transform과 transition을 사용하기 어렵기 때문에 나온 것일까요? 그렇지 않습니다. keyframes는 프로그래밍 언어의 존재 이유와도 같은 맥락에서 나왔습니다. 바로, 수 많은 작업이 발생할 경우를 대비해, 사람이 직접 모든 경우를 다 처리하기 어렵고, 힘들고, 시간과 노력이 많이 필요하기때문에 이를 대체할 수단으로 존재하는 겁니다.
가령, 한 페이지 내에서 애니메이션을 다루는 공간이 수 십개라고 가정을 한다면(이를테면 쇼핑몰 페이지의 상품 목록마다 다른 애니메이션이 들어가게 되는 경우), 어떻게 유지보수를 하시겠습니까? 또한, 하나 이상의 상품이 같은 애니메이션 효과를 가질 수 있다고 가정을 한다면, 유지보수의 문제는 더욱 커지게 됩니다.
그러나 CSS에는 함수를 만들기란 불가능하죠. 그러나 우리에게 단 한가지, 구원의 동아줄이 있다면 그건 바로 keyframes입니다. CSS의 창조주가 우리를 불쌍히(?) 여기셨는지 코드를 재활용할 수 있게 애니메이션 함수 기능을 허락해준거죠.
간혹 이런 사람들이 있습니다. "transform으로 한 줄이면 해결 될 문제를 keyframes를 사용해 불필요하게 왜 코드의 양을 늘리냐". 맞는 말이기도하고 틀린 말이기도 합니다. 내가 처한 상황이 keyframes을 사용하는 것이 정말 낭비되는 상황이라면 transform으로도 충분하고, 그렇지 않으면 반대의 경우가 더 낫겠죠. 그 보다도 저는 개인적으로, 코드의 양이 많고 적냐가 좋은 코드, 그렇지 않은 코드를 판가름짓는 기준이냐에 대한 질문에는 '그렇지 않다'는 입장입니다. 내가 이 코드를 한 달뒤에 봐도 이해할 수 있어야하고 다른 사람들도 내 코드를 쉽게 받아들일 수 있어야 좋은 코드라 생각합니다.
추가된 CSS에서는 위, 아래의 .line이 겹쳐지고 난 후에 rotate 속성을 주어 회전하는 듯한 느낌을 주었습니다. 애니메이션을 저렇게 두 줄 이상으로 작성하게되면 첫 번째로 지정된 애니메이션부터 실행이되고 그 다음 순서로 넘어가게 됩니다. 여기서 두 번째 애니메이션을 순서에 맞게 진행시키고 싶다면, animation-delay 효과를 이용해야합니다. 그렇지 않으면 지정한 애니메이션이 모두 다 동시에 발생하게 되죠. rotate을 할 때, translateY로 설정해주지 않으면 어떤 일이 일어날까요? .line-* 가 있었던 위치에서 rotate가 실행되게 됩니다. 왜냐하면, 지정한 애니메이션의 0% 지점에서 translateY를 따로 설정하지 않으면 자동적으로 초기 위치로 시작한다고 인식하기 때문입니다.
코드를 보시면 추가된 부분이 제법 많습니다. 우선 HTML을 보시면 .init 이라는 클래스를 지정해줬고 CSS에서는 이 클래스에서 animation을 none을 주고 우선순위를 부여합니다. 이렇게하는 이유는, 버튼을 다시 눌렀을 때 애니메이션을 반대로 지정해줘야 하는데 이런 기능을 가진 클래스를 처음부터 갖고 있으면 버튼을 누르기도 전에 reverse 애니메이션이 실행이 되어버립니다. 그런데 여기서 생각해야 할 것은, 애니메이션 실행 ↔ 애니메이션 반대로 실행 이 버튼의 클릭에 따라 한 가지만 실행이 되야하죠. 그리고 이러한 작업이 버튼 클릭에 따라 번갈아가면서 발생해야 합니다. 그 말은, .line-top에 있는 애니메이션은 그 반대의 애니메이션을 갖고 있는 .line-top-reverse와는 동시에 클래스로 존재해서는 안된다는 뜻이 됩니다.
그렇다면 버튼을 눌렀을 때 애니메이션이 실행되게 하기 위해선 버튼을 누른 후에 .line-top을 부여해줘야하고, 그 말은 다시, .line-top-reverse는 코드 실행 시작시에 처음으로 갖고 있는 클래스라는 뜻입니다. 그런데 윗 단락에서 설명한 것을 다시 말하자면, .line-top-reverse는 나름의 애니메이션을 갖고 있기 때문에, 코드 실행이 될 때 자동으로 실행이 되겠죠. 이 것을 어떻게 막냐,이 문제에 직면하게 됩니다. CSS에서는 조건문이라는 것이 없기 때문에 제어를 할 수가 없죠. 그래서 .init을 만들어 강제적으로 모든 애니메이션을 없애버린 것입니다. 그리고 jQuery 부분에서는 .line 클래스를 찾아 .init 클래스를 지워버리죠. 제가 만든 샘플 코드에서는 클릭 이벤트가 실행될 때마다 .init을 찾아 삭제하겠지만, 다른 방법들도 많으니 고민해보시기 바랍니다.
반대로 정의하고 싶은 애니메이션은 기존에 지정한 애니메이션을 반대로 작성해주기만 하면 금방이죠. 그런데 여기서 @keyframes line-mid-invisible에 주목해보세요. 의미없이 보이는 애니메이션이 들어가 있습니다. 시작과 끝에서 모두 scale로 같은 값을 지정한다는 것은 무슨 의미일까요? 저 부분은 그 자체로의 의미보다는 .mid-reverse 설정과 연결지어서 봐야합니다. 아무렇게나 만든 것 같은 line-mid-invisible 애니메이션이 먼저 지정이 되어 있고 그 다음에 본 애니메이션이 연결이 되어있죠. 이 것은 'animation delay'와 어느정도 연관이 있습니다.
최초의 클릭 후 애니메이션이 실행이 되면 클래스명의 네이밍은 어떻게 될까요. .line-mid이 생기고 .mid-reverse와 .init은 없어지겠죠. 그리고 다시 클릭하면 .mid-reverse 클래스명이 생기면서 reverse 애니메이션을 실행하게 될텐데, 우리가 원하는 #line-mid의 경우 rotate된 나머지 두 라인이 다시 원래대로 돌아올 때까지 기다렸다가 다음 애니메이션부터 같이 실행되길 원합니다. 그런 마음에서 animation-delay를 설정해 줬는데, 예상과는 다르게 애니메이션이 실행되기 전까지의 시간은 우리가 초기 속성값을 정해놓은 그 상태 그대로 기다리게 됩니다. 즉, 애니메이션 대기 큐에는 올라갔지만 기다리는 동안 이렇다할 상태변화가 없기 때문에 원래 갖고 있던 값 그대로 갖고 있는채로 기다리게 되는 것입니다.
우리는 mid가 보이지 않았다가 서서히 나타나는 효과를 원했으므로, 애니메이션을 기다리는 동안(animation-delay)에도 계속 보이지 않는 상태로 유지시켜주면 더 좋겠죠. 그래서 scale을 0으로 만들고 기다리는 작업을 하고 있는 것입니다. 직접 한 번 실행해보면서 이해를 해보도록 하세요.
이로써 햄버거 메뉴 버튼 만들기는 끝났습니다. 기초적인 기능이지만 세련된 느낌을 줄 수 있는 좋은 효과이기때문에, 한 번 익혀놓으시면 다른 스타일로도 얼마든지 응용이 가능한 매우 유용한 기술입니다.
설명을 위해 글이 다소 길어졌지만 끝까지 읽어주셔서 감사합니다. 다음에는 다른 효과에 대해 알아보도록 하겠습니다.
"비어있는 상태값(state)"이 만약 제대로 설정이 되어 있지 않다면, 결국에 이 문제는 개발자에게 더 큰 후폭풍을 안겨주게 됩니다.
(※ 작성자에 의한 의역임을 알림(or를 오타로 판단해 of로 해석). 원문 : The lack of default or “empty state” data can bite you another way, too)
바로 자식 컴포넌트에게 정의되지 않은(undefined) 상태값이 전달될 때 말이죠.
위의 예제를 조금 더 확장해 봅시다. 가령 Quiz 컴포넌트안에 있는 자식 컴포넌트로 list를 넘겨준다고 한다면,
문제가 보이시나요? Quiz가 처음으로 렌더링이 될 때, this.state.items 는 undefined 입니다. 무슨 말인가하면, ItemList 컴포넌트가 items 이라는 데이터를 undefined 상태로 넘겨받게되고, 결국에는 화면에서 Uncaught TypeError: Cannot read property 'map' of undefined 를 보게되는 것이란 말입니다.
만약 ItemList안에 propTypes에 대한 정의가 컴포넌트에 새겨져 있었다면 디버깅하기는 더 수월했겠군요.
이렇게 정의가 되어 있었다면 콘솔에 나오는 메시지는 다음과 같습니다.
"Warning: Failed prop type: Required prop items was not specified in ItemList."
(경고: prop type 오류: 필수요건인 items가 ItemList에 정의되어 있지 않음.)
그러나 여전히 Uncaught TypeError: Cannot read property 'map' of undefined 의 에러는 남아있습니다. propType의 유효성을 검사하는 것은 컴포넌트의 렌더링에 관한 문제를 해결해주지는 않습니다. 다만 알려주기만 할 뿐이죠.
그러나 최소한 이러한 방법은 디버그를 조금 더 수월하게는 해줍니다.
기본 Props 설정(Default Props)
한 가지 더 쉬운 방법이 있습니다. props의 default값을 설정해주면 됩니다.
Default props는 항상 최선책은 아닙니다. 이 방법을 사용하기전에 더 나은 해결책이 없는지, 이 방법이 그저 임기응변(band-aid solution)에 지나지 않는지 항상 확인하세요.
Default 값들을 설정하는 것이 그저 값들이 정의되지도 않아서 발생하는 수 많은 에러들을 모두 예방해줄 수 있을 것이라 생각하시나요? 그 전에 값(data)들을 제대로 정의하는 것을 먼저 고려하십시오.
아니면 prop이 단순한 선택적인 것에 불과하다고 말할 수 있습니까? prop이 전달되지 않은 상태에서 컴포넌트가 렌더링이 되는 경우에 대해서는 문제가 없다고 생각하십니까? 그렇다면 기본 값 설정에 대한 문제 해결을 받아들일 준비가 되었습니다.
이 문제는 몇 가지 방법으로 해결할 수 있습니다.
defaultProps 이용하기
이 메소드는 여러분의 컴포넌트가 상태(state)를 갖고 있지 않은 함수인지, React.Component를 상속받는 클래스인지에 얽매이지 않습니다.
이 메소드는 컴포넌트가 클래시 형식일 때, 여러분의 컴파일러가 ES7의 static initializer 문법을 지원할때만 동작합니다.
render 조작
이 방법은 아래에 있는 render 안에서, ES6의 destructuring syntax에 의해 다음과 같이 표현됩니다.
이 라인은 다음과 같은 의미입니다.
"items 키를 this.props에서 가져오고, 만약 undefined상태라면 빈 배열로 초기화한다"
인자 값(arguments) 조작
만약 컴포넌트가 함수형이라면, 아래와 같이 초기화를 해줄 수 있습니다.
요약
컴포넌트 라이프 사이클이 실행되는 동안에 이루어지는 비동기 호출은 컴포넌트가 데이터가 로드되기 전에 렌더링이 된다는 것을 의미합니다. 그래서..
constructor 안에서 state를 초기화하거나 빈 값을 적절히 처리해야 합니다.
디버깅을 더 수월히 하기 위해 ProTypes를 사용하십시오.
defaulProps를 적절히 활용하세요.
구조 변경(※ 의역, 원문: Destructuring syntax: 구문 파괴)은 깔끔하면서 쉽게 기본 값들을 설정할 수 있습니다.
실제로 JavaScript나 jQuery만을 이용해 어플리케이션을 개발했을 때를 생각을 해보자면, 하나의 HTML파일에 여러가지 모듈화된 js파일들을 불러왔었을 겁니다. 어플리케이션의 크기가 증가하면서 코드의 양도 자연스레 비례적으로 증가하였고 단편적으로 HTML의 양이 대폭적으로 늘어났다고 가정을 해보면, 우선 분리되어있지 않은 코드들이 가독성을 제일 먼저 떨어트릴 것입니다. 그리고 이러한 DOM들을 제어 · 관리하는데에 사용하는 jQuery의 양도 매우 많아지겠죠. 즉, 한마디로 말해 '관리의 효율' 문제라는 겁니다. 아무리 버그가 없고 이상이 없는 사이트인데 오늘만 산다는 마음가짐으로 코드 관리를 매우 비효율적으로 해놓는다면, 추후의 관리의 차원에서 너무 힘들어지겠죠. 나 혼자만 개발하는 것이 아니라 협업의 관계에 속해있다면 관리는 반드시 고려해야할 숙제 중 하나입니다.
다행스럽게도, React는 이러한 관리문제를 컴포넌트의 모듈화로 제법 해결해놓았습니다. 아래의 코드는 아주 간단한 jQuery 예제로 jQuery가 어떻게 DOM에게 간섭하는지를 보여줍니다. jQuery의 시작은 항상 $으로 시작하죠, 이 기호를 이용해 모든 DOM에 접근할 수 있습니다. (솔직히 제 개인적으로도 jQuery만큼 DOM관리하는데에 편한것도 없는 것 같습니다.)
언뜻 보면 React.js의 코드가 더 길고 복잡해 보입니다. HTML 코드는 jQuery의 코드를 기준으로 8줄이네요. 그리고 React는 코드를 컴포넌트라는 하나의 클래스를 만들어 모듈화를 통해 관리합니다. 즉, '뚜렷한 의미를 가지는 클래스들의 모듈화' 를 이용하는 것이죠. 이는 상당히 중요한 개념입니다. 제 개인적으로는 React가 jQuery보다 앞서있다고 생각되는 점 중에 하나입니다.
만약에, 어플리케이션이 방대해져서 HTML만 1,000줄이 필요하다고 가정을 해보면, 무수히 많은 클래스들과 아이디가 부여가 될 것이고 그에 따른 CSS제어, 액션제어들이 필요하겠죠. 이 모든 것들을 $.ready()에서 처리한다고 생각해본다면 얼마나 읽기가 힘들지는 눈에 선하죠? jQuery에서도 js파일을 나눠서 관리할 수 있습니다만.. 특정한 의미가 없이 그저 코드의 양을 줄이고자 나누는 작업은 오히려 가독성을 낮출 수 있습니다. 하나의 파일에서 시간을 조금만 들여서 보면 될 것을 파일의 분기때문에 이 파일 저 파일 번갈아가면서 봐야할 수도 있는거죠.
React는 1,000줄의 HTML에서 이런식으로 흐름을 분기합니다.
이런식의 의미있는 컴포넌트만 불러와 하나의 HTML을 만드는 것은 상당히 편리하고 강력합니다. 또 <로그인 />에서는 로그인에 필요한 액션 제어, <회원가입/> 에서는 그에 맞는 액션제어(Form 전송 등)를 알맞게 할 수 있고, 나중을 위한 유지보수의 첫 단추도 잘 넣게 되는 것이죠.
그러나, 한 가지 염두해두고 있어야 할 점은, React가 낫다, jQuery가 낫다 아니면 혹은 다른 프레임워크들이 낫다고 생각해 한 가지만을 고집하는 것은 어리석은 생각입니다. 공식 홈페이지에서도 나와있듯이, React는 MVC 패턴을 구현하기 위해 제작된 프레임워크가 아닙니다. 그저 확장성과 관리효율성 차원에서 고려되어져 만들어진 우수한 성능의 자바스크립트 라이브러리일 뿐입니다. 기본적인 베이스를 잡고 있는 프레임워크나 라이브러리는 존재하되, 필요한 기능을 더 편리하고 강력하게 구현하는 기능을 제공해주는 것이 있다면, 현재 사용중인 개발언어의 기능과 비교해보고 더 나은 것을 선택하는 것이 바람직하다고 할 수 있습니다.
