서론
어제 MIL을 작성해서 TIL이 하루 밀렸다.
점점 한 숫자씩 밀려서 숫자가 좀 이상하구먼
화면 깜빡임
route 첫 부분에 target.innerHTML=""이 있어서 깜빡임이 발생한다.
따라서 그냥 지워봤는데, 깜빡임이 사라졌다.
..?
대신 제목을 바꿔서 api를 보내면, 현재 보고있는 화면documentPage의 editor부분 제목만 바뀌고
documentList의 documentItem부분은 바뀌지 않는다
이부분을 수정할 필요가 있어보인다.
=> App.js에서 editor에게 documentAutoSave를 내려줌. 포스팅할때, api를 다시 불러오게했다.
특정 도큐먼트만 불러오는게 나을것 같은데...nav에선 모든 도큐먼트를 불러와서 사용중이다.
따라서 nav에도 업데이트를 주려면, 결국 다 불러와야함...흠.
화면 깜빡임2
대대적으로 구조를 바꿨다(renderChildren으로 라우팅 컴포넌트 처리)
그런데, nav > DocumentList에서 innerHTML = ""처리를 하지 않으면, 노드가 계속 추가된다.
따라서 결국 공백처리를 했는데, 얘는 깜빡임이 없다.
실화냐?
=> 부모 전체를 깜빡이는게 아니라...일부 컴포넌트만 깜빡이는건 괜찮아서 그런듯함.
--
상태관리
내 상태는 App.js가 모두 관리한다. 따라서 핸들러도 App.js가 모두 관리한다.
=> 뎁스가 깊어지면 프롭스를 계속 전달해야하는 번거로움이 생긴다. 전역스토어 생성 필요.
라우팅
지금 라우팅 방식에 심히 고민이 있다.
setState로 라우팅을 처리하는것도 그렇고...코드가 깔끔하지 않은 기분
대대적으로 교체중이다.
node.prepend
선택한 노드의 맨 앞 자식으로 추가한다. 비효율적인 렌더링 방식 같은데..일단 진행해보고 생각하려한다.
10.23추가
배열의 맨앞에추가하는 건줄 알았는데,
생각보니 그저 트리 방식 이다.
비효율적인 렌더링은 아니었다. 하지만통일된 방식으로 하는게 좋아보인다
컴포넌트, SPA
SPA는 결국 미리 컴포넌트를 클라이언트측에서 만들어 두고(클래스형이면 인스턴스 생성), 렌더링(화면에 보이기. 노드를 추가한다.)하는 방식이라고 생각한다.
실제로 강의에서도 route처리를 컴포넌트들의 setState를 활용하여 하였다.
각 컴포넌트의 setState내부에서 render()를 호출하기때문에, 결국 render()로 넣은 innerHTML이 보여지는 것이다.
내가 하려는 방식도 굉장히 유사하다.
다만 기존의 innerText = ""로 초기화 하던 방식을 아예 replaceChildren(node)로 초기화 하려했더니
많은 수고로움이 따른다...
특히 상태를 주고받을때, 이젠 App에서 내려주지 말고 전역 스토어를 구현해서 해보려 한다.
이게 맞는것일까 의문이 들기도 하고...
그리고 계속 보여야하는 nav는 라우팅에서 예외처리하기 번거로워body > nav, main 이렇게 넣어버렸다.
main의 자식이 라우팅될때 항상 replaceChildren으로 초기화되니,nav는 prepend라는 메소드로 body바로 아래 자식으로 넣었다.
간단한 노션 페이지를 어렵게 만드는게 맞나싶다.
그래도 일단 생각나는것과 해볼수 있는건 해봐야지.
설계의 중요성
계속 갈아엎다보니, 설계의 중요성을 보다 뼈저리게 느낀다.
앞으로 과제가 얼마나 있을진 모르겠지만, 설계부터 완벽히까진 아니더라도
- 컴포넌트의 의존 관계
- 상태처리(부모기반 or 구독, 전역)
- UI 설계
- 라우팅
등 핵심 부분을 정립 해놓고 진행해야 편할 것 같다!
