여러분 안녕하세요~
간만에 포스팅이라 좀 어색하네요... 이번에는 제가 플젝을 하면서 느낀 새로운 고찰에 대해 얘기해 보는 진실의 방 시리즈를 연재해 보려고 합니다.
바로 이번 주제는 플렉스 그리드입니다.
자~ 자~
제가 이번에 왜? 어쩌다가? 플렉스 그리드를 다시 살펴보게 되었는가?에 대한 경위 부터 말씀드리자면...
1. 발단의 시작.
사실 새로운 라이브러리인 리엑트를 3주차에 배우면서 모든 서막이 시작되었습니다.
리엑트 뭐 그 까이꺼~ 별거 있겠나?
그런데 이게 웬걸.... 시작은 나스부터였습니다....
나스= 즉, 기존의 자바스크립트로 구현한 css+html을 리액트로 옮기는 일종의 변환 작업입니다. 마치 이사가는 거죠... 그런데 아실 분들은 다 아실 겁니다...
생각보다 이사가기 전에 아무리 계산하고 재고 한다고 해도...
실제와 다르듯.... 나에게 있어 리엑트 나스 과정이 그랬다.
화면은 나오나.... 완전 망가진 css.
2주간의 노력이 수포로... 돌아간 느낌이랄까...
뭐가 문제일지 한 번 고민해 봤다.
1. 네스팅의 문제? css 네이밍의 문제?
2. 자바스크립트 자체의 구성의 문제?
=> 총 문제의 원인을 이렇게 총 2가지로 구분했다. 그래서 결국 첫 시도로 네스팅을 시도했다.
1. 네스팅의 문제.
네스팅이라 함은 결국 기존의 css를 scss라는 리엑트 전용 css파일로 바꿔주면서 발생하는 css네이밍의 중복을 해결해 주는 기법이었다. 즉, 원래 css에는 부모나 자식의 개념이 없지만, 새롭게 부모와 자식을 설정해 주는 것이다. 왜 이렇게 해주냐고 반문할 수 있다.
그 이유는 기존 html 기반의 css는 네이밍이 중복된다고 해도 다른 html 파일에 영향을 끼치지 않았다. 하지만, 리엑트에서는 그렇지 않았다. 만약 동일한 네이밍 css 클래스가 있다면 그것이 영향을 끼쳐서 제멋대로 뒤죽박죽이 된다. 따라서 다소 귀찮지만, 이렇게 리엑트로 넘어올 경우에는 기존 css를 이용하기 위해서는 나스 적용 시 네스팅 기법을 취해줘야 한다.
그래서 필자 역시 네스팅 기법을 적용했다.
그렇게 어렵지는 않았다. 그냥 가장 큰 컨테이너를 모부모로 선택하고 해당 클래스를 기존과 달리 여기서는 List.js에 맞춰 List_~ 이런 식으로 바꿔줬다. 그리고 css의 마지막 닫는 중괄호를 아래 전체의 css를 감쌀 수 있도록 위치시켰다. 그러면 과연 변화가 있었을까?
부푼 기대를 가지며 돌려봤지만... 또 똑같이 css가 망쳐진 화면 뿐....
다른 사람들은 분명... 이렇게만 하면 그냥 적용된다고 했는데.... 참.... 어이가 없었다. 그치만 뭔가 이때까지만 해도 아직은 희망을 가지고 있었다. ㅎㅎ
그래서 혹시나 싶어 위코드 커뮤니티 게시판에도 질문을 올리고 멘토분에게도 질문했다.
링크텍스트
그래서 답변으로 모듈 방법을 적용해 보라는 답을 받았다. 즉, 이 방법은 기존의 scss로 파일을 바꾸지 않고, 네스팅도 하지 않아 편해 보였다. 하지만, 그것은 착각!
결국 이 방법은 기존의 css가 재사용 가능하다는 장점은 있었지만, 그 안의 내부에 모듈 방식에 따라 되려 js파일 내부의 클래스네임 대신, 해당 부분을 {css.기존 클래스명}으로 바꿔줘야 했다.
하지만, 이게 결국은 클래스 명을 다르게 만든 것과 다른 점을 찾지는 못 했다. 결국 이는 근본적인 해결 방법이 아님을 깨달았다.
다른 동기에게 나의 문제 상황을 알려주니, 기존 html 구조를 의심했다. 설마 아니겠지라고 생각했었다.
"아니? 기존 html에서는 제대로 실행되는 게 왜 안되냐고요!"
"html 구조를 한 번 제대로 짰는 지 다시 보시겠어요?"
그때의 나는 그렇게 3일을 이것을 바꾸는 데에만 시간을 소비했다. 그러다 도저히 진전이 나지 않아 결국 대 수술을 결정했다.
-------------------다음편에서 계속---------------------------
