Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. React
Code

Pengantar yang Lembut untuk Higher-Order Components dalam React: Praktik Terbaik

by
Difficulty:BeginnerLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Sap (you can also view the original English article)

Ini adalah bagian ketiga dari seri Higher-Order Components. Pada tutorial pertama, kita mulai dari ground zero. Kami mempelajari dasar-dasar sintaks ES6, fungsi higher-order, dan Higher-Order Components.

Pola higher-order component berguna untuk menciptakan komponen abstrak-Anda dapat menggunakannya untuk berbagi data (keadaan dan perilaku) dengan komponen Anda yang ada. Pada bagian kedua dari rangkaian, saya menunjukkan contoh kode yang praktis dengan menggunakan pola ini. Ini termasuk routes yang dilindungi, membuat generic container yang dapat dikonfigurasi, melampirkan indikator pemuatan ke komponen, dll.

Dalam tutorial ini, kita akan melihat beberapa praktik terbaik dan dos dan kelalaian yang harus Anda perhatikan saat menulis HOC.

Pengantar

React sebelumnya memiliki sesuatu yang disebut Mixins, yang bekerja hebat dengan method React.createClass. Mixins memungkinkan developers untuk berbagi kode antar komponen. Namun, mereka memiliki beberapa kekurangan, dan akhirnya ide tersebut akhirnya terjerumus. Mixins tidak diupgrade untuk mendukung kelas ES6, dan Dan Abramov bahkan menulis sebuah posting mendalam tentang mengapa Mixins dianggap berbahaya.

Higher-order components muncul sebagai alternatif Mixins, dan mereka mendukung kelas ES6. Selain itu, HOC tidak perlu melakukan apapun dengan React API dan merupakan pola umum yang bekerja dengan baik dengan React. Namun, HOC memiliki kekurangan juga. Meskipun higher-order components lebih tinggi mungkin tidak terlihat dalam proyek yang lebih kecil, Anda bisa memiliki beberapa higher-order components yang dirantai ke satu component saja, seperti di bawah ini.

Anda seharusnya tidak membiarkan dirantai sampai pada titik di mana Anda bertanya pada diri sendiri pertanyaan: "Dari mana alat itu berasal?" Tutorial ini membahas beberapa masalah umum dengan pola higher-order component dan solusi untuk mewujudkannya.

Masalah dengan HOC

Beberapa masalah umum yang berkaitan dengan HOC tidak ada hubungannya dengan HOC sendiri, melainkan penerapan Anda terhadap mereka.

Seperti yang sudah Anda ketahui, HOC bagus untuk abstraksi kode dan membuat kode yang dapat digunakan kembali. Namun, bila Anda memiliki banyak HOC yang ditumpuk, dan jika ada yang tidak beres atau jika beberapa alat peraga tidak muncul, akan sangat sulit untuk melakukan debug karena React DevTools memberi Anda petunjuk yang sangat terbatas tentang apa yang mungkin salah.

Masalah nyata HOC

Untuk memahami kekurangan HOCs, saya telah membuat contoh demo yang menyembunyikan beberapa HOC yang kami buat di tutorial sebelumnya. Kami memiliki empat fungsi higher-order yang membungkus komponen tunggal ContactList itu. Jika kode tersebut tidak masuk akal atau jika Anda belum mengikuti tutorial saya sebelumnya, berikut adalah ringkasan singkat tentang cara kerjanya.

withRouter adalah HOC yang merupakan bagian dari package react-router. Ini memberi Anda akses ke riwayat properti objek dan kemudian melewati mereka sebagai prop.

withAuth mencari prop authentication dan, jika authentication benar, itu membuat WrappedComponent. Jika authentication salah, itu mendorong '/login' ke objek riwayat.

withGenericContainer menerima sebuah objek sebagai masukan selain WrappedComponent. GenericContainer membuat panggilan API dan menyimpan hasilnya di state dan kemudian mengirimkan data ke wrapped component sebagai alat peraga.

withLoader adalah HOC yang menyertakan loading indikator. Indikator berputar sampai data yang diambil mencapai state.

BestPracticeDemo.jsx

Sekarang Anda bisa melihat sendiri beberapa jebakan umum higher-order components. Mari kita bahas beberapa di antaranya secara rinci.

Dasar Dos dan Larangan

Jangan Lupakan Penyebaran Props di HOC Anda

Asumsikan bahwa kita memiliki sebuah authenticated = {this.state.authenticated } prop di bagian atas hirarki komposisi. Kita tahu bahwa ini adalah prop yang penting dan ini harus sampai pada komponen presentasi. Namun, bayangkan bahwa HOC menengah, seperti withGenericContainer, memutuskan untuk mengabaikan semua props.

Ini adalah kesalahan yang sangat umum yang harus Anda hindari saat menulis higher-order components. Seseorang yang tidak mengenal HOC mungkin merasa sulit untuk mengetahui mengapa semua props hilang karena akan sulit untuk mengisolasi masalah tersebut. Jadi, selalu ingat untuk menyebarkan props di HOC Anda.

Jangan Lewatkan Props yang Tidak Memiliki Keberadaan di Luar Scope dari HOC

HOC mungkin akan memperkenalkan props baru yang mungkin tidak berguna bagi WrappedComponent. Dalam kasus seperti itu, adalah praktik yang baik untuk menyebarkan props yang hanya relevan dengan komponen yang tersusun.

Higher-order component dapat menerima data dengan dua cara: baik sebagai function argument atau sebagai prop komponen. Misalnya, authenticated = {this.state.authenticated } adalah contoh prop, sedangkan dengan withGenericContainer (reqAPI) (ContactList), kami mengirimkan datanya sebagai argumen.

Karena withGenericContainer adalah sebuah fungsi, Anda bisa masuk sesedikit atau sebanyak mungkin argumen yang Anda inginkan. Pada contoh di atas, sebuah objek config digunakan untuk menentukan ketergantungan data komponen. Namun, kontrak antara enhanced component dan wrapped component benar-benar melalui props.

Jadi saya sarankan mengisi data static-time dependensi melalui function parameters dan melewati data dinamis sebagai props. props yang authenticated bersifat dinamis karena pengguna dapat dikenali atau tidak, tergantung pada apakah mereka masuk atau tidak, namun kami dapat yakin bahwa isi objek reqAPI tidak akan berubah secara dinamis.

Jangan Gunakan HOC Di dalam Render Method

Berikut adalah contoh yang harus sangat dihindari.

Terlepas dari kinerja, Anda akan kehilangan status OriginalComponent dan semua children di setiap render. Untuk mengatasi masalah ini, pindahkan HOC declaration di luar method render sehingga hanya dibuat satu kali, sehingga render selalu mengembalikan EnhancedComponent yang sama.

Jangan Mutate Wrapped Component

Mutating Wrapped Component di dalam sebuah HOC membuat tidak mungkin untuk menggunakan Wrapped Component di luar HOC. Jika HOC Anda return sebuah WrappedComponent, Anda hampir selalu dapat memastikan bahwa Anda melakukannya dengan salah. Contoh di bawah ini menunjukkan perbedaan antara mutation dan composition.

Composition merupakan salah satu ciri dasar React. Anda dapat memiliki wrapped component di dalam component lain dalam function render, dan itulah yang Anda sebut composition.

Selain itu, jika Anda mengubah tipe WrappedComponent di dalam HOC dan kemudian membungkus component yang disempurnakan menggunakan HOC lain, perubahan yang dilakukan oleh HOC pertama akan diganti. Untuk menghindari skenario seperti itu, Anda harus tetap menggunakan composing components daripada mengubahnya.

Namespace Generic Propnames

Pentingnya namespacing nama prop terbukti saat Anda memiliki banyak Stacked up. Component bisa mendorong nama prop ke dalam WrappedComponent yang sudah digunakan oleh higher-order component lainnya.

Baik withMouse dan withCat mencoba untuk mendorong versi prop nama mereka sendiri. Bagaimana jika Enhanced Component juga harus berbagi beberapa props dengan nama yang sama?

Bukankah itu menjadi sumber kebingungan dan penyesatan bagi end developer? The React Devtools tidak melaporkan konflik nama apapun, dan Anda harus melihat rincian implementasi HOC untuk memahami apa yang salah.

Hal ini dapat diatasi dengan membuat prop names HOC diinterpretasikan sebagai konvensi melalui HOC yang menyediakannya. Jadi Anda akan memiliki withCat_name dan withMouse_name, bukan generic prop name.

Hal lain yang menarik untuk dicatat di sini adalah bahwa ordering properti Anda penting dalam React. Bila Anda memiliki properti yang sama beberapa kali, menghasilkan konflik nama, deklarasi terakhir akan selalu bertahan. Pada contoh di atas, Cat menang karena ditempatkan setelah {...this.props}.

Jika Anda lebih memilih untuk menyelesaikan conflict name dengan cara lain, Anda dapat menyusun ulang properti dan menyebarkan this.props terakhir. Dengan cara ini, Anda dapat mengatur default yang sesuai dengan proyek Anda.

Buat Debugging Lebih Mudah Menggunakan Nama Tampilan yang Berarti

Components yang diciptakan oleh HOC muncul di React Devtools sebagai normal components. Sulit membedakan keduanya. Anda dapat mempermudah debugging dengan menyediakan displayName yang berarti untuk higher-order component. Tidakkah masuk akal untuk memiliki sesuatu seperti ini pada React Devtools?

Jadi apa itu displayName? Setiap component memiliki properti displayName yang dapat Anda gunakan untuk tujuan debugging. Teknik yang paling populer adalah membungkus nama tampilan dari WrappedComponent. Jika withCat adalah HOC, dan NameComponent adalah WrappedComponent, maka displayName akan disertakanwithCat(NameComponent).

Alternatif untuk Higher-Order Components

Meskipun Mixins hilang, akan menyesatkan untuk mengatakan higher-order components adalah satu-satunya pola di luar sana yang memungkinkan pembagian kode dan abstraksi. Pola alternatif lain telah muncul, dan saya pernah mendengar ada yang mengatakan bahwa ini lebih baik dari pada HOC. 1

Render props disebut oleh sejumlah nama yang berbeda:

  • render prop
  • children prop
  • function sebagai child
  • render callback

Berikut adalah contoh singkat yang harus menjelaskan bagaimana sebuah render prop bekerja.

Seperti yang Anda lihat, kita menyingkirkan higher-order functions. Kami memiliki component biasa yang disebut Mouse. Alih-alih membuat wrapped component dalam render method, kita akan membuat this.props.children() dan lewat dalam keadaan sebagai argument. Jadi, kita memberi Mouse sebuah prop, dan render prop menentukan apa yang harus diberikan.

Dengan kata lain, components Mouse menerima function sebagai nilai untuk children props. Saat Mouse merender, ia mengembalikan keadaan Mouse, dan function render prop bisa menggunakannya sesuai keinginan.

Ada beberapa hal yang saya sukai dari pola ini:

  • Dari perspektif keterbacaan, ini lebih jelas dari mana asal usulnya.
  • Pola ini dinamis dan fleksibel. HOC disusun pada static-time. Meskipun saya tidak pernah menemukan bahwa menjadi batasan, membuat props disusun secara dinamis dan lebih fleksibel.
  • Komposisi component yang disederhanakan. Anda bisa mengucapkan selamat tinggal pada beberapa nesting HOC.

Kesimpulan

Higher-order components adalah pola yang dapat Anda gunakan untuk membangun component reusable yang kuat dalam React. Jika Anda akan menggunakan HOCs, ada beberapa peraturan dasar yang harus Anda ikuti. Ini agar Anda tidak menyesali keputusan menggunakannya nanti. Saya telah meringkas sebagian besar praktik terbaik dalam tutorial ini.

HOC bukan satu-satunya pola yang populer saat ini. Menjelang akhir tutorial, saya telah mengenalkan Anda pada pola lain yang disebut props yang menghasilkan ground di antara para developers React.

Saya tidak akan menilai sebuah pola dan mengatakan bahwa yang ini lebih baik dari yang lain. Seiring bertambahnya pertumbuhan, dan ekosistem yang mengelilinginya akan matang, semakin banyak pola yang akan muncul. Menurut pendapat saya, Anda harus mempelajarinya semua dan bertahan dengan gaya yang sesuai dengan gaya Anda dan kenyamanan Anda.

Ini juga menandai akhir dari seri tutorial pada higher-order components. Kami telah pergi dari ground zero untuk menguasai teknik lanjutan yang disebut HOC. Jika saya melewatkan sesuatu atau jika Anda memiliki saran/pemikiran, saya akan senang mendengarnya. Anda bisa mempostingnya di komentar.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.