Conversation
|
조용하더니 다 햇내... 소히 공주님 파이팅~ |
| const renderInitialLayout = () => { | ||
| const root = document.getElementById('app'); | ||
|
|
||
| root.innerHTML = ` | ||
| ${Header()} | ||
| <div class="grid grid-cols-1 lg:grid-cols-[1fr_360px] gap-6 flex-1 overflow-hidden"> | ||
| ${CartContainer()} | ||
| ${OrderSummary()} | ||
| </div> | ||
| ${Manual()} | ||
| `; | ||
| }; |
There was a problem hiding this comment.
첫 화면은 기본 값으로 다 그리고, 스토어 내 상태가 바뀔 때마다 innerHTML을 사용해 UI의 각 부분을 다시 그리는 구조로 잡아보았는데요. 새로 그려지는 파트를 구역별로 최대한 나누어서 아예 새로 그려지는 부분을 좁히려고 했지만! 그래도 한계가 있는 것 같아요. 다들 베이직 과제 진행하면서 렌더링 성능 최적화에 대해 어떤 고민을 했는지 어떻게 진행을 하셨는지 이야기 나누고 싶어요오
There was a problem hiding this comment.
오.. 코드 예쁘다!
저는 성능 최적화에 대해 아예 고려를 하지 않아서 드릴 말씀이 X..
(이딴식으로 리뷰해도 되나 제성함니다;)
There was a problem hiding this comment.
저도.. 성능을 생각하면서 과제를 진행하지는 않았어서 크게 도움을 드릴 수 있는 말이 없는데 궁금한 점이 있어요!
새로 그려지는 파트를 구역별로 최대한 나누어서 아예 새로 그려지는 부분을 좁히려고 했지만! 그래도 한계가 있는 것 같아요.
말씀해주신 대로 하면 렌더링 성능 최적화를 이룰 수는 있다고 생각하는데, 어떤 점에서 한계가 있으며 그게 왜 한계라고 생각했는지도 궁금해여
There was a problem hiding this comment.
제 베이직 과제는 말이죠.. 상태가 변할 때 전체가 리렌더링 된답니다... 렌더링 성능 최적화 고려를 못해써요,,,
사실 부분 렌더링 하고싶다! 까지는 생각을 했는데 어떻게 해야할지 감이 안와서 그냥 냅다 전체 렌더링 했어요..
베이직에서도 부분 렌더링을 고려했다니 또히님 멋져요
There was a problem hiding this comment.
말씀해주신 대로 하면 렌더링 성능 최적화를 이룰 수는 있다고 생각하는데, 어떤 점에서 한계가 있으며 그게 왜 한계라고 생각했는지도 궁금해여
가독성이 괜찮은 데까진 계속 렌더링 하는 구역을 줄이면 성능에 도움은 될 수 있겠지만
그래도 프로젝트 규모가 커지면 업데이트용 렌더 함수가 늘어나고 업데이트 구역에 대한 관리가 어려워질 거라는 생각입니다.
또 html을 다시 그린다는 것 자체가 input 값 상태 유지도 안 되고 ,, 포커스도 잃고 여러모로 유지보수에 단점이 많은 것 같아요!
There was a problem hiding this comment.
앞분들과 동일하지만, 저도 바꿔본다면 전체 innterHTML을 한번에 그리는 거보다, Header, Container, Manual을 직접 innerHTML로 그리는게 root에서 그리는 것 보다 낫지 않을까? 라는 생각은 듭니다!
There was a problem hiding this comment.
가독성이 괜찮은 데까진 계속 렌더링 하는 구역을 줄이면 성능에 도움은 될 수 있겠지만 그래도 프로젝트 규모가 커지면 업데이트용 렌더 함수가 늘어나고 업데이트 구역에 대한 관리가 어려워질 거라는 생각입니다. 또 html을 다시 그린다는 것 자체가 input 값 상태 유지도 안 되고 ,, 포커스도 잃고 여러모로 유지보수에 단점이 많은 것 같아요!
소희님의 답변에서 이미 방향을 잘 잡고 계시다는 게 느껴졌어요! 아까 ZEP에서도 잠깐 이야기해주셨지만, 말씀해주신 내용을 보면 Vanilla JS에서 리렌더링을 최적화하는 고민에서 출발해서, 지금은 더 확장된 주제인 “DOM 업데이트 시 상태를 어떻게 관리하고, 어떻게 똑똑하게 렌더링할 수 있을까?”라는 방향으로 이어지고 있는 느낌이에요.
그리고 이 주제는 아마 소희님이 가장 잘 이야기해주실 수 있지 않을까 싶어요. 저는 지금까지 React만 써봐서 아무래도 가상 DOM 기반의 구조에 익숙한데 소희님은 Vue도 직접 경험해보셨잖아요! 그래서 두 프레임워크가 리렌더링 최적화를 어떻게 접근하는지 비교해보면 굉장히 흥미로운 인사이트가 나올 수 있을 것 같아요. 이 과정에서 예전에 테오가 말했던 *"프론트엔드는 결국 한 방향으로 수렴하고 있다"*는 말에 공감할 수 있는 인사이트가 나올 수도 있을 것 같구요!
말로 하다보니 저도 너무 궁금한데, 여유되시면 나중에 관련해서 어떤 차이점이 있었는지도 공유해주시면 저도 많이 배울 수 있을 것 같아요 🙌
6 participants
과제 배포링크
esoby.github.io/front_6th_chapter2-1/
과제 체크포인트
기본과제
심화과제
과제 셀프회고
과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?
클린 코드 첫 과제! 멘토링 때도 말씀드렸지만, (정말)(정말) 재밌었어요!
업무로 개발을 하다 보면 코드의 질적인 개선보다 기능 구현에 집중하게 되기도 하고,
이미 구현된 틀 안에서 유지 보수를 조금씩 해나가는 경험을 많이 하는 것 같습니다.
그런데 오랜만에 구조까지 갈아엎을 수 있는 리팩토링 과제라 .. 아주 짜릿했습니다.
과제를 처음 받았을 때는 무슨 수단을 써서라도 완벽한 코드를 만들어 보자! 다짐 했었는데요.
그렇게 맘 먹고 시작해보니 막막하기도 하고 부담도 돼서 ai한테 자꾸 시키게 되더라고요.
파일부터 냅다 나누면서 중복 코드 제거하다가 결국 원상복구 하고 main에서 뚝딱뚝딱 했습니다.
과제를 마저 진행하면서 저는 결과보단 과정에 집중하기로 했어요.
아주아주 완벽한 코드라는 게 뭔지도 모르겠고! 그러기엔 나는 아직 부족하니까!
적어도 바로 전보다는 나은 코드를 만들어가잔 마음으로 차근차근 임했습니다.
기본 과제의 큰 방향성은 리액트스러움(?)으로 잡았습니다!
심화 과제로 빠르게 전환하고 싶기도 했고 확실히 깔끔한 흐름인 것 같아요.
처음부터 store에서 dispatch - subscribe - notify를 구현해 데이터 변동을 관리하고
컴포넌트 단위로 ui 코드를 분리해놨더니 리액트 전환이 아주 수월했습니다. 뿌듯.
앗 과제 초반 팀원들과 eslint와 prettier rule을 적용하기 위한 팀 컨벤션도 정해보았는데요!
다른 분들 코드 스타일도 엿볼 수 있고~ 합의해가려 서로를 설득하는 과정도 재밌었읍니다.
학메 송이님 조언으로 평소보다 빡빡하게 규칙을 넣어서 작업했는데 덕분에 가독성이 좋아져쒀요
과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?
심화 과제를 시작하고, 기본 과제를 리액트 프로젝트 위로 어찌저찌 이식해두긴 했지만
뷰로만 작업하다가 리액트를 다시 써보려니 ,, 정말 기억이 하나도 안 나더라고요 ㅠ.ㅠ
깊이있는 내용은 머릿속에서 다 증발해 버려서 더 멋찐 코드를 짤 수 없었습니다.
이번 기회로 다시 친해져야 할 것 같고 계속 꾸준히 돌아봐야 할 것 같읍니다.
고쳐도 고쳐도 돌아보면 아쉬운 게 있다는 게 이 과제에 대한 아쉬운 점이겠습니다.
감각적으로다가 코드를 휘리릭 클린하게 짜는 사람이었다면 더 많은 부분을 캐치할 수 있었을텐데!
고런 부분에 대한 공부를 게을리 했다는 게 스스로 아숩게 느껴졌습니다~ 이제 하면 되지~ 헤헤
팀원들과 코드 리뷰를 더더더 적극적으로 해보지 못 한 것도 아쉽게 느껴져요!
다음주차 땐 더 많이 수다 떨고 더 많이 질문하고 더 많이 ...! 서로서로 귀찮게 하겠다 ,,! 다짐했습니다.
과제 제출 후에 늦게서야 다른 분들 코드를 훔쳐보았는데 진짜 기깔나더라고요 아 질투난다 💦
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)