이러한 구성요소 실수를 저지르지 마세요

사실 구성 요소는 믿을 수 없을 정도로 간단합니다. 시작하는 것은 쉽습니다. 함수를 정의하고, JSX를 반환하고, 하루 만에 끝내세요. 하지만 깨끗하고 유지 관리가 가능하며 작업하기 즐거운 구성 요소를 작성하시겠습니까? 완전히 다른 게임입니다.

우리는 자신도 모르게 다음과 같은 구성 요소를 만듭니다.

• 한 눈에 이해하기에는 너무 큽니다.
• 테스트하기가 너무 어렵습니다.
• 너무 밀접하게 결합되어 재사용이 불가능합니다.
• 부진한 실적 판단으로 인해 부진합니다.

이 게시물에서는 개발자가 React 구성요소와 관련하여 저지르는 가장 일반적인 실수에 대해 안내하겠습니다. 더 중요한 것은 전체 앱을 찢지 않고 문제를 해결하는 방법을 보여 드리겠습니다.

이제 막 시작했든 수년간의 경험이 있었든 간에 이 팁은 기능적일 뿐만 아니라 유지 관리가 즐거운 구성 요소를 작성하는 데 도움이 될 것입니다.

"모든 구성 요소" 안티 패턴

우리 모두가 저지르는 고전적인 실수인 Everything 구성 요소에 대해 이야기해 보겠습니다. 여러분도 본 적이 있을 것입니다. 작고 순수하게 시작될 수도 있습니다. 아마도 간단한 양식이나 대시보드로 시작될 수도 있습니다. 조금 빨리 진행하면 이제 상태 관리, API 호출 처리, 데이터 형식 지정 및 모닝 커피 끓이기 작업을 수행할 수 있습니다.

// Please, no more of this
const UserDashboard = () => {
  const [userData, setUserData] = useState(null);
  const [orders, setOrders] = useState([]);
  const [notifications, setNotifications] = useState([]);
  const [settings, setSettings] = useState({});
  const [isEditing, setIsEditing] = useState(false);
  const [activeTab, setActiveTab] = useState('profile');

  // 15 separate useEffects
  // 10 different event handlers
  // Multiple conditional renders
  // 300+ lines of chaos
};

익숙한 것 같나요?

당신이 유죄인지 확인하는 방법

다음과 같은 경우 구성 요소가 "모든 구성 요소"로 바뀔 수 있습니다.

• 상태 과부하: 3~4개 이상의 개별 상태를 추적하고 있습니다.
• 끝없는 스크롤: 특정 기능이나 로직을 찾는 데 너무 많은 시간을 소비합니다.
• 종속성 팽창: useEffect 종속성은 주간 쇼핑 목록처럼 보입니다.
• 기능 크리프 거부: 기능 하나만 더 있어도 문제 없을 거라고 스스로에게 계속해서 다짐하고 있습니다.

무너뜨리기

해결책은? 하나의 모든 구성 요소 대신 책임을 더 작고 집중된 부분으로 나누세요.

// A cleaner, smarter approach
const UserDashboard = () => {
  return (
    <div>
      <userprofile></userprofile>
      <orderhistory></orderhistory>
      <notificationcenter></notificationcenter>
      <usersettings></usersettings>
    </div>
  );
};

주요 원리: 논리 > 공들여 나열한 것

리팩토링할 때 화면에 보이는 방식에 따라 구성 요소를 분리하지 마세요. 책임별로 나누십시오. 스스로에게 물어보세요: 이 기능이 자체 구성요소로 사용될 자격이 있습니까? 사용자 프로필이나 주문 내역과 같은 고유한 항목을 처리하는 경우 아마도 그럴 것입니다.

팁: 좋은 구성 요소는 한 가지 일을 하고 잘 수행합니다. 목적을 한 문장으로 설명하는 데 어려움을 겪는다면 너무 많은 일을 하려고 할 가능성이 높습니다.

프롭 드릴링 지옥

별로 재미없는 '소품 넘기기' 게임에 대해 이야기해보겠습니다. 깊게 중첩된 하위 항목에 도달하기 위해 동일한 소품을 여러 구성요소를 통과한 적이 있다면 소품 드릴링 지옥에 갇힌 것입니다.

// Please, no more of this
const UserDashboard = () => {
  const [userData, setUserData] = useState(null);
  const [orders, setOrders] = useState([]);
  const [notifications, setNotifications] = useState([]);
  const [settings, setSettings] = useState({});
  const [isEditing, setIsEditing] = useState(false);
  const [activeTab, setActiveTab] = useState('profile');

  // 15 separate useEffects
  // 10 different event handlers
  // Multiple conditional renders
  // 300+ lines of chaos
};

이러한 접근 방식은 짜증스러울 뿐만 아니라 장기적인 문제를 야기합니다. 사용자 속성의 이름을 바꿔야 한다고 상상해 보세요. 갑자기 5개 이상의 장소에서 업데이트하고 있습니다. 더 나쁜 것은 구성요소를 사용하지도 않는 데이터에 연결하게 된다는 것입니다.

이 문제를 해결하는 방법

소품을 가지고 뜨거운 감자 놀이를 할 필요가 없습니다. 드릴링을 완전히 방지할 수 있는 두 가지 실용적인 솔루션은 다음과 같습니다.

1. 공유 데이터에 대한 컨텍스트 사용

앱의 여러 부분에서 데이터 조각에 액세스하는 경우 React의 Context API를 사용하여 작업을 단순화할 수 있습니다.

// A cleaner, smarter approach
const UserDashboard = () => {
  return (
    <div>
      <userprofile></userprofile>
      <orderhistory></orderhistory>
      <notificationcenter></notificationcenter>
      <usersettings></usersettings>
    </div>
  );
};

2. 유연성을 위해 컴포지션 사용

props를 레이어에 강제로 적용하는 대신 필요한 것만 전달하도록 구성 요소를 재구성하세요.

// This is exhausting
const App = () => {
  const [user, setUser] = useState({});
  return (
    <layout user="{user}">
      <sidebar user="{user}">
        <navigation user="{user}">
          <usermenu user="{user}"></usermenu>
        </navigation>
      </sidebar>
    </layout>
  );
};

주요 시사점

컨텍스트는 사용자 정보, 테마 또는 전역 설정과 같은 앱 전체 데이터에 적합합니다. 그러나 항상 최선의 선택은 아닙니다. 과도하게 사용하지 마십시오. 현지화된 상태의 경우 드릴링을 완전히 방지하기 위해 구성요소 구조를 조정할 수 있는지 생각해 보세요.

목표는 구성 요소를 명확하고 유지 관리하기 쉽게 만드는 것입니다. 프롭 드릴링을 피하면 시간, 좌절감, 그리고 수많은 골치 아픈 문제를 줄일 수 있습니다.

조기 최적화 함정

아마도 조기 최적화가 모든 악의 근원이라는 유명한 인용문을 들어보셨을 것입니다. 글쎄, 구성 요소 수준의 악에 오신 것을 환영합니다. 저는 그것이 두 번 필요할지 알기도 전에 모든 것을 재사용 가능하게 만들려고 노력하는 시대에 대해 이야기하고 있습니다.

일반적인 모습은 다음과 같습니다.

const UserContext = createContext();

const App = () => {
  const [user, setUser] = useState({});
  return (
    <usercontext.provider value="{user}">
      <layout>
        <sidebar>
          <navigation></navigation>
        </sidebar>
      </layout>
    </usercontext.provider>
  );
};

// Use it only where needed
const UserMenu = () => {
  const user = useContext(UserContext);
  return <div>{user.name}</div>;
};

구성요소가 자연스럽게 발전하도록 하세요. 지금 당장 필요한 것을 위해 구축하세요. 새로운 요구 사항이 발생하면 명확하게 정당화할 수 있는 경우 기능을 추가하세요. 성급한 최적화는 시간을 낭비하고 복잡성을 가중시키며 거의 성과를 거두지 못합니다.

기억하세요: YAGNI 원칙(You ARE'T Gonna Need It)은 구성요소에도 적용됩니다. 최고의 추상화는 실제로 해결 중인 문제에 직면했을 때 나타납니다. 과도한 엔지니어링이 적극적으로 느껴질 수도 있지만 항상 단순함이 승리합니다.

부작용 잘못된 관리

악영향 관리의 전형적인 예는 다음과 같습니다. 낯익죠?

// Focused components for better clarity
const Navigation = ({ children }) => {
  return <nav>{children}</nav>;
};

// Pass data only where required
const App = () => {
  const user = useUser();
  return (
    <layout>
      <navigation>
        <usermenu user="{user}"></usermenu>
      </navigation>
    </layout>
  );
};

일반적인 실수와 수정

1) 지저분한 데이터 가져오기

잘못된 데이터 처리는 해결하는 것보다 더 많은 버그를 생성합니다. 더 깔끔한 접근 방식은 다음과 같습니다.

// Behold, the over-engineered button
const Button = ({ 
  children,
  variant = 'primary',
  size = 'medium',
  isFullWidth = false,
  isDisabled = false,
  isLoading = false,
  leftIcon,
  rightIcon,
  onClick,
  customClassName,
  style,
  loadingText = 'Loading...',
  tooltipText,
  animationType,
  // ... 10 more props
}) => {
  // 50 lines of prop processing logic
  return (
    <button classname="{generateComplexClassNames()}">



<h3>
  
  
  Why This Hurts
</h3>

<ul>
<li>Your “simple” button now requires an instruction manual.</li>
<li>Most of those 15+ props will never be used.</li>
<li>Making updates becomes risky because you have to account for endless combinations.</li>
<li>Writing tests becomes painful, with a hundred possible scenarios to consider.</li>
</ul>

<h3>
  
  
  Better Approach:
</h3>

<p>Instead of building for every imaginable scenario, start small and let your components grow as needed.<br>
</p>

<pre class="brush:php;toolbar:false">// Start simple
const Button = ({ children, onClick, variant = 'primary' }) => {
  return (
    <button classname="{`btn" btn- onclick="{onClick}">
      {children}
    </button>
  );
}

// Create specific buttons when you actually need them
const LoadingButton = ({ isLoading, children, ...props }) => {
  return (
    <button>
      {isLoading ? 'Loading...' : children}
    </button>
  );
}

2) 정리를 잊는 중

항상 스스로 청소하십시오.

const UserProfile = ({ userId }) => {  
  const [user, setUser] = useState(null);  
  const [posts, setPosts] = useState([]);  

  // Dependency array woes
  useEffect(() => {  
    fetchUserData(userId);  
    fetchUserPosts(userId);  
    // No cleanup? Yikes.
  }, []); // eslint-disable-line react-hooks/exhaustive-deps  

  // Multiple effects, all tangled
  useEffect(() => {  
    const subscription = subscribeToUserStatus(userId);  
  }, [userId]);  

  // Cleanup? What cleanup?
  useEffect(() => {  
    const interval = setInterval(checkNotifications, 5000);  
  }, []);  
};

3) 경쟁 조건 무시

이 기술을 사용하여 요청이 중복되지 않도록 하세요.

// Improved version
const UserProfile = ({ userId }) => {  
  const { data: user, isLoading } = useQuery(  
    ['user', userId],  
    () => fetchUserData(userId)  
  );  

  // Keep concerns separate
  const { data: posts } = useQuery(  
    ['posts', userId],  
    () => fetchUserPosts(userId),  
    { enabled: !!user }  
  );  
};

빠른 팁

• useEffect를 사용하기 전에 생각해 보세요. 때로는 전혀 필요하지 않을 수도 있습니다.
• 집중 유지: 하나의 효과가 하나의 책임을 처리해야 합니다.
• 항상 정리: 구독, 간격, 이벤트 청취자에 주의가 필요합니다.
• 올바른 도구 사용: React Query와 같은 라이브러리는 데이터 가져오기 및 캐싱을 단순화합니다.
• eslint-disable로 속임수를 쓰지 마세요. 종속성 문제를 숨기는 대신 수정하세요.

성능 사각지대

부적절한 성능 문제에 대해 이야기해 보겠습니다. 그들은 모든 것이 괜찮아 보이기 때문에 레이더 아래로 날아가는 종류입니다. 그러나 그렇지 않을 때까지 말입니다. 침묵의 원인을 찾아 해결 방법을 살펴보겠습니다.

문제

다음은 미묘한 성능 문제가 있는 구성 요소입니다.

// Please, no more of this
const UserDashboard = () => {
  const [userData, setUserData] = useState(null);
  const [orders, setOrders] = useState([]);
  const [notifications, setNotifications] = useState([]);
  const [settings, setSettings] = useState({});
  const [isEditing, setIsEditing] = useState(false);
  const [activeTab, setActiveTab] = useState('profile');

  // 15 separate useEffects
  // 10 different event handlers
  // Multiple conditional renders
  // 300+ lines of chaos
};

문제를 발견할 수 있나요? 분석해 보겠습니다.

수정

1) 고가의 계산을 메모하세요

렌더링할 때마다 모든 것을 다시 계산하는 대신 useMemo를 사용하여 결과를 캐시하세요.

// A cleaner, smarter approach
const UserDashboard = () => {
  return (
    <div>
      <userprofile></userprofile>
      <orderhistory></orderhistory>
      <notificationcenter></notificationcenter>
      <usersettings></usersettings>
    </div>
  );
};

이렇게 하면 렌더링할 때마다 데이터를 다시 계산하고 이벤트 핸들러를 다시 생성하는 것을 방지할 수 있습니다. 또한 메모를 통해 불필요한 자식 컴포넌트의 재렌더링을 방지합니다.

2) 효율적인 상태 업데이트

부실한 상태 관리도 성능을 저하시킬 수 있습니다. 검색 결과와 같은 업데이트를 처리하는 더 좋은 방법은 다음과 같습니다.

// This is exhausting
const App = () => {
  const [user, setUser] = useState({});
  return (
    <layout user="{user}">
      <sidebar user="{user}">
        <navigation user="{user}">
          <usermenu user="{user}"></usermenu>
        </navigation>
      </sidebar>
    </layout>
  );
};

디바운싱을 사용하면 키를 누를 때마다 데이터를 가져오지 않으므로 불필요한 API 호출과 다시 렌더링이 줄어듭니다.

빠른 성능 팁

• 메모 기능을 과도하게 사용하지 마세요. 가치가 있을 때만 최적화하세요.
• 인라인 함수 피하기: 안정적인 참조는 성능을 향상시킵니다.
• 프롭을 예측 가능하게 유지: 얕고 안정적인 소품은 구성 요소의 효율성을 유지하는 데 도움이 됩니다.
• 큰 목록 분할: 반응 창과 같은 도구는 큰 데이터 세트를 우아하게 처리할 수 있습니다.
• 상태를 더 가깝게 이동: 실제로 필요한 상태만 관리하세요.
• DevTools를 사용한 프로필: 최적화하기 전에 항상 측정하세요.

결론

건축 구성요소는 엄청난 과학은 아니지만, 현실적으로 생각해 봅시다. 나쁜 습관에 빠지기 쉽습니다. 나는 이러한 실수를 모두 저질렀습니다(때때로 지금도 그렇습니다). 괜찮습니다. 중요한 것은 조기에 발견하고 수정하며 거친 코드베이스를 피하는 것입니다.

더 나은 구성 요소를 위한 빠른 체크리스트

✅ 단일 책임: 구성 요소의 작업을 한 문장으로 요약할 수 없다면 이제 분리해야 할 때입니다.

✅ 소품 관리: 소품을 레이어별로 전달하시나요? 대신 컨텍스트를 사용하거나 구성을 활용하는 것을 고려해 보세요.

✅ 상태 및 효과: 효과에 집중하고 적절하게 정리하며 최신 도구를 사용하여 복잡한 데이터 가져오기를 처리할 수 있습니다.

✅ 성능: 최적화를 위해 최적화하지 말고 먼저 측정하세요. 메모, 메모 사용, 콜백 사용 등의 도구를 필요할 때 스마트하게 사용해보세요.

✅ 단순하게 시작하세요. 언젠가 겪게 될 문제가 아닌 지금 겪고 있는 문제를 해결하세요.

최고의 구성 요소는 화려하거나 지나치게 영리하지 않습니다. 팀이 6개월 동안 시간을 ​​들이지 않고 읽고 유지 관리할 수 있는 구성 요소입니다.

기억하세요: 이는 엄격한 규칙이 아니라 지침일 뿐입니다. 가끔 깨뜨려도 괜찮습니다. 목표는 완벽함이 아닙니다. 나중에 다시 방문할 때 직업 선택에 의문을 제기하지 않도록 구성 요소를 구축하는 것입니다.

위 내용은 이러한 구성요소 실수를 저지르지 마세요의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!