좋은 발표 감사드립니다~! 11:58 리모트 데이터 스카마와의 의존성 12:15 아이디만 받고 모양은 전역에서 13:48 데이터 정리하기 14:31 ID 기반으로 데이터 불러오기 16:35 글로벌 ID기반 16:57 활용 사례1 17:19 GOI 최종적 흐름 === 18:38 활용 사례2 Refetch 19:32 의존성 살펴보기 21:36 느슨하게 변경한 데이터 스키마 23:22 비슷한 컴포넌트 23:37 새롭게 분리할까 재사용할까? 24:35 프로필 둥근 사각형? 25:00 모델 기준으로 컴포넌트 분리 === 26:20 비슷한 컴포넌트들 다른 경우 === 27:56 컴포넌트를 사용하는쪽의 코드 29:04 4가지 원칙 요약 31:22 GOI사용할때 아이디어를 얻은 부분 31:38 Relay 프레임워크는
좋은 발표 감사합니다! 발표자분께 질문이 두가지 있는데요. 1. 저는 회사에서 relay는 안써봤고 apollo client와 react-query만 써봤습니다. apollo가 가지는 normalized cache가 편할 때도 많았지만 mutation 후 invalidate할 때 캐시를 잘 관리하는 게 쉽지 않았습니다. 수정은 그나마 쉽지만 추가나 삭제에서는 정렬이나 페이지네이션 때문에 보통 전체 목록을 다시 가져오는 전략을 취했는데, 여기서 오는 성능 문제도 가끔 있었습니다. 릴레이도 normalized cache를 쓰는 걸로 보이는데 실무에서 캐시 무효화의 어려움은 어떻게 해결하셨는지 궁금합니다. 2. 리모트 데이터 모델을 기반으로 미래의 변화를 예측하고 재사용할 수 있게 컴포넌트를 나눈다고 하셨는데요. 예제에서도 보여주셨듯 다른 모델이지만 UI가 비슷한 컴포넌트들이 있습니다. 이들 중 작은 UI 엘리먼트 하나하나는 디자인 시스템으로 풀어서 상호 의존성을 없애기는 쉬운데, 레이아웃 패턴이 유사할 때는 디자인 시스템으로 풀기가 점점 어려워지더군요. 가능하면 이런 패턴도 시스템화하고 싶은데 또 미묘하게 다르게 디자인하고싶어하시는 니즈가 있어서.. 이러한 스타일, 또는 레이아웃의 중복은 어떻게 푸시는지 궁금합니다.
![[A4] Operate Micro-Frontends with Webpack 5 Module Federation](http://i.ytimg.com/vi/0Eq6evGKJ68/mqdefault.jpg)
![[A4] Operate Micro-Frontends with Webpack 5 Module Federation](/img/tr.png)
![[A1] Do more, with less. - Design system. What's next?](http://i.ytimg.com/vi/LmLchZ4tCXc/mqdefault.jpg)
![[10분 테코톡] 앨버의 리액트 렌더링 최적화](http://i.ytimg.com/vi/1YAWshEGU6g/mqdefault.jpg)
![[Track 1-2] 유인동 - ES6+ 비동기 프로그래밍과 실전 에러 핸들링](/img/n.gif)
좋은 발표 감사드립니다~!
11:58 리모트 데이터 스카마와의 의존성
12:15 아이디만 받고 모양은 전역에서
13:48 데이터 정리하기
14:31 ID 기반으로 데이터 불러오기
16:35 글로벌 ID기반
16:57 활용 사례1
17:19 GOI 최종적 흐름 ===
18:38 활용 사례2 Refetch
19:32 의존성 살펴보기
21:36 느슨하게 변경한 데이터 스키마
23:22 비슷한 컴포넌트
23:37 새롭게 분리할까 재사용할까?
24:35 프로필 둥근 사각형?
25:00 모델 기준으로 컴포넌트 분리 ===
26:20 비슷한 컴포넌트들 다른 경우 ===
27:56 컴포넌트를 사용하는쪽의 코드
29:04 4가지 원칙 요약
31:22 GOI사용할때 아이디어를 얻은 부분
31:38 Relay 프레임워크는
ㅎㅎ 정답만을 기억하고 사용하고 실천하는 것.. 뼈맞았네요..
주어진 문제를 문제로서 정확히 인지하고 질문하는 게 ㄷㅓ 중요하다는 말 정말 공감합니다!
30:21
컴포넌트 간 의존성을 어떻게 효과적으로 분리할 수 있을지, 의존성이 생겼을 때의 좋은 표현은 무엇일지 고민이었는데, 덕분에 새로운 관점을 얻을 수 있었습니다
특히 소개해주신 4가지 리팩토링 원칙이 인상 깊었어요
좋은 발표 감사합니다!
5번째 보면서 드디어 70% 이해가 가기 시작했습니다.
리액트 공부할 때는 아무것도 모른 상태에서 "저게 뭐야?" 하면서 보고, 클론코딩 하면서 조금씩 조금씩.. 근데 이제야 전부는 아니지만 주어주신 정보를 이해할 수 있게 되었습니다.
좋은 영상, 강의 감사드립니다.
새로운 시각 주셔서 감사합니다
들어가세요
발표 감사히 잘 봤습니다! 커스텀훅 로직을 보통 hook디렉토리에서 일괄적으로 관리했었는데 공통으로 사용되는 훅하고 특정컴포넌트에서 사용되는 훅을 쉽게 구분할 수 있을 것 같아요. 인사이트 감사합니다
이번주에 개발하면서 고민했던 부분을 싹 긁어주시네요 좋은 발표 감사합니다☺️
주니어 개발자인데 많은 인사이트를 얻고 갑니다!
항상 로직들이 흩어져있어서 유지보수에 힘든점도 있었는데 좀 더 많은 부분들을 생각하게 된 영상이었네요.
제가 짠 코드들을 조금씩 리팩토링 해가면서 다시 구조를 잡아봐야겠습니다
예시를 너무 잘 들어주셔서 이해 정말 잘 되었습니다!!! 컴포넌트를 바라보는 시각이 진짜 넓어진 것 같아요 감사합니다~~!!
좋은 강의 감사드립니다...!🥕
궁금한 것이 있습니다. 7분에서 보통 유저들이 왜 오른쪽 동작을 원하나요? (왼쪽같은 경우에 화면에 로딩된것 먼저 보여주니까 더 좋은거 아닌가요?)
하나하나 고민이 묻어나는 내용이네요.
너무 잘 보고 갑니다
많이 배워갑니다
타입스크립트를 사용하고 컴포넌트에 의존성이 많이 주입되면 스키마의 타입을 여기저기 끌고 다녀야해서, 어떻게 컴포넌트를 분리하는게 좋을까 항상 고민해 왔었는데, 비슷한 관점도 보고 새로운 관점도 봐서 너무 유익한 강의였습니다!! 잘보고가요~
메모: 관심사끼리 모으기, 데이터를 ID 기반으로 정리하기, 의존성 노출하기, 모델에 따라 컴포넌트 분리하기
좋은 발표 감사합니다.
감사합니다
잘 봤습니다~
잘보고갑니닷
영상 잘 봤습니다!
질문이 있는데요, useNodes를 사용하여 root에서 모든 데이터를 받아오고, 특정 id를 props로 내려주고 , useNode에서 특정 id를 통해 특정 데이터를 가지고 오는 건가요?
발표 정말 잘 들었습니다!!🙏
그리고 강의 자료가 정말 이해 쉽고 인상깊은데 혹시 어떤 걸 이용해 ppt를 만드셨는지 여쭤봐도 될까요?
Keynote 입니다 :)
마지막에 다시 기술어필 하셔서 혼란스럽지만 잘봤습니다
👍👍
컴포넌트 설계에 진짜 큰 도움이 되는 영상이네요! 혹시 가능하시다면 발표 자료도 공유해주셨으면 좋겠어요!
좋은 발표 감사합니다! 발표자분께 질문이 두가지 있는데요.
1. 저는 회사에서 relay는 안써봤고 apollo client와 react-query만 써봤습니다. apollo가 가지는 normalized cache가 편할 때도 많았지만 mutation 후 invalidate할 때 캐시를 잘 관리하는 게 쉽지 않았습니다.
수정은 그나마 쉽지만 추가나 삭제에서는 정렬이나 페이지네이션 때문에 보통 전체 목록을 다시 가져오는 전략을 취했는데, 여기서 오는 성능 문제도 가끔 있었습니다. 릴레이도 normalized cache를 쓰는 걸로 보이는데 실무에서 캐시 무효화의 어려움은 어떻게 해결하셨는지 궁금합니다.
2. 리모트 데이터 모델을 기반으로 미래의 변화를 예측하고 재사용할 수 있게 컴포넌트를 나눈다고 하셨는데요. 예제에서도 보여주셨듯 다른 모델이지만 UI가 비슷한 컴포넌트들이 있습니다. 이들 중 작은 UI 엘리먼트 하나하나는 디자인 시스템으로 풀어서 상호 의존성을 없애기는 쉬운데, 레이아웃 패턴이 유사할 때는 디자인 시스템으로 풀기가 점점 어려워지더군요. 가능하면 이런 패턴도 시스템화하고 싶은데 또 미묘하게 다르게 디자인하고싶어하시는 니즈가 있어서..
이러한 스타일, 또는 레이아웃의 중복은 어떻게 푸시는지 궁금합니다.
저도 2번의 문제를 자주 겪는데 답변이 궁금하네용 ㅜㅜ
저도 2번의 문제가 궁금합니다!
비슷한 UI는 재사용가능한 컴포넌트로 항상 설계를 해왔었는데 데이터리모트 스키마에 의존하여 컴포넌트를 분리하여 설계하는것은 새로운 관점이네요!
ID 기반으로 데이터 불러오기 > 이게 왜 Article 객체 자체를 받는것보다 더 이점이 있는지 모르겠습니다.