Today I did
- css는 왜 해도 해도 끝나지 않을까... 다 했다 싶으면 또 새로운 개선점이 보이는 것 같고 그렇다 처음 건드리기 시작한 지 장장 7일인데 (그 중 만 하루는 다른 기능적인 에러핸들링으로 보냈던 것 같지만) 아직도 완전히 끝이 나지 않았다니...
- 그래도 어제 새벽에 갑자기 삘 받아서 반응형을 얼추 완성해놓고 (스크롤 내리면 사라지고 올리면 생겨나도록 하는 메소드도 만들었다!) 오늘 많이 수정해서 한두가지 수정사항 외에는 다 된 것 같다 (고 말하면 부정 타나?) 처음 프로젝트 시작할 때는 반응형을 해야 한다는 생각에 덜컥 겁먹었는데 집중해서 하니까 이틀만에 뚝딱 만든 것 같다. 이럴 거면 지난 프로젝트에도 조금이라도 시도할걸!
- css를 스프린트 수준으로 하면서 느낀 점
-
%, vw/vh, rem 등이 능사는 아니다: 왠지 hard number가 아닌 '비율'을 사용하면 나중에 화면 크기가 변동될 때 유동적으로 엘리먼트 크기가 변화하니까 좋지 않을까 했는데 의외로 크게 도움이 되지 않았다. 오히려 일정 너비까지는 메인 엘리먼트는 크기를 똑같이 두고 마진만 줄어들다가 임계점이 오면 메인 엘리먼트가 한 단계 작아지고? 하는 것이 더 자연스럽고 그럴듯해 보인다. 특히 rem과 em의 사전적 차이는 알았는데 굳이 다르게 사용할 일이 있을까? 했는데 있었다.
(rem: root element의 폰트 크기를 기준으로 잡음
em: 부모 엘리먼트의 폰트 크기를 기준으로 잡음)뷰의 너비가 줄어서 랜딩의 폰트를 더 작게 재설정했지만, 모달의 경우 정보가 많지 않고 전체 화면을 차지하지 않으니 폰트 및 모든 비율을 전체화면 뷰일 때와 동일하게 두고 싶었다. 모달의 모든 자식 엘리먼트의 폰트 사이즈를 크게 설정해 두고 모든 여백 비율 등을 em으로 표현하니 루트 폰트와 별개로 표현할 수 있었다!
-
뷰 크기 단계를 몇 개 정해 놓고 그 단계에 따라 다른 비율의 뷰를 만들어 주는 것이 좋다: 현재 프로젝트 같은 경우는 러프하게 720px, 480px 기준으로 잡고 너비가 720이상, 720~480 사이, 480 이하일 때 다른 비율로 보이도록 했다. 높이는 사실 크게 상관이 없는 게 어차피 웬만한 웹사이트는 필연적으로 상하스크롤이 있기 마련이니까... 몇 가지 엘리먼트의 경우 해당 임계 포인트가 잘 들어맞지 않아서 추가적으로 960px, 400px 그룹을 따로 만들어 주었다.
-
모바일에 가까운 크기인 경우
display: none신공으로 자잘한 엘리먼트는 숨겨 준다: speaks for itself. 어차피 모바일은 간소화가 맞다. 여백도 최소화하고 내용에만 집중토록 한다. -
플렉스박스를 그렇게 많이 쓸 거면 그냥 애초에 모두 플렉스로 설정해두고 시작하자: 이건 그냥 display: flex 일억만번 쓰다가 내가 지쳐서...
-
콕 찝어 스타일링 해야 하는 엘리먼트가 아니더라도 일단 클래스나 아이디를 통일성 있게 만들어 두자: 이게 안 돼서 식별자 없는 엘리먼트를 스타일링 해야 할 때 부모의 부모, 부모의 부모의 부모 이런 식으로 선택해서 스타일링 해야 하면 나중에 태그 구조 변동이 되는 경우 난리가 난다. (그리고 태그 구조 변동은 나기 마련이라고 봐야 한다.)
-
재사용이 가능한 리액트 컴포넌트인데 위치에 따라 다르게 스타일링 해야 하는 경우: 가장 기준이 되는 모양을 먼저 잡아 두고 (앱 안에서 가장 흔하게 쓰일 스타일) 다른 위치에서 쫌쫌따리 추가변경제거해서 원하는 모양으로 바꾼다.
-
가장 작은 컴포넌트부터 스타일링해서 쌓아 올라간다: 이건 이번 프로젝트에 시도해 보지는 못했는데, 일단 대강의 레이아웃이 잡히고 나면 하위의 (그래서 여기저기 많이 재사용되는) 컴포넌트부터 스타일링 하는 것이 조금 더 섬세하게+효율적으로 작업 가능할 것 같다. 이번에는 무식하게 재사용성 무시하고 일단 페이지 별로 만들었더니 후작업에 시간이 너무 소요된 것 같다.
-
- 그래도 정 들었지만 이제 css 그만 보고 싶다... 누워서 천장 등을 봐도 플렉스박스밖에 생각이 안 난다.
- 그래도 나름대로 팀에서 배포맨, 디자인맨을 따로 두는 것은 잘했던 것 같다. 배포는 사실 한 계정을 두고 해야 하는데 여럿이서 왔다갔다 하는 것은 혼란스럽고 디자인도 앱 전체적인 통일감이 있어야 하니 비슷하다. 원래는 이렇게 영역을 갈라 버리는 것은 진정한 팀웍이 아닌건가(?) 라는 생각도 했었는데 커뮤니케이션이 잘 되는 한 자기 자리에서 자기가 맡은 부분의 책임자가 된다는 점에서 이것도 충분히 팀웍이 아닌가 싶다.
- 개인적으로 사실 기능적으로 더 추가하고 싶은 생각은 없고 마무리하고 랜딩에 넣을 기능 가이드 슬라이드 만들고 (이거 세련되게 만드는 것도 은근히 품이 많이 들 것 같다) 리팩토링하면서 (코드가 많이 지저분하다는 생각이 든다) 한 주를 보내고 싶은 마음이 있는데 다른 팀원 분은 기능이 충분치 않다는 생각을 하는 것 같다. 한 분이 피치 못할 사정으로 월, 화 동안 작업이 불가하게 되었는데 2인으로 가능할까 싶기도 한데 내일 회의를 해 봐야 할 것 같다.
Tomorrow I will
- css 마무리짓기
- 마지막 주 추가기능 구현 계획
반응형 작업했던 게 배포되어서 모바일 환경에서도 볼 수 있다. 귀여워 ㅎ
