Replies: 9 comments 12 replies
-
|
저는 사용성 관점에서 생각해봤어요. 반대로 사용성이 높은 코드에서는 선언적으로 상태를 넘겨주는 방식이 더 효과적일 것 같아요. |
Beta Was this translation helpful? Give feedback.
-
|
저의 경우는 조건을 인지하는 방식에 따라 세가지로 나뉘는 것 같아요!
function Example(){
return isLoading && <Loading/>
}
functino Example(){
switch(state){
case "READY":
return <Ready/>;
case "PROGRESS":
return <Progress/>;
case "DONE":
return <Done/>;
}
function Example(){
<AccessManager country={["KR", "US", "JP"]} version="2.6.10" fallback={<Fallback/>}>
<Content/>
</AccessManager>
}위의 사항들을 고려해봤을 때 위의 If 컴포넌트의 예시는 1번에 해당되는 것으로 보여서 저라면 삼항연산이나 논리연산을 사용할 것 같습니다! |
Beta Was this translation helpful? Give feedback.
-
|
저는 AND 연산자 Short-circuiting먼저, 예시JSX를 쓰니까 명확히 드러나지 않는 부분이 있는데요. 구체적인 JavaScript 코드로 살펴볼게요. 다음과 같이 <If condition={value != null}>
<span>값: {value}</span>
</If>JSX를 원래 JS 문법인 React.createElement(If, { condition: value != null }, [
// 이 라인은 value 값에 관계없이 항상 평가됨
React.createElement('span', {}, `값: ${value}`)
]);반대로, 다음과 같이 삼항 연산자를 사용하는 상황을 생각해 볼게요. value != null ? (
<span>값: {value}</span>
) : null다음 원본 코드를 보면, 완전히 value != null ? (
// value == null 이면 이 함수 호출이 완전히 무시됨
React.createElement('span', {}, `값: ${value}`)
) : null그래서 더 언어 레벨에서 안전하게 코드를 다룰 수 있어요. 이렇게 TypeScript에서 타입 안전성을 보장하기 위해서 AND 연산자나 삼항 연산자를 쓰는 것이 더 좋은 방향이라고 생각해요. |
Beta Was this translation helpful? Give feedback.
-
|
이 논의와 별개로.. 조건부 렌더링을 처리하는 방식은 한 프로젝트에서 하나의 방식으로 통일하는 것이 좋겠다는 생각도 덧붙이고 싶어요. 서비스를 만들 때 어떤 사람은 |
Beta Was this translation helpful? Give feedback.
-
이 말씀이 예전에 babel transpile을 거치고 나면 모든게 그 방식이 아니게 된 시점부터는 사실 JSX는 function call이 아니긴 합니다. 실제로 const content = <Content />;
if (condition) {
return content;
}한다고 해서 물론 저는 @raon0211 님 말씀대로 이런 경우엔 JavaScript 연산자를 그대로 쓰는게 맞다고 생각합니다. 이유는 이따가 적어볼게요.. |
Beta Was this translation helpful? Give feedback.
-
|
말씀 덧붙여주셔서 감사해요!
말씀하신 것처럼 |
Beta Was this translation helpful? Give feedback.
-
|
맞아요. 런타임에선 아무 문제가 없지만, 말씀주신대로 타입스크립트를 사용하는 장점이 사라져버리죠. 아주 대표적으로 이런 경우요: <If condition={data != null}>
<Component data={data} />
</If>
function Component({ data }: { data: string }) {
// ...
}위에 말씀드린건 현시점 리액트와 JSX의 동작에 대해 바로잡고 싶었던 것 뿐이고, 저도 의견 자체는 완전히 같습니다. |
Beta Was this translation helpful? Give feedback.
-
|
저는 선언적인 컴포넌트 사용의 장점을 조금 생각해 봤어요. 인지적 관점에서 비교적 우수하다.예를 들어, 아래와 같은 상태를 처리하는 컴포넌트를 구현한다고 가정해 볼게요.
// 기존 방식 (&&, 삼항 연산자 사용)
const OrderStatus = () => {
const { status, payment, shipping } = useOrder();
return (
<div>
{status === 'PENDING' && payment.status === 'WAITING' && (
<PaymentWaitingMessage deadline={payment.deadline} />
)}
{status === 'PROCESSING' && (
shipping.status === 'PREPARING' ? (
<PreparingShipment estimatedDate={shipping.estimatedDate} />
) : shipping.status === 'IN_DELIVERY' ? (
<InDeliveryInfo trackingNumber={shipping.trackingNumber} />
) : (
<DeliveredInfo deliveryDate={shipping.deliveryDate} />
)
)}
</div>
);
};기존 방식으로 작성된 코드는 가독성이 좋다고 생각되지는 않아요. 이유는 이렇습니다.
이제 선언적인 컴포넌트 // 선언적 컴포넌트 사용
const OrderStatus = () => {
const { status, payment, shipping } = useOrder()
return (
<div>
<If condition={status === 'PENDING' && payment.status === 'WAITING'}>
<PaymentWaitingMessage deadline={payment.deadline} />
</If>
<If condition={status === 'PROCESSING'}>
<SwitchCase
value={shipping.status}
caseBy={{
PREPARING: (
<PreparingShipment estimatedDate={shipping.estimatedDate} />
),
IN_DELIVERY: (
<InDeliveryInfo trackingNumber={shipping.trackingNumber} />
),
DELIVERED: <DeliveredInfo deliveryDate={shipping.deliveryDate} />,
}}
/>
</If>
</div>
)
}주관적일 수 있겠지만, 저는 이 방식이 훨씬 잘 읽힌다고 생각해요.
위의 장점들 덕분에 기능 명세 없이 코드만 봐도 렌더링 조건을 알 수 있을 정도로 명확하게 표현할 수 있어요. 얼마 전에 어느 아티클에서 읽은 내용인데요, 원본 글을 찾지 못해 기억나는 대로 재구성하자면 이런 내용이었습니다.
별도로 관리되는 문서는 최신을 보장할 수 없으며, 구현된 코드와 일치한다고 할 수 없어요. 사실은...저도 평소에 |
Beta Was this translation helpful? Give feedback.
-
|
예제에서 보여주신대로 삼항연산자를 겹겹이 쓰면 읽기가 어렵더라구요, const OrderStatus = () => {
const { status, payment, shipping } = useOrder()
return (
<div>
{(() => {
if (status === 'PENDING' && payment.status === 'WAITING') {
return <PaymentWaitingMessage deadline={payment.deadline} />
}
if (status === 'PROCESSING') {
switch(shipping.status) {
case 'PREPARING':
return <PreparingShipment estimatedDate={shipping.estimatedDate} />
case 'IN_DELIVERY':
return <InDeliveryInfo trackingNumber={shipping.trackingNumber} />
case 'DELIVERED':
return <DeliveredInfo deliveryDate={shipping.deliveryDate} />
default:
return null
}
}
return null
})()}
</div>
)
} |
Beta Was this translation helpful? Give feedback.
-
|
저는 리액트에서 조건부 렌더링을 어떤식으로 작성하냐를 넘어서, "선언적이다", 그리고 "가독성이 좋다"라는 이유로 컴포넌트의 형태로 만들어 사용하는 것 자체에 대해 이야기하고 싶은데요. 지금까지 많은 프론트엔드 코드 리뷰와 논의를 지켜보면서, 어느 시점부터 공감이 잘 안가기 시작했던 부분이 바로 '특정 패턴을 일단 컴포넌트로 만든 후 그것을 선언적이라고, 또는 가독성이 좋다고 평가하는 것'이었습니다. 아주 적합한 예시로, 위에서도 바로 언급될 만큼 많은 분들이 익숙하신 switch case 컴포넌트가 있습니다. <Switch
value={value}
case={{
a: <A />,
b: <B />,
c: <C />,
}}
/>자, 아주 선언적이고 가독성 좋은 예쁜 코드가 작성되었네요! 어라, 그런데 역으로 생각해봅시다. 그럼 아래 코드는 선언적이지 않은가요? 또는 가독성이 좋지 않은가요? switch (value) {
case "a":
return <A />
case "b":
return <B />
case "c":
return <C />
}두 코드 모두 "value가 잠시 리액트를 떠나서 생각해봅시다. 주어진 숫자 중에서 가장 큰 값을 뽑는 로직을 작성했을 때, 두 코드 중 무엇이 선언적이라고 느껴지시나요? const arr = [1, 2, 3];
let max = 0;
for (let i = 0; i < arr.length; i++) {
if (max < arr[i]) {
max = arr[i];
}
}const max = Math.max(1, 2, 3);저는 후자가 더 선언적이라고 생각합니다. 그 이유는, 전자는 결과를 어떻게 구하는지가 자세히 드러나지만, 후자는 원하는 결과가 무엇인지, 결과를 위해 무엇이 필요한지만 명확히 드러내고, 과정은 숨기기 때문이죠. 즉, '컴포넌트 사용'과 '선언적인 코드'는 서로 관계가 없다고 생각합니다. 반복되는 UI 렌더링 로직을 잘 추상화하여 선언적인 형태의 컴포넌트로 만들어서 사용할 때, 선언적인 코드가 되는 것이죠. 따라서 조건부 렌더링을 컴포넌트로 구현하는게 선언적인 측면, 가독성 측면에서 아무런 차이가 없으니, 다른 측면에서 어떤 이점이 있는지 살펴봐야 결정할 수 있을 것 같습니다. 첫 번째로 리렌더링 성능입니다. 우리는 부모 컴포넌트 전체가 불필요하게 리렌더링되는 것을 막기 위해, 자식 컴포넌트를 만들고 상태를 그 안으로 옮깁니다. 아래와 같이 말이죠. function Parent() {
return (
<ChildA />
<ChildB />
);
}
function ChildA() {
const [state, setState] = useState(); // state가 변경되면 ChildA 컴포넌트만 리렌더링됨
// ...
}그런데 두 번째로 타입 안전성입니다. 아래와 같은 discriminated union이 있다고 해봅시다. type Query =
{ status: "fethcing" } |
{ status: "success", message: string } |
{ status: "failed", reason: string };이때 JavaScript의 switch-case로 작성하면, TypeScript 컴파일러가 query.status 값에 따라 query.message, query.reason 프로퍼티의 존재 여부를 추론해줍니다. switch (query.status) {
case "fetching":
return <Loader />;
case "success":
return <SuccessPage message={query.message} />;
case "failed":
return <ErrorPage reason={query.reason} />;
}그런데 이를 즉, 오히려 컴포넌트로 조건부 렌더링을 했을 때 사용성을 넘어서 제품의 안정성까지 큰 손해를 보는 상황이 됩니다. 따라서 조건 분기를 컴포넌트로 작성하는 것은 선언적인 측면, 가독성 측면, 성능 측면, 안정성 측면 모두 아무런 이점이 없기 때문에, 그냥 JavaScript 기본 문법으로 분기하는게 더 옳다고 생각합니다. |
Beta Was this translation helpful? Give feedback.
-
|
지금까지 제가 선언라이팅(?) 당한 것이 아닌가... 되돌아보게 되는 코멘트네요. 새로운 인사이트 주셔서 감사합니다🙇 말씀해 주신 것처럼, switch-case 문이 단순하게 컴포넌트를 반환하는 경우에는 <div>
{switch (value) { // 오류 발생
case "a":
return <A />;
case "b":
return <B />;
case "c":
return <C />;
}}
</div>JSX에서의 switch-case 문저는 이 논의가 UI를 조건에 따라 보여주기 위한 코드가 JSX내에서 선언적이고, 가독성 좋게 표현될 수 있는 방법에 대한 것이라고 생각했어요. 1. 즉시 실행 함수를 사용하는 방법<div>
{(() => {
switch (value) {
case "a":
return <A />;
case "b":
return <B />;
case "c":
return <C />;
}
})()}
</div>이 경우는 개인적으로 JSX와 자바스크립트 문법이 섞여서 가독성이 비교적 좋지 않다고 생각해요. 2. 컴포넌트를 반환하는 함수로 호출하는 방법const renderComponent = (value) => {
switch (value) {
case "a":
return <A />;
case "b":
return <B />;
case "c":
return <C />;
}
};
const RootComponent = ({ value }) => {
return (
<div>
{renderComponent(value)}
</div>
);
};이 경우는 UI 렌더링을 위한 코드가 JSX에서 분리되어 있기 때문에 가독성이 좋지 않다고 생각해요. 또한, 컴포넌트를 반환하는 함수는 일반 함수가 아니라 컴포넌트로 선언해야 한다고 생각해요. 3. 컴포넌트로 분리하는 방법위의 const RootComponent = ({ value }) => {
return (
<div>
<RenderComponent value={value} /> // 어떤 컴포넌트를 언제 렌더링하는지 명시적으로 드러나지 않음
</div>
);
};여기서 조건과 그에 따른 컴포넌트가 외부에 드러난다면 구조상 말씀해 주신 타입 안정성 문제가 있어서 저도 SwitchCase를 사용할 때마다 고민이 되긴 합니다. 하지만 switch-case 문이 JSX에서 사용될 수 있는 형태로 바뀌어야 한다는 점을 고려해 보면... |
Beta Was this translation helpful? Give feedback.
-
|
코멘트에선 switch-case를 단독으로 사용했지만, 당연히 즉시 실행 함수와 함께 사용하는 것을 가정한 예제이긴 했습니다. 먼저, 저는 가독성을 '읽기 쉬운 정도'를 말하는 단어로 이해하고 있습니다. 즉, 코드를 읽기 쉽다는 것은 그 코드의 동작을 이해하기 쉽다는 것이죠. 그렇기에 저는 즉시 실행 함수가 함께 사용된다고 해서 읽기 어려워진다거나, 코드의 동작을 파악하기 힘들어진다고 생각하진 않습니다. 즉시 실행 함수와 함께 쓰이든, 혼자서 쓰이든 상관 없이, 그 코드의 동작은 그저 단순한 switch-case 분기일 뿐인걸요. JavaScript 문법과 JSX가 섞이기 때문에 가독성이 낮아진다는 말씀도 주셨는데, JSX는 원래 전부 분리되어 관리되었던 마크업, 스크립트를 JavaScript 파일 한 곳에서 관리할 수 있도록 만들어주기에 오히려 기존 대비 높은 가독성과 쉬운 유지보수를 자랑하는 JavaScript의 확장입니다. 즉, JavaScript 문법과 결합하여 사용하면서도, 기존의 형태와 똑같이 작성할 수 있는 것(예: 그리고 (저는 애초에 1번을 가정했었으니 논외긴 하지만) 2, 3번과 같이 JSX 수정이 번거로울 정도로 컴포넌트가 복잡해졌을 때, 그것을 별도 function 또는 컴포넌트로 분리해서 '가독성을 높히는 것'은 우리가 리액트에서 아주 흔하게 사용하는 패턴 중 하나죠. 즉, 말씀해주신 매우 간단한 예제들은 실제와는 거리가 멀고 이해를 위해 어느정도 끼워맞춰진 면이 크기 때문에 2, 3번의 불필요 여부와 가독성에 대해 논하기가 어렵다고 생각합니다. 결론적으로 1, 2, 3번 모두 가독성 측면에서 어렵게 느끼시는 이유가 사실 잘 공감이 되진 않습니다. |
Beta Was this translation helpful? Give feedback.
-
|
저는 약간 좀 더 논쟁적일(?) 수 있는 절차지향적이고 mutable 한 스타일 사용중입니다. #4 (reply in thread) 에서 @hoseungme 님이 짚어주신 것과 같이 React 에서는 컴포넌트를 JSX에서 사용한것과, 컴포넌트 함수가 호출돼서 생성되고 및 렌더링 되는 동작은 별개더라구요. 그래서 위에서 나온 예시들 몇가지를 제 스타일로 작성하면 #4 (comment) 이 예시코드는 다음과 같이, function Component() {
if (someCondition) {
return <A />
}
};#4 (comment) 이 예시코드는 다음과 같이 작성하겠습니다. function OrderStatus() {
const { status, payment, shipping } = useOrder();
let waitingMessage;
if (status === 'PENDING') {
if (payment.status === 'WAITING') {
waitingMessage = <PaymentWaitingMessage deadline={payment.deadline} />;
}
}
let deliveryInfo;
if (status === 'PROCESSING') {
if (shipping.status === 'PREPARING') {
deliveryInfo = <PreparingShipment estimatedDate={shipping.estimatedDate} />;
} else if (shipping.status === 'IN_DELIVERY') {
deliveryInfo = <InDeliveryInfo trackingNumber={shipping.trackingNumber} />;
} else {
deliveryInfo = <DeliveredInfo deliveryDate={shipping.deliveryDate} />;
}
}
return (
<div>
{waitingMessage}
{deliveryInfo}
</div>
);
};마찬가지로 조건문 뿐 아니라, map, filter, reduce 함수들도 별로 좋아하진 않아서 평범한 반복문 사용합니다. function EvenOdd(props: { lines: string[] }) {
const children = [];
for (let i = 0; i < props.lines.length; i++) {
if (i % 2 === 0) {
const even = <Even value={line} />;
children.push(even);
} else {
const odd = <Odd value={line} />;
children.push(odd);
}
}
return (
<div>{children}</div>
);
}; |
Beta Was this translation helpful? Give feedback.
-
|
@foriequal0 사실 리액트에서 이야기 하는 '선언적'인 스타일이라는 것은 UI 컴포넌트를 다룰 때의 선언적인 측면을 이야기 하고 있다고 생각하는데요(ex. 다만 코드가 수정을 겪는 과정에서 값을 받아주는 변수와 값을 조작하는 로직 간에 응집이 깨지거나 알아보기 힘들어질 가능성이 높으니 이런 부분은 잘 다루어 사용해주는 것이 좋겠지요 :) |
Beta Was this translation helpful? Give feedback.
-
|
'별로 좋아하진 않아서' 가 이유라기에는 마지막 예시를 map filter로 고쳤을 때 가독성이랑 작성 시 편의성, 의도치않은 변경 가능성 제거 등 너무 큰 장점들을 희생하시는게 아닌가 싶네요. |
Beta Was this translation helpful? Give feedback.
-
function EvenOdd(props: { lines: string[] }) {
const rendered = lines.map((line, index) => {
const isOdd = index % 2 === 1;
const isEven = index % 2 === 0;
if (isOdd) return <Odd value={line} />;
if (isEven) return <Even value={line} />;
});
return <div>{rendered}</div>;
};반복문을 선호하시는 이유가 무엇인지는 모르지만 나름 '반복문 스타일' 로 작성된 map 로직이 아닐까 합니다. |
Beta Was this translation helpful? Give feedback.
-
|
@saengmotmi 코멘트 감사합니다. 가독성과 응집성이 중요하단 것에는 이견이 없습니다. 상황에 따라 평범한 제어구문이 괜찮은 선택지일 수도 있다는걸 제시하고 싶었습니다. 제 스타일로 DOM 과 CSS 의 트리구조에 예민한 경우를 다룰 때에는 아래 예시처럼 코드를 읽는 흐름이 구조를 따르지 않는게 단점인 것 같더라구요. 장점으로는 탭 깊이와 괄호가 한결 얕아지고, 디버거를 꽂아 한 스텝씩 따라가기 더 쉽고, 조금 더 까다로운 제어구문을 적용하기가 쉽고(양날의 검이겠네요), 성능에 미미하게나마 도움이 된다는게 있겠습니다. function Foo(props: { lines: string[] }) {
const childen = [];
for (const line of props.lines) {
const li = <li className="item">{line}</li>;
children.push(li);
}
return <ul className="list">{children}</ul>;
}@nninnnin 반복문이 map/filter 로 잘 변환되지 않는 경우의 예시를 가져오고 싶었는데 제가 예시를 잘 고르지 못한 것 같습니다. 일반적인 제어구문들은 키워드가 확실히 있어서 문법강조도 잘 받고, 코드의 모양새가 특징적이어서 코드를 훑어보는데 유리해서 선호합니다. |
Beta Was this translation helpful? Give feedback.
-
|
@foriequal0 말씀대로 for loop의 장점이 제어가 더 직관적이고 편리한 부분에 있지만, 컴포넌트 렌더링에서 그 결과물이 루프 안에서 너무 자유롭게 제어되면 결국 렌더링의 결과를 예측하기가 힘들어지지 않을까 싶습니다. 다수가 충분히 예측 가능한 조건부 렌더링 로직이 목적이라면 저는 체이닝을 이용할 것 같기는 한데, 사실 함수형 컴포넌트 안에서 for loop으로 렌더링을 제어해 본 경험은 없어서 특정 상황에서 요긴할수도 있겠다는 생각이 들면서 새롭네요. 아무쪼록 새로운 시각을 공유해주셔서 감사합니다. |
Beta Was this translation helpful? Give feedback.
-
|
다들 좋은 의견 많이 남겨주셔서 감사합니다. 개인적인 추가적인 의견을 남겨봅니다. 하지만 동일하게 예를 들어, AB테스트를 수행하는 <ABTest
condition={condition}
truthyComponent={<></>}
falsyComponent={<></>}
/>해당 컴포넌트는 사실 이를 사용할 때 느낀 장점을 말씀드리자면, 실무에서는 서비스 내 여러 영역에서 AB테스트를 수행하는 케이스가 꽤 있을 것이라 생각합니다. 이때, 단순 조건식 혹은 논리 연산자로만 이런 케이스를 처리 했을 때 프로젝트 규모가 크다면 AB테스트 영역을 추적하는데 |
Beta Was this translation helpful? Give feedback.
-
|
먼저 좋은 주제 남겨주셔서 감사합니다. 저는 조건이 단순할때는 논리연산자나 삼항연산자를 사용하는 편입니다. 논리연산자나 삼항연산자가 그 자체로 나쁘다고 생각하진 않습니다. 다만 앞선 분들이 말씀하신 것처럼 조건이 복잡해져서 분기처리가 다양해질 때가 문제인듯 합니다. 확장성 예측가능성 타입추론등이 모두 어려워지기 때문입니다. 그럴떄 저는 early return과 추상화된 컴포넌트를 이용하여 처리하는 편입니다. 이를 통해 결합도를 낮추고 코드 가독성을 높힐 수 있다고 생각합니다. 컴포넌트는 jsx 내에서 statement를 사용할 수 없기에 사용하는 컴포넌트 같은데, 앞선 예제들이 모두 컴포넌트 내에서 return 문을 하나만 사용함으로써 예측 가능성과 가독성이 오히려 떨어지는 것 같습니다. 이와 관련하여 제가 번역한 블로그 포스트 하나와 ui 컴포넌트 추상화를 위한 글 하나를 첨부하겠습니다. https://wonderwalls.tistory.com/entry/컴포넌트-합성은-훌룡합니다-그런데 |
Beta Was this translation helpful? Give feedback.
-
|
여러 관점의 글이 있어서 재미있네요. 저도 복잡한 조건부 렌더링을 할 때 나름의 방식을 사용하고 있는데요. 저는 각 상태들의 가능한 조합을 하나의 변수 만들어서, ts-pattern의 match 문을 사용해서 표현하려고 합니다. 다른 분들은 어떻게 생각하시는지 궁금합니다. const Component() {
const [isLoading, setIsLoading] = useState(false)
const [hasError, setHasError] = useState(false)
const [data, setData] = useState(null)
useEffect(() => {
setIsLoading(true)
fetch('https://api.example.com/data')
.then(response => response.json())
.then(data => {
setData(data)
})
.catch(() => {
setHasError(true)
})
.finally(() => {
setIsLoading(false)
})
}, [])
const viewState = useMemo(() => {
if (isLoading) {
return 'loading'
}
if (hasError) {
return 'error'
}
return 'success'
}, [isLoading, hasError, data])
return (
<>
{match(viewState)
.with('loading', () => <LoadingView />)
.with('error', () => <ErrorView />)
.with('success', () => <SuccessView data={data} />)
.otherwise(() => null)}
</>
)
}
} |
Beta Was this translation helpful? Give feedback.
-
안녕하세요! 리액트로 코드를 작성하다 보면 조건부 렌더링을 할 일이 정말 많죠.
저는 보통 AND 논리 연산자(&&)나 삼항 연산자(?:)를 이용해서 조건부 렌더링을 처리하곤 하는데요.
최근 회사 코드를 살펴보다가, 아래처럼 선언적인 방식으로 조건부 렌더링을 구현한 걸 봤어요.
이런 방식이 익숙하지 않아서, 기존 방식(논리 연산자나 삼항 연산자)과 비교했을 때 어떤 장점과 단점이 있는지 궁금하더라고요.
혹시 이런 선언적인 방식을 사용하시는 분들이 많으신지, 의견 나눠주시면 감사하겠습니다.
333 votes ·
Beta Was this translation helpful? Give feedback.
All reactions