Berhenti Membuat Kesilapan Komponen Ini

Sebenarnya, komponen adalah sangat mudah. Mudah untuk bermula—takrifkan fungsi, kembalikan beberapa JSX dan panggilnya sehari. Tetapi menulis komponen yang bersih, boleh diselenggara dan menyenangkan untuk digunakan? Itu permainan bola yang berbeza.

Tanpa disedari, kami mencipta komponen iaitu:

• Terlalu besar untuk difahami sepintas lalu.
• Sangat sukar untuk diuji.
• Berganding rapat sehingga mustahil untuk digunakan semula.
• Lembap kerana keputusan prestasi yang lemah.

Dalam siaran ini, saya akan membimbing anda melalui kesilapan yang paling biasa dilakukan oleh pembangun dengan komponen React. Lebih penting lagi, saya akan menunjukkan kepada anda cara membetulkannya tanpa mengoyakkan keseluruhan apl anda.

Sama ada anda baru bermula atau mempunyai pengalaman bertahun-tahun, petua ini akan membantu anda menulis komponen yang bukan sahaja berfungsi, tetapi menggembirakan untuk dikekalkan.

Anti-corak "Komponen Semuanya".

Mari kita bincangkan tentang kesilapan klasik yang kita semua buat: komponen segala-galanya. Anda telah melihatnya—ia bermula kecil dan tidak bersalah, mungkin sebagai bentuk ringkas atau papan pemuka. Cepat ke hadapan sedikit, dan kini ia menguruskan keadaan, mengendalikan panggilan API, memformat data dan mungkin membancuh kopi pagi anda.

// 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
};

Kedengaran biasa?

Cara Mengetahui Jika Anda Bersalah

Komponen anda mungkin telah bertukar menjadi "komponen segala-galanya" jika:

• Kelebihan keadaan: Anda menjejaki lebih daripada 3-4 bahagian negeri yang berasingan.
• Tatal tanpa henti: Anda menghabiskan terlalu banyak masa untuk memburu fungsi atau logik tertentu.
• Ketergantungan bergantung: Kebergantungan useEffect anda kelihatan seperti senarai beli-belah mingguan anda.
• Ciri-ciri penafian rayapan: Anda terus memberitahu diri sendiri, hanya satu ciri lagi tidak akan menyakitkan.

Memecahkannya

Penyelesaian? Daripada satu komponen segala-galanya, bahagikan tanggungjawab kepada bahagian yang lebih kecil dan fokus.

// A cleaner, smarter approach
const UserDashboard = () => {
  return (
    <div>
      <UserProfile />
      <OrderHistory />
      <NotificationCenter />
      <UserSettings />
    </div>
  );
};

Prinsip Utama: Logik > Susun atur

Apabila pemfaktoran semula, jangan pecahkan komponen berdasarkan penampilannya pada skrin. Pisahkan mereka mengikut tanggungjawab. Tanya diri anda: Adakah fungsi ini layak untuk komponennya sendiri? Jika ia mengendalikan sesuatu yang berbeza—seperti profil pengguna atau sejarah pesanan—ia mungkin melakukannya.

Petua: Komponen yang baik melakukan satu perkara dan melakukannya dengan baik. Jika anda sukar untuk menerangkan tujuannya dalam satu ayat, kemungkinan besar ia cuba melakukan terlalu banyak.

Prop Menggerudi Neraka

Mari bincangkan permainan "lulus props" yang tidak begitu menyeronokkan. Jika anda pernah melepasi prop yang sama melalui berbilang komponen hanya untuk mencapai anak yang bersarang dalam, anda telah terperangkap dalam neraka penggerudian prop.

// 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
};

Pendekatan ini bukan sahaja menjengkelkan—ia mewujudkan masalah jangka panjang. Bayangkan anda perlu menamakan semula prop pengguna. Tiba-tiba, anda mengemas kininya di lima atau lebih tempat. Lebih teruk, anda akhirnya mengikat komponen pada data yang mereka tidak gunakan.

Bagaimana untuk Membetulkan Ini

Tidak perlu bermain kentang panas dengan prop anda. Berikut ialah dua penyelesaian praktikal untuk mengelakkan penggerudian sama sekali.

1. Gunakan Konteks untuk Data Dikongsi

Jika sekeping data diakses merentas bahagian berlainan apl anda, API Konteks React boleh memudahkan perkara.

// A cleaner, smarter approach
const UserDashboard = () => {
  return (
    <div>
      <UserProfile />
      <OrderHistory />
      <NotificationCenter />
      <UserSettings />
    </div>
  );
};

2. Gunakan Komposisi untuk Fleksibiliti

Daripada memaksa prop melalui lapisan, susun semula komponen supaya ia hanya menurunkan apa yang diperlukan.

// This is exhausting
const App = () => {
  const [user, setUser] = useState({});
  return (
    <Layout user={user}>
      <Sidebar user={user}>
        <Navigation user={user}>
          <UserMenu user={user} />
        </Navigation>
      </Sidebar>
    </Layout>
  );
};

Pengambilan Utama

Konteks berfungsi dengan baik untuk data seluruh apl seperti maklumat pengguna, tema atau tetapan global. Walau bagaimanapun, ia bukan selalunya pilihan terbaik-jangan gunakannya secara berlebihan. Untuk keadaan setempat, fikirkan sama ada struktur komponen anda boleh dilaraskan untuk mengelakkan penggerudian sepenuhnya.

Matlamatnya adalah untuk menjadikan komponen anda jelas dan boleh diselenggara. Mengelakkan penggerudian prop akan menjimatkan masa, kekecewaan dan sakit kepala yang tidak terkira di jalan raya.

Perangkap Pengoptimuman Pramatang

Anda mungkin pernah mendengar petikan terkenal tentang pengoptimuman pramatang sebagai punca segala kejahatan. Nah, selamat datang ke kejahatan peringkat komponen. Saya bercakap tentang masa-masa itu kita cuba menjadikan semuanya boleh diguna semula sebelum kita tahu sama ada kita akan memerlukannya dua kali.

Inilah yang biasanya kelihatan:

const UserContext = createContext();

const App = () => {
  const [user, setUser] = useState({});
  return (
    <UserContext.Provider value={user}>
      <Layout>
        <Sidebar>
          <Navigation />
        </Sidebar>
      </Layout>
    </UserContext.Provider>
  );
};

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

Biarkan komponen anda berkembang secara semula jadi. Bina untuk apa yang anda tahu anda perlukan hari ini. Jika keperluan baharu timbul, tambahkan ciri apabila anda boleh mewajarkannya dengan jelas. Pengoptimuman pramatang membuang masa, menambah kerumitan dan jarang membuahkan hasil.

Ingat: Prinsip YAGNI (You Aren’t Gonna Need It) juga terpakai kepada komponen. Abstraksi terbaik datang apabila anda benar-benar menghadapi masalah yang mereka selesaikan. Kejuruteraan berlebihan mungkin terasa proaktif, tetapi kesederhanaan menang setiap kali.

Kesalahan Pengurusan Kesan Sampingan

Berikut ialah contoh klasik pengurusan kesan buruk. Nampak familiar?

// 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} />
      </Navigation>
    </Layout>
  );
};

Kesilapan dan Pembetulan Biasa

1) Pengambilan Data Kucar-kacir

Pengendalian data yang buruk menghasilkan lebih banyak pepijat daripada diselesaikan. Berikut ialah pendekatan yang lebih bersih:

// 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-${variant}`}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

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

2) Melupakan Pembersihan

Sentiasa bersihkan diri anda:

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) Mengabaikan Keadaan Perlumbaan

Elakkan permintaan bertindih dengan teknik ini:

// 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 }  
  );  
};

Petua Pantas

• Berfikir sebelum menggunakan useEffect: Kadangkala, anda mungkin tidak memerlukannya sama sekali.
• Pastikan ia fokus: Satu kesan harus mengendalikan satu tanggungjawab.
• Sentiasa bersihkan: Langganan, selang waktu dan pendengar acara memerlukan perhatian.
• Gunakan alatan yang betul: Perpustakaan seperti React Query memudahkan pengambilan data dan caching.
• Jangan menipu dengan eslint-disable: Selesaikan isu pergantungan dan bukannya menyembunyikannya.

Bintik Buta Prestasi

Mari kita bincangkan tentang isu prestasi licik tersebut. Mereka adalah jenis yang terbang di bawah radar kerana semuanya kelihatan baik-sehingga tidak. Mari kita dedahkan punca senyap ini dan lihat cara membetulkannya.

Masalahnya

Berikut ialah komponen dengan beberapa perangkap prestasi halus:

// 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
};

Bolehkah anda melihat isu-isu tersebut? Mari pecahkan mereka.

Pembetulan

1) Menghafal Pengiraan Mahal

Daripada mengira semula segala-galanya pada setiap paparan, gunakan useMemo untuk cache hasil:

// A cleaner, smarter approach
const UserDashboard = () => {
  return (
    <div>
      <UserProfile />
      <OrderHistory />
      <NotificationCenter />
      <UserSettings />
    </div>
  );
};

Ini mengelakkan pengiraan semula data dan mencipta semula pengendali acara pada setiap paparan. Ia juga menghalang pemaparan semula komponen kanak-kanak yang tidak perlu dengan memo.

2) Kemas Kini Negeri yang Cekap

Pengurusan negeri yang lemah juga boleh membunuh prestasi. Berikut ialah cara yang lebih baik untuk mengendalikan kemas kini seperti hasil carian:

// This is exhausting
const App = () => {
  const [user, setUser] = useState({});
  return (
    <Layout user={user}>
      <Sidebar user={user}>
        <Navigation user={user}>
          <UserMenu user={user} />
        </Navigation>
      </Sidebar>
    </Layout>
  );
};

Menyahlantun memastikan kami tidak mengambil data pada setiap ketukan kekunci, mengurangkan panggilan API yang tidak diperlukan dan memaparkan semula.

Petua Prestasi Pantas

• Jangan terlalu menggunakan hafalan: Optimumkan hanya apabila ia berbaloi.
• Elakkan fungsi sebaris: Rujukan stabil meningkatkan prestasi.
• Pastikan prop boleh diramal: Prop cetek dan stabil membantu komponen kekal cekap.
• Pecahkan senarai besar: Alat seperti tetingkap reaksi boleh mengendalikan set data besar dengan anggun.
• Alihkan keadaan lebih dekat: Hanya uruskan keadaan di mana ia sebenarnya diperlukan.
• Profil dengan DevTools: Sentiasa ukur sebelum mengoptimumkan.

Kesimpulan

Komponen binaan bukanlah sains roket, tetapi biarlah menjadi nyata—mudah untuk terjerumus ke dalam tabiat buruk. Saya telah membuat setiap satu daripada kesilapan ini (dan kadang-kadang masih melakukannya). tak mengapa. Apa yang penting ialah menangkapnya lebih awal, membetulkannya dan mengelakkan pangkalan kod kasar.

Senarai Semak Pantas untuk Komponen yang Lebih Baik

✅ Tanggungjawab Tunggal: Jika anda tidak dapat meringkaskan tugas komponen anda dalam satu ayat, sudah tiba masanya untuk memecahkannya.

✅ Pengurusan Props: Melepasi prop melalui lapisan demi lapisan? Pertimbangkan untuk menggunakan Konteks atau memanfaatkan komposisi sebaliknya.

✅ Keadaan & Kesan: Pastikan kesan terfokus, bersihkannya dengan betul dan biarkan alat moden mengendalikan pengambilan data yang kompleks.

✅ Prestasi: Jangan mengoptimumkan untuk kepentingannya—ukur dahulu. Gunakan alatan seperti memo, useMemo dan gunakanCallback dengan bijak apabila diperlukan.

✅ Mulakan Mudah: Selesaikan masalah yang anda hadapi sekarang, bukan masalah yang mungkin anda hadapi suatu hari nanti.

Komponen terbaik tidak mencolok atau terlalu pintar—ialah komponen yang boleh dibaca dan dikekalkan oleh pasukan anda tanpa mengeluh enam bulan kemudian.

Ingat: ini bukan peraturan yang sukar, hanya garis panduan. Anda akan memecahkannya kadang-kadang, dan itu tidak mengapa. Matlamatnya bukanlah kesempurnaan—ia membina komponen yang tidak membuat anda mempersoalkan pilihan kerjaya anda apabila anda melawatnya semula nanti.

Atas ialah kandungan terperinci Berhenti Membuat Kesilapan Komponen Ini. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!