widgets 레이어의 본질적인 의미가 무엇이라고 생각하시나요?

의견 감사합니다 승완님☺️ 1번 내용은 동일하게 생각하고 있는 것 같아요  2번 답변에 대해서 더 논의해보고 싶은데요 ㅎㅎ아래 의견을 통해서 저는 layout이 shared에 위치해있으면 shared는 어떠한 비즈니스 로직이나 특정 페이지/위젯에 대한 지식을 알고 있지 않아야 되는 곳으로 이해했어요. 그런데 layout은 특정 페이지에 대한 정보(===레이아웃)를 알게 되는 것인데, shared로 들어가게 된다면 이 맥락이 FSD에서 정의한 shared와 상충된다고 판단했습니다. 이에 대해서는 어떻게 생각하실까요?

오! 의견 감사합니다! 답변 주신 내용에 대해서 또 궁금한 점이 생겼습니다. 개인적으론 features 와 같이 slice 간 참조가 불가능 한 경우 각 features와 entities를 묶는 것 자체가 고유한 가치 라고 생각해요. 상황에 따라 features, entities가 한 구간에 모여야할텐데 이 자체가 책임이자 가치가 아닐까 싶어요 widgets가 단순히 features와 entities를 한데 모으는 것을 넘어, 사용자 인터페이스 측면에서 어떤 추가적인 가치나 의미를 창출한다고 보시는 것일까요? 예를 들어, 특정 비즈니스 로직이나 데이터 흐름과 직접적인 연관이 없으면서도, 사용자 경험(UX) 측면에서 widgets 레이어가 담당하는 책임은 무엇이라고 생각하시는지도 궁금합니다 🙏🏻 layout의 경우 shared도 괜찮지 않을까? 싶었지만 layout 같이 children을 포함하는 요소가 shared에 있다면 계층 역전이 아닐까 하는 애매함이 들어 widgets에 두게 되었어요저도 사용하면서 애매하거나 많은 분들의 생각이 궁금한데 너무 좋은 질문 같아요!!! layout 컴포넌트가 shared에 위치하게 되면, shared가 pages나 widgets와 같은 구체적인 상위 레이어의 내용물을 '알고 있어야' 제대로 작동하게 되는데, 레이어의 본질적인 추상성과 범용성을 훼손하고, FSD가 지향하는 계층별 책임 분리 원칙에 위배된다고 이해했습니다. 맞을까요? 그러면 말씀주신대로 layout 컴포넌트가 widgets 레이어에 위치한다면, 이는 widgets 레이어의 정의를 'features와 entities의 조합'이라는 협소한 의미를 넘어, '사용자 인터페이스의 특정 부분을 구성하는 독립적인 시각적 단위'와 같은 더 넓은 의미로 확장해야 함을 시사한다고 볼 수 있을까요? 그렇다면 widgets 레이어의 포함 범위를 어떻게 정의하는 것이 합리적일까요? 더 깊은 의견이 궁금합니다!

widgets가 단순히 features와 entities를 한데 모으는 것을 넘어, 사용자 인터페이스 측면에서 어떤 추가적인 가치나 의미를 창출한다고 보시는 것일까요? 예를 들어, 특정 비즈니스 로직이나 데이터 흐름과 직접적인 연관이 없으면서도, 사용자 경험(UX) 측면에서 widgets 레이어가 담당하는 책임은 무엇이라고 생각하시는지도 궁금합니다 🙏🏻 이전 글에서 widgets의 가장 큰 역할은 독립적인 요소들을 한군데 모으는 중재자로서의 역할이라고 의견을 말씀드렸는데요. UX 측면으로 생각해보았을 때 features와 entities는 자신의 정보만 책임을 지지만, widget은 대부분 요소들의 배치, 구성을 담당하면서 <u>“이 요소들이 사용자에게 어떻게 보여지고, 무엇을 먼저 봐야하는가.”</u> 에 책임이 있다고 생각해요. layout 컴포넌트가 shared에 위치하게 되면, shared가 pages나 widgets와 같은 구체적인 상위 레이어의 내용물을 '알고 있어야' 제대로 작동하게 되는데, 레이어의 본질적인 추상성과 범용성을 훼손하고, FSD가 지향하는 계층별 책임 분리 원칙에 위배된다고 이해했습니다. 맞을까요? 그러면 말씀주신대로 layout 컴포넌트가 widgets 레이어에 위치한다면, 이는 widgets 레이어의 정의를 'features와 entities의 조합'이라는 협소한 의미를 넘어, '사용자 인터페이스의 특정 부분을 구성하는 독립적인 시각적 단위'와 같은 더 넓은 의미로 확장해야 함을 시사한다고 볼 수 있을까요? 그렇다면 widgets 레이어의 포함 범위를 어떻게 정의하는 것이 합리적일까요? 네 서희님이 말씀하신것 처럼 해당 컴포넌트에서 import 혹은 직접적인 참조는 아니지만 계층이 역전된다는 느낌이 들었어요. 위 의견과 비슷한 느낌이라고 생각되는데요. 말씀해주신 '사용자 인터페이스의 특정 부분을 구성하는 독립적인 시각적 단위’ 이 문장이 딱 들어맞는게 아닐까 싶어요. 단순한 조합이 아닌 UI의 배치, 로딩 및 에러등의 UX 부분 그리고 때에 따라 각 요소들의 독립성은 유지하면서 사용자의 use case에 맞는 협력의 역할을 담당하는 경험의 완성도를 높인 레이어라고 생각해요. 포함 범위는 어떠한 부분을 말씀하시는지 조금 애매한데요, 어떨때 widgets로 묶는지 단위에 대해서 말씀하시는건지 여쭙고 싶어요. 개인적으론 FSD의 layer들을 UX보단 DX에 맞춰서 생각해왔는데 다른 관점으로 생각해볼 수 있었던 것 같아요. 😊

포함 범위는 어떠한 부분을 말씀하시는지 조금 애매한데요, 어떨때 widgets로 묶는지 단위에 대해서 말씀하시는건지 여쭙고 싶어요. 저는 DX보다는 UX측면, 하나의 응집된 사용자 인터페이스 단위로 제공( === UI 블록) 하려고 해야 할때 widgets으로 묶어야 한다고 생각했어요. 해당 컴포넌트가 UI 상에서 명확하게 구분되는 하나의 독립적인 시각적 블록으로 인식되는가? 그리고 그 블록이 자신만의 특정 UI 목적과 책임을 가지고 응집되어 있는가? 예를 들면, 아래와 같은 것들이 있을 것 같습니다. • ProductCard제품의 이미지, 이름, 가격, '장바구니 담기' 버튼 등이 하나의 시각적 단위로 묶여 제품을 효과적으로 보여주는 카드. • UserProfileHeader: 사용자의 프로필 이미지, 닉네임, 간단한 상태 메시지 등 사용자 정보를 한눈에 보여주는 헤더 섹션 • onfirmationModal: 특정 액션에 대한 사용자 확인을 요구하는 팝업 창. (내부에 '확인' feature와 메시지 entity를 포함) 제가 생각했을때 위 컴포넌트들은 여러 하위 요소들을 포함하지만, 그 자체로 하나의 완결된 UI 경험을 제공하며 다른 곳에서도 재사용될 수 있는 잠재력을 가지기에 widgets이라고 판단했습니다. 이러한 구분 외에도 해당 컴포넌트가 하나 이상의 feature와/또는 entity를 가져와 사용자 유즈 케이스에 맞게 재배치하고 조직화하는 역할을 하는가? 도 기준점이 된다고 생각했습니다.&#x20; 왜냐하면 widgets은 하위 레이어의 요소를 가지고 오는 행위 자체로 이미 상호작용이 가능한 UI 단위니까요. 이러한 몇가지 기준점으로 widgets을 나누는 것 같은데, 막상 FSD관련해서 폴더링 진행하다보면 사람마다 가지고 있는 정의가 달라서 서로 생각하는 맥락을 맞추고 가는 것이 필요하다는 걸 느끼고 있습니다 🙏🏻 의견 나눠주셔서 감사합니다 ㅎㅎ