BerandaComputers and TechnologyRedux pasti TIDAK mati (transkrip)

Redux pasti TIDAK mati (transkrip)

Menampilkan

Sponsor

Rollbar Kami bergerak cepat dan memperbaiki berbagai hal karena Rollbar. Atasi kesalahan dalam hitungan menit. Terapkan dengan percaya diri. Pelajari lebih lanjut di rollbar .com / changelog .

Raygun – Dengan Raygun Error dan Performance Monitoring Anda memiliki semua informasi yang Anda butuhkan di ujung jari Anda untuk dengan cepat menemukan dan memperbaiki kesalahan dan masalah kinerja di seluruh tumpukan teknologi Anda hingga ke baris kode. Mulailah dengan uji coba 14 hari gratis, buka raygun.com dan bergabunglah dengan ribuan tim perangkat lunak yang berpusat pada pelanggan yang menggunakan Raygun setiap hari.

AWS Amplify – AWS Amplify adalah seperangkat alat dan layanan yang memungkinkan pengembang untuk membangun aplikasi web dan seluler tanpa server dan berbasis cloud menggunakan kerangka kerja mereka dan teknologi pilihan. Amplify memberi Anda akses mudah ke hosting, otentikasi, GraphQL terkelola, fungsi tanpa server, API, pembelajaran mesin, chatbots, dan penyimpanan untuk file seperti gambar, video, dan pdf. Pelajari lebih lanjut dan mulai gratis di awsamplify.info/JSParty

Catatan & Tautan

Edit di GitHub

Salinan

Edit aktif GitHub

Tebak, jam berapa sekarang teman? Ini adalah waktu Pesta JS sekali lagi! Nama saya Jerod Santo, saya teman internet Anda, dan saya bergabung dengan teman internet saya, Amal Hussein. Ada apa, Amal?

Dan kami memiliki yang sangat spesial Tamu, di sini untuk berbicara tentang Redux, Redux Toolkit, dan saya mendengar rumor kematian Redux sangat dibesar-besarkan… Kami bergabung dengan pengelola Redux, Mark Erikson. Mark, terima kasih telah bergabung dengan kami.

Hai! Saya sangat senang berada di sini.

Kami senang menerima Anda . Itu mengejutkan saya – Amal baru saja memberi tahu saya bahwa Redux telah ada selama lebih dari lima tahun sekarang. Ini gila bagi saya.

Maksud saya, itu seperti 30 di tahun anjing perpustakaan internet…

Tentu saja, dan itu masih hidup dan menendang… Dan Anda sekarang mempertahankan ini. Dapatkah Anda memperkenalkan diri Anda sejauh bagaimana Anda bisa hadir di JS Party hari ini dalam kaitannya dengan sejarah Redux? Bagaimana Anda bisa terlibat dengan proyek dan menjadi pengelola perpustakaan yang sangat populer ini?

Tentu. Jadi Redux, seperti yang diketahui kebanyakan orang, awalnya dibuat oleh Dan Abramov dan Andrew Clark pada musim panas 2015. Saya sebenarnya baru saja mulai mempelajari React sendiri pada saat yang sama… Dan saya membaca postingan blog dan berkumpul di chat saluran dan saya telah melihat beberapa pustaka serupa Flux lainnya sedang dibahas pada saat itu, dan hal Redux ini terus bermunculan. Saya mulai membacanya sedikit; orang lain mengajukan pertanyaan tentang hal itu… Dan saya terus melihat pertanyaan yang sama bermunculan di mana-mana, seperti Stack Overflow, dan Reddit, dan saluran obrolan Reactiflux dan yang lainnya… Dan saya pikir sekitar Januari 2016 saya sebenarnya setengah menjadi sukarelawan untuk menulis halaman FAQ untuk Redux berdasarkan semua hal yang telah saya lihat diminta … Dan saya melakukannya, dan Danny Abramov memberi saya hak komitmen atas repo setelah itu.

Saya menghabiskan beberapa bulan berikutnya hanya membantu masalah triase, dan mengubah dokumennya… Dan sekitar waktu itu, Dan dipekerjakan untuk bekerja di tim React di Facebook, dan dia mengirim pesan kepada diri saya sendiri dan pria lain bernama Tim Door, dan pada dasarnya berkata, “Hai, selamat! Anda adalah pengelola sekarang. Ini kuncinya. Selamat bersenang-senang!” Sebenarnya saya butuh sedikit waktu untuk benar-benar merasa seperti saya benar-benar memiliki izin untuk memiliki pendapat tentang seperti apa kode itu sendiri, tetapi itu menjadi hal yang saya sukai setelah itu.

[00:04:13.14] Ya. Dan Mark sebenarnya, sekali lagi, menjadi sangat rendah hati… Karena selain – hanya memiliki banyak kepemimpinan yang sangat hebat atas proyek yang sangat penting ini untuk ekosistem kita… Karena Redux, meskipun mungkin dipopulerkan melalui komunitas React, karena menurut saya itu adalah implementasi paling populer dari arsitektur Flux, ia benar-benar berkembang pesat dan agak cepat diadopsi dengan banyak komunitas lain… Dan menurut saya apa yang benar-benar telah dilakukan Mark dengan sangat baik adalah menurut saya berlatih, menurut saya, sebuah perlawanan … Dan Anda mungkin bertanya-tanya “Apa itu perlawanan?” Nah, dia mempraktikkan perlawanan karena dia menahan keinginan untuk mengubah Redux. Jejaknya kecil, dan API-nya benar-benar konsisten selama bertahun-tahun. Tentu saja, hal yang luar biasa tentang Redux adalah ia memiliki arsitektur yang dapat dipasang dengan indah ini, jadi ada ekosistem yang sangat luas di dalam Redux yang sangat luar biasa. Maksud saya, berapa banyak paket yang seperti plugin Redux, Markus? Seperti ratusan, bukan?

Ya… Untuk sementara, Saya menyimpan katalog yang berjalan pada dasarnya setiap perpustakaan dan add-on yang terkait dengan Redux yang dapat saya temukan, dan itu mencapai sekitar 2.000 paket yang berbeda sebelum saya hanya harus berhenti menambahkan ke daftar itu, karena saya perlu fokus tentang hal lain.

Ya. Jadi untuk mengatakan bahwa itu memiliki kaki yang bahkan mungkin – itu meremehkan. Tapi saya pikir salah satu hal yang benar-benar ingin saya luangkan waktu sejenak untuk meneriakkan Mark adalah kenyataan bahwa dia semacam ini (menurut saya) dukungan teknis untuk komunitas React secara luas; itulah cara terbaik untuk menjelaskannya. Reactiflux adalah komunitas yang luar biasa, yang akan kami tautkan di catatan acara … Ini adalah server Discord tempat Anda bisa – ada saluran berbeda di berbagai jenis kerangka kerja React populer, perpustakaan, atau hanya bidang keahlian … Dan Mark benar-benar sangat aktif di sana, menjawab pertanyaan… Dan dia sangat sabar, karena dia menjawab pertanyaan yang sama beberapa kali, lagi dan lagi dan lagi. Dia telah menjawab pertanyaan yang sama; saat komunitas ini tumbuh dan Anda memiliki semua pendatang baru yang memasuki komunitas, Mark hanya dengan sabar – dia bahkan tidak menghubungkan mereka ke jawaban lagi, dia hanya menjawab pertanyaan yang sama… Dan saya hanya ingin berterima kasih untuk itu, Mark, karena Anda adalah penjaga dan guru yang baik, dan Anda sangat sabar, dan kami sangat beruntung memiliki Anda, dan saya hanya ingin mengucapkan terima kasih atas semua yang Anda lakukan.

Saya akan dengan bebas mengakui bahwa saya memiliki sejumlah jawaban tertulis yang secara rutin saya salin-tempel sebagai tanggapan atas pertanyaan-pertanyaan ini…

Ini dia. Perluasan teks.

Baik. Sekarang kita tahu rahasianya. [laughs]

Tandai, apakah Anda merasa seperti apa yang Amal katakan benar? Saya tahu Anda ingin rendah hati, tetapi apakah Anda merasa telah menjadi dukungan teknis untuk komunitas React? Maksud saya, itu peran yang besar…

Dalam banyak hal, ya. Saya tidak sepenuhnya bercanda bahwa saya menjawab pertanyaan tentang React dan Redux secara harfiah di mana pun ada kotak komentar di internet… Dan itu adalah bagian yang sangat signifikan dari waktu luang saya saat ini. Saya suka menjawab pertanyaan hampir terlalu banyak. Ada saat-saat ketika saya melihat seseorang mengajukan pertanyaan yang saya tahu jawabannya, dan saya sebenarnya harus menahan diri untuk tidak meluangkan waktu untuk menjawabnya … Ini seperti, hanya karena ada pertanyaan tidak berarti Saya harus meluangkan waktu untuk menjawabnya sendiri secara pribadi sekarang.

Baik. Luar biasa… Sungguh menakjubkan Anda ingin melakukan itu, karena kebanyakan dari kita tidak dapat diganggu. Ini seperti “Ohh, pertanyaan lain… RTFM, Bung.” Anda tahu, itulah tanggapan yang khas. Tapi Anda seperti “Tidak, saya manualnya. Sini! Saya sudah membaca manual, izinkan saya memberi tahu Anda apa yang dikatakannya. Luar biasa. ”

[00:08:08.28] Saya sebenarnya baru saja melihat postingan blog yang sangat bagus kemarin…

Saya baru saja akan membicarakannya Itu. Saya me-retweet tweet itu; Itu tadi Menajubkan. Posting blog yang bagus.

Sebuah posting blog dari Ned Batchelder , yang sangat aktif dalam komunitas Python… Dan saya telah melihat banyak postingan bagus selama bertahun-tahun tentang cara mengajukan pertanyaan yang bagus. Stack Overflow memiliki panduannya… Anda tahu, minable, contoh runnable, dan semua hal semacam itu. Tapi ini sebenarnya adalah postingan yang mencoba memberikan panduan tentang cara terbaik menjawab pertanyaan online. Seperti, coba dan bersikap positif dalam cara Anda merespons, fokuslah pada pertanyaan mereka alih-alih mengecam tentang pemformatan atau hal-hal lain. Banyak nasihat yang sangat bagus dalam posting itu.

Ya, saya sudah membaca yang itu juga. Saya pikir itu spektakuler. Kami pasti akan menautkannya. Sangat cepat, Mark, hanya dalam semangat inklusi dan aksesibilitas – kami tahu Redux telah ada sejak lama, dan karena Anda menjawab semua pertanyaan tentangnya, mungkin ada orang yang mendengarkan yang baru saja membuka JavaScript, atau mereka Saya hanya ingin tahu tentang JS, dan mungkin mereka tidak tahu apa itu Redux. Jadi, dapatkah Anda melakukan Redux 101 untuk kami, dan seperti meletakkan dasarnya, sehingga kami dapat membangun percakapan di sekitarnya?

Tentu. Jadi Facebook mengumumkan React secara publik pada tahun 2013, dan pada saat itu terdapat banyak pendekatan yang sangat berorientasi objek untuk mengelola data dalam aplikasi web, seperti Backbone. Dan di 2014, Facebook mengumumkan pola yang mereka buat secara internal, yang mereka sebut arsitektur Flux. Idenya adalah untuk menyederhanakan pola aliran data dalam aplikasi dengan cara memusatkan di mana, kapan dan bagaimana negara Anda benar-benar dapat diperbarui; daripada memiliki sekumpulan model objek yang dapat memicu peristiwa di semua tempat, aplikasi lainnya memanggil objek pusat yang disebut dispatcher dan meneruskan objek yang menjelaskan beberapa peristiwa yang terjadi di aplikasi, dan objek itu disebut tindakan.

Jadi selama tahun depan, lusinan pustaka Flux yang berbeda muncul di ekosistem, bereksperimen dengan pola ini dengan cara yang berbeda. Pada pertengahan 2015 Dan Abramov, yang mendapatkan sedikit ketenaran di ekosistem React untuk beberapa hal lain yang dia kerjakan, mulai membuat perpustakaan terkait Flux miliknya yang disebut Redux untuk konferensi. Dan perpustakaan itu dengan sangat cepat berkembang pesat, jauh lebih banyak dari yang pernah dia pikirkan, dan pada dasarnya itu membunuh semua perpustakaan Flux lainnya. Saya menyebutnya sebagai semacam memenangkan perang Flux… Dan pada dasarnya sekarang ini adalah satu-satunya implementasi yang paling banyak digunakan dari arsitektur Flux.

Jadi idenya adalah Anda tulis semua kode pembaruan status Anda dalam fungsi yang disebut reduksi, yang akan mendapatkan status yang ada, dan beberapa objek tindakan yang mendeskripsikan sesuatu yang terjadi, seperti “Pengguna mengklik tombol” atau “Mengambil beberapa data dari server”, dan peredam kemudian memutuskan seperti apa negara bagian baru itu sebagai tanggapan. Jadi aplikasi lainnya tidak diizinkan untuk hanya mengubah status yang ada, melainkan harus mengatakan “Inilah yang terjadi”, dan memanggil store.dispatch, di mana penyimpanan berisi satu set data global yang semua aplikasi dapat merujuk ke.

Jadi ada tingkat yang disengaja tipuan di sini, dibandingkan dengan hanya mengatakan myobject.value=123 … Tetapi ada banyak manfaat dalam mencoba memusatkan beberapa pengelolaan ini, serta memisahkan proses yang terjadi di aplikasi dari “bagaimana status saya memperbarui” di aplikasi.

[00:11:58.13] Pergeseran semacam ini, membawa pub / sub dan aliran data satu arah ke aplikasi frontend hanya mengubah permainan… Sebelumnya, manajemen peristiwa dan status di dalam aplikasi frontend hanyalah mimpi buruk; Rube Goldberg ini, tidak ada organisasi nyata, tidak ada arah, tidak ada apa-apa. Itu salah satu alasan saya pribadi berpikir pengikatan dua arah di Angular juga dipopulerkan … Karena saya pikir itu hanya menghilangkan beberapa sakit kepala seputar acara dan manajemen negara, di mana itu seperti “Cukup tautkan ke hal itu”, Anda tahu ? Waktu sebenarnya.

Jadi Redux ada dan dulu benar-benar luar biasa dalam semua manfaat yang dibawanya… Tapi ada juga poin kerugian seputar adopsi. Apakah Anda keberatan mungkin berbicara dengan beberapa dari itu? Karena saya pikir itu adalah contoh yang sangat bagus mengapa Redux Toolkit dibuat – untuk mengatasi beberapa masalah yang timbul saat menggunakan Redux.

Tentu. Jadi sejak awal, Redux telah dikenal karena mengharuskan Anda untuk menulis cukup banyak kode boilerplate, dalam beberapa bentuk. Dan Abramov men-tweet kembali pada tahun 2015 yang menyatakan bahwa Flux dan Redux tidak pernah dimaksudkan sebagai cara terpendek untuk menulis kode. Mereka dimaksudkan untuk membuatnya sangat lugas dan jelas untuk memahami kapan, di mana, mengapa, dan bagaimana keadaan Anda berubah di seluruh aplikasi.

Jika Anda melihat Redux docs, ada halaman yang disebut “Mengurangi boilerplate”, dan halaman itu telah ada di sana sejak – jika Anda memeriksa sejarahnya – akhir 2015, tepat setelah Dan menulis dokumen asli. Dan itu menunjukkan beberapa pola untuk beberapa abstraksi kecil yang dapat Anda buat sendiri untuk kasus penggunaan umum.

Dan karena Redux mendapat banyak hal lebih populer dan banyak orang yang mengadopsinya, baik sengaja atau karena orang lain menyuruh mereka, bahwa kalimat “Redux membutuhkan banyak boilerplate” telah menjadi tema yang sangat konstan. Dan kami menyebutkan jumlah paket yang dibuat oleh komunitas, dan banyak dari mereka mencoba untuk memecahkan jenis masalah yang sama, tetapi semua orang hanya membuat versi kecil mereka sendiri dari berbagai utilitas … Dan Anda terus melihat pola yang sama berulang-ulang.

Ada beberapa poin rasa sakit lainnya … Redux dibuat agar dapat diperluas, tetapi karena itu, pustaka inti hampir tidak menyertakan apa pun yang ada di dalamnya; bahkan pendekatan paling umum untuk menulis logika asinkron dipecah menjadi paket terpisah yang disebut Redux Thunk. Dan itu hanya seperti 12 baris kode, tetapi idenya adalah “Kami tidak akan memaksa Anda untuk menggunakan satu pendekatan ini, jika Anda ingin melakukan hal lain.” Dan banyak orang lain melakukannya.

Bersamaan dengan itu, prosesnya , karena ada semua cara berbeda untuk mengatur berbagai hal, kode yang harus Anda tulis untuk mengkonfigurasi dan menyiapkan penyimpanan Redux melibatkan sejumlah langkah. Dan memang, Anda hanya perlu melakukannya sekali per aplikasi, tapi terus terang, itu menjengkelkan untuk menulis itu setiap kali Anda memulai aplikasi baru.

Jadi ini semua sangat umum poin rasa sakit yang orang tunjuk sebagai alasan mengapa Redux sulit digunakan, atau mereka tidak menyukainya … Dan bahkan sejauh tahun 2017, saya telah mengajukan masalah diskusi yang menanyakan “Apa sajakah cara yang kami tawarkan untuk beberapa -dalam abstraksi, permudah pengguna Redux, lebih mudahkan mengajar Redux? ” Dan butuh beberapa saat untuk beberapa ide ini untuk meresap melalui sistem, tapi di mana kami akhirnya adalah bahwa di akhir ’18, awal ’19, kami mulai mengerjakan paket resmi yang awalnya kami namai Redux Starter Kit. Di dalamnya kami akan menambahkan beberapa utilitas resmi untuk kasus penggunaan yang paling umum ini, hal-hal seperti menyiapkan toko, menulis reduksi, pembuat tindakan, jenis tindakan … Dan mencoba menangani pembaruan yang tidak dapat diubah dengan cara yang lebih mudah untuk membaca dan menulis.

[00:16:09.29] Kami secara resmi mempublikasikannya sebagai 1.0 pada bulan Oktober lalu, dan pada waktu yang sama orang-orang juga menunjukkan kepada kami bahwa nama Starter Kit memiliki masalah tersendiri. Orang-orang berasumsi bahwa itu adalah boilerplate yang sudah dibuat sebelumnya yang seharusnya Anda klon, atau itu hanya bagus ketika Anda sedang menyiapkan sebuah proyek, atau itu hanya bagus untuk orang-orang yang masih pemula dan belum pernah menggunakan Redux sebelumnya. Dan tidak satupun dari itu benar. Jadi kami akhirnya mengganti namanya menjadi Redux Toolkit.

Saya pikir saya ada di dalamnya ngomong-ngomong… Saya berada di kamp “Ini seperti roda latihan. Saya tidak butuh ini. Saya seorang profesional. ” Saya berada di kamp itu, sebagai catatan… [laughter] Saya pikir saya hanya berasumsi bahwa itu untuk pemula, ya.

Ya. Dan tujuannya adalah agar ini bermanfaat bagi kedua orang yang memulai dengan Redux, tetapi juga ahli yang telah menulis banyak kode Redux. Jadi kami secara resmi menamakannya ke Redux Toolkit dan beralih ke nama paket yang berbeda di reduxj / toolkit di Npm. Dan itu bekerja dengan sangat baik.

Kami sekarang secara resmi merekomendasikannya sebagai cara untuk menulis kode Redux. Anda masih dapat menulis kode dengan tangan jika Anda mau, tetapi intinya adalah Anda tidak perlu melakukannya, dan kami tidak lagi mengajarkan bahwa Anda harus melakukannya. Dan jika Anda melihat tingkat unduhan, itu hanya pertumbuhan yang sangat stabil pada garis lurus yang bagus, miring ke atas. Saya pikir itu sebenarnya baru saja memecahkan 50.000 unduhan per hari secara konsisten … Ini masih jauh dari unduhan sebenarnya dari paket inti Redux, tetapi penerapannya sangat solid, dan umpan balik dari komunitas memberi tahu saya bahwa – Anda tahu, saya dulu membenci Redux, dan Redux Toolkit membuat saya menyukainya lagi.

Saya baru saja memigrasi kode kami dari Redux biasa ke Redux Toolkit, dan saya memotong jumlah baris kode menjadi dua, dan seterusnya… Jadi, tanggapan positif yang sangat, sangat antusias, memberi tahu saya bahwa kita sedang menuju ke arah yang benar.

Kedengarannya bagus. Kami akan mendalami Redux Toolkit setelah jeda. Tapi sebelum itu, saya ingin melempar Anda sedikit ke sini…

Anda adalah pengelola ini hal-hal, sehingga Anda dapat menjadi proyek dan Anda berkata “Mari kita tingkatkan apa yang saat ini ada.” Dan menulis perpustakaan sedemikian rupa sehingga itu modular, dan benar-benar tidak beropini, karena dapat digunakan dengan semua cara yang berbeda ini…

… dan yang menyebabkan hal ini tantangan yang Anda coba perbaiki. Jika Anda akan kembali dan menulisnya sendiri, menurut Anda apakah dia membuat pilihan yang tepat yang dia buat? Atau apakah Anda akan memiliki lebih banyak roda pelatihan bawaan, atau lebih banyak pendapat? Atau apakah menurut Anda modularitas dan keumumannya membuatnya berhasil?

Saya pikir mengingat kendala dan tujuan desain pada saat itu, di musim panas 2015, Dan dan Andrew membuat beberapa pilihan desain yang luar biasa bagus dalam rentang dua bulan, yang berhasil dengan sangat baik. Sekarang, mengingat apa yang sekarang kita ketahui dan bagaimana kita melihatnya – Redux Toolkit tidak dapat dibuat jika kita belum melihat ribuan paket lain yang dibuat orang, pola yang digunakan orang, masalah yang mereka coba selesaikan, titik sakit yang mereka hadapi, dan terutama jika paket tertentu yang disebut Immer belum dibuat. Penjelasan singkat tentang itu…

Redux mengharuskan Anda menulis file memperbarui secara permanen, yang berarti Anda harus selalu membuat salinan objek dan memperbarui salinannya, bukan modif ying aslinya. Dan menulis kode pembaruan yang tidak dapat diubah dalam JavaScript sangat merepotkan, karena Anda akhirnya harus melakukan banyak operator penyebaran objek bersarang, dan menggabungkan serta memetakan larik Anda… Ini sangat panjang, dan sangat bertele-tele, sulit dibaca, dan sangat mudah untuk membuat kesalahan. Dan kesalahan nomor satu yang saya lihat orang-orang lakukan dengan Redux adalah secara tidak sengaja mengubah status mereka, baik di dalam atau di luar fungsi peredam.

[00:20:20.22] Sementara itu, Michel Westrate, pembuat pustaka MobX, membuat paket terpisah yang disebut Immer, yang menggunakan proxy JavaScript untuk menggabungkan beberapa data … Dan Anda menyediakan fungsi panggilan balik yang menerima objek draf yang terlihat seperti data asli Anda, tetapi itu sebenarnya telah dibungkus dalam proxy. Dan Anda sebenarnya dapat menulis kode mutasi, seperti state.value=123, di dalam callback. Immer melacak perubahan yang dicoba dan secara internal mengubahnya menjadi pembaruan yang aman dan tidak dapat diubah, sehingga hasil yang dikembalikan dari fungsi ini adalah objek baru yang diperbarui secara permanen, seolah-olah Anda telah menulis semua kode operator penyebaran itu sendiri.

Jadi Redux Toolkit dibangun menggunakan Immer dari prototipe pertama yang saya tulis. Dan meskipun kami dapat menulis beberapa utilitas lain dengan baik lebih awal, menggunakan Immer adalah inti dari cara kerja Redux Toolkit, dan salah satu cara utama yang membuatnya lebih mudah untuk menulis logika Redux Anda.

Untuk kembali dan menjawab pertanyaan, mungkin ada beberapa hal yang Dan dan Andrew dapat lakukan secara berbeda, seperti, katakanlah, setidaknya menyertakan paket Thunk di luar kotak, jadi Anda tidak perlu menginstal perpustakaan terpisah… Tapi mengingat apa yang mereka tuju untuk dan kendala pada saat itu, sejujurnya itu adalah desain yang brilian.

Mark, itu benar-benar a cerita latar belakang yang luar biasa menjadi alasan di balik pembuatan Toolkit… Kembali ke masalah Redux… Saya pikir dengan mencoba melayani komunitas JavaScript, Anda selalu berusaha untuk melayani basis seluas mungkin, karena JavaScript ada di mana-mana. Semua orang selalu menulis JavaScript. Pengembang Java sedang menulis JavaScript, pengembang Python menulis JavaScript… Atau mungkin saya harus mengatakan pengembang Java mencoba menulis JavaScript… [laughs]

Maaf… [laughter] Saya hanya mengatakan, kadang-kadang aksesibilitas JavaScript bisa menimbulkan masalah foot-gunning, Anda tahu?

Tapi bagaimanapun – jadi itu menarik kepada banyak orang, tapi jelas ada hal-hal tertentu di sekitar boilerplate, misalnya, itu adalah masalah … Tapi sejujurnya, itu adalah bagian dari desain, dalam arti bahwa dari pemahaman saya Dan Abramov benar-benar mencoba untuk mencapai sesuatu yang sangat greppable … Jadi untuk jenis koin istilah “faktor grep” – faktor grep Redux tinggi, karena Anda memiliki pencipta tindakan konstan ini, dan Anda hanya grep untuk itu, dan Anda dapat melihat di mana-mana itu digunakan. Anda dapat dengan mudah grep kode Anda dan hanya melihat di mana satu tindakan ini – bagaimana itu dilacak di seluruh kode sumber Anda … Dan bagi saya, itu sangat besar, terutama dalam hal keterbacaan, pemeliharaan … Dan saya selalu salah di sisi menjadi sedikit lebih bertele-tele untuk kode yang seharusnya dipertahankan oleh banyak orang selama bertahun-tahun … Jadi saya lebih suka memiliki kode yang lebih mudah dibaca daripada kode pendek yang diabstraksi.

[00:24:37.17] Jadi pertanyaan saya adalah – dengan Redux Toolkit Anda telah membuat abstraksi ini, tetapi apa yang hilang dari kami untuk pengguna yang mahir, atau untuk orang yang menginginkan lebih dari faktor grep itu? Dan terlebih lagi, dari membaca dokumen, kami memiliki abstraksi, tetapi kami juga memiliki kekuatan lebih. Hal-hal seperti Immer – mereka membawa lebih banyak ke meja langsung dari gerbang daripada sebelumnya. Jadi, bisakah Anda berbicara tentang dikotomi memberi orang jetpack, tetapi juga memberi mereka pagar pengaman?

Tentu. Jadi inti Redux, secara harfiah pustaka dan fungsinya sendiri sangat minim sehingga Anda dapat menggunakannya dengan banyak cara berbeda. Ini kemudian menjadi kekuatan dan kelemahan… Dan saya sebenarnya menulis dua posting blog yang sangat panjang yang berbicara tentang maksud di balik desain Redux, apa yang perpustakaan benar-benar minta Anda lakukan dalam hal bagaimana Anda menulis kode Anda, tapi mengapa banyak pola penggunaan umum sebenarnya ada. Saya menjuluki posting ini sebagai “Tao Redux. Bagian I: Implementasi dan Maksud “dan” Bagian II: Praktek dan Filsafat “.

Mari kita lihat salah satu file contoh umum. Salah satu keluhan paling umum tentang boilerplate adalah “Saya harus menulis jenis tindakan saya dan kode peredam saya di fungsi pembuat tindakan saya, dalam file terpisah, dan saya harus menulis jenis tindakan saya sebagai variabel konst, di mana kedua nama variabel dan teks string semuanya menggunakan huruf besar, atau huruf besar untuk perawatan ular. ” Perpustakaan Redux sebenarnya tidak membutuhkan semua itu. Itu tidak peduli dengan struktur folder Anda, tidak peduli apakah Anda telah mendefinisikan jenis tindakan Anda sebagai variabel const atau menulisnya sebaris, tidak peduli apakah itu huruf besar, huruf kecil, tanda hubung, terserah… Tapi ini semua adalah konvensi umum yang ada dan ditunjukkan di dokumen karena suatu alasan.

Sebagai pengembang, kami sering menempatkan kode jenis yang berbeda ke dalam file yang berbeda atau area berbeda dari basis kode. Jadi mari kita pisahkan fungsi pembuat tindakan kita – yang tidak diperlukan, tetapi merupakan pola yang umum – dari fungsi peredam kita, yang pasti diperlukan. Oke, keduanya perlu merujuk ke string jenis tindakan yang sama… Kami tidak ingin menyalin-tempel string di banyak tempat, karena mungkin Anda salah ketik, atau semacamnya. Jadi Anda ingin mendefinisikannya di satu tempat…

Atau mungkin Anda ingin menggunakannya kembali …

Ya, ya. Jadi, mari kita definisikan itu sebagai variabel, dan jika variabel dibutuhkan oleh dua file lain dan itu perlu ada di file sendiri… Ada alur pemikiran yang sangat logis tentang mengapa pola ini ada. Namun pada saat yang sama, pola default yang selalu ditampilkan di dokumen cenderung mengarah ke beberapa contoh yang sangat bertele-tele. Dan saya pernah melihat Dan berkata bahwa dia tidak selalu berpikir orang akan benar-benar menulis kode seperti yang ditunjukkan di dokumen … Dan sebanyak saya mencintai Dan, saya pikir itu mungkin pendapat yang sedikit naif … Karena tentu saja orang akan melakukan apa yang Anda tunjukkan di dokumen.

Tetapi orang-orang juga menyukai Dan. Mari kita menjadi nyata.

Jika Dan menerbitkan makanannya dan jadwal musik dan pakaian atau apa pun, saya pikir orang-orang akan melakukannya. Mereka hanya ingin “npm-install dan abramov”. Saya pikir dia memiliki klub penggemar yang sangat serius.

[00:28:07.04] Menurutmu dia punya jadwal pakaian, Amal? [laughs]

Ya, seperti “Saya pakai ini pada hari Senin… ”Atau merek yang dia kenakan…

Saya hanya berpikir, “Oh , ini 8:30 PAGI. Sebaiknya saya pakai celana saya. ”

Ada yang berikut ini. Itu juga. Jujur saja; hari-hari ini seperti “Senin, Selasa, setiap hari …” Setiap hari adalah hari tanpa celana hari ini … [laughs]

Ngomong-ngomong, sebenarnya – Saya tidak tahu tentang Anda, tetapi Anda mengatakan bahwa Anda memasukkan kode Anda ke file yang berbeda… Saya tidak melakukan itu. [laughter]

Saya baru saja memasukkan semuanya satu file bernama bundle.js. [laughter]

Saya seorang minimalis. Semua kode saya masuk dalam satu file… Di beberapa proyek.

Bahkan bahasa yang berbeda. Itu semua adalah satu file.

Ya. Anda hanya menggunakan namespace dan IIFE, Anda tahu? [laughter] Bagaimanapun…

Masalahnya adalah, dokumennya menunjukkan pola pengorganisasian berbagai jenis kode Anda ke dalam file yang berbeda, dan kemudian mengatur file tersebut ke dalam folder menurut jenis. Jadi Anda memiliki folder reduksi, folder tindakan, folder konstanta, dll.

Seorang pria bernama Erik Rasmussen sebenarnya muncul dengan pola untuk meletakkan semua logika untuk fitur tertentu ke dalam satu file, yang dia beri nama pola Bebek. Sebagian kecil komunitas Redux mengadopsinya, tetapi kami tidak menyarankannya secara resmi. Dan saya selalu memiliki beberapa kekhawatiran tentang hal itu, terutama tentang bagaimana hal itu menunjukkan bahwa hanya satu peredam yang tidak pernah dapat menangani tindakan dari jenis tertentu, padahal maksudnya adalah peredam dapat menanggapi tindakan apa pun.

Jadi mengingat ini spesifik poin-poin penting yang dibicarakan orang, bagaimana Redux Toolkit mencoba mengatasinya? Dokumen mengatakan bahwa saya membuat Redux Toolkit benar-benar untuk menyelesaikan tiga masalah berbeda. Terlalu sulit untuk mendirikan toko, Anda harus menambahkan banyak paket tambahan untuk melakukan sesuatu yang berguna, seperti Redux Thunks, dan Pilih Ulang dan yang lainnya… Dan itu membutuhkan terlalu banyak kode boilerplate.

Item satu, Redux Toolkit punya fungsi yang disebut configureStore, itu adalah panggilan satu baris. Anda menyediakan fungsi peredam yang telah Anda buat sendiri, atau peredam irisan untuk berbagai fitur, dan itu akan menyusunnya sendiri. Ini secara otomatis mengatur pengaturan ekstensi browser Redux DevTools yang diperlukan, dan secara otomatis menambahkan middleware Redux Thunk, dan dalam mode pengembangan beberapa middleware cek dev yang akan menimbulkan kesalahan jika Anda melakukan hal-hal seperti secara tidak sengaja mengubah status apa pun di toko … Jadi melindungi dari kesalahan paling umum yang dilakukan orang saat menggunakan Redux.

Dari sana, ada pasangan utilitas seperti `createAction`, yang menghasilkan pembuat tindakan berdasarkan string jenis tertentu … Dan` createReducer`, yang memungkinkan Anda untuk mendefinisikan reduksi menggunakan sintaks tabel pencarian objek daripada pernyataan switch, karena untuk beberapa alasan banyak orang benar-benar membenci pernyataan sakelar.

Dan `createReducer` juga menggunakan perpustakaan Immer ini di dalam untuk memungkinkan Anda menulis apa yang tampak seperti sintaks mutasi di reduksi Anda, tetapi sebenarnya berubah menjadi pembaruan internal yang aman, benar, dan tidak dapat diubah. Jadi dari sana, kami memiliki API yang disebut createSlice, dan kami secara tradisional menggunakan kata “slice” untuk merujuk pada peredam untuk satu bagian dari status Redux Anda. Misalnya, jika saya memiliki aplikasi blog dengan state.users, state.posts, dan state.comments, peredam pengguna dan tindakan pengguna mewakili sebagian negara Anda.

[00:31:55.03] Jadi createSlice dibangun di atas createAction dan createReducer. Anda memberinya satu set fungsi peredam dalam suatu objek, dan Anda memberinya nama yang bermakna. Memberikan contoh aplikasi agenda klasik, [unintelligible 00:32:09.23] hal-hal seperti itu … Dan secara otomatis menghasilkan pembuat tindakan dan jenis tindakan secara internal, berdasarkan nama fungsi peredam yang Anda berikan . Dan ini sebenarnya berhubungan dengan faktor grepabilitas yang Anda tanyakan sebelumnya.

Salah satu keuntungan memiliki semua jenis tindakan tersebut sebagai variabel const dalam basis kode adalah Anda dapat melihat Redux DevTools dan melihat jenis tindakan “Oke, saya mengirimkan Add_todo”, dan sekarang saya dapat Ctrl + Shift + F, mencari seluruh basis kode secara tekstual untuk penggunaan jenis tindakan itu.

Nah, kami sebenarnya sekarang merekomendasikan agar orang menggunakan pola penamaan di mana stringnya berada di bawah camel cased, dan Anda mendefinisikannya sebagai domain-eventname. Misalnya, mungkin domainnya adalah todos / todoadded, daripada kasus ular teriak atas AddToDo.

Rasanya sangat mirip RPC. Ini seperti peralihan dari REST ke RPC. Ini sangat mirip dengan GraphQL. GraphQL memungkinkan Anda menyusun data yang Anda peroleh dari server dengan cara yang digerakkan oleh peristiwa, sebagai lawan dari yang digerakkan oleh sumber daya … Jadi, jenis ini terasa lebih sejalan dengan itu. Saya suka ide menggunakan domain dan kemudian tindakan sebagai satu hal untuk jenis tindakan Anda.

Ya. Saya telah melihat banyak aturan penamaan yang berbeda. Orang-orang NgRx sebenarnya menggunakan ruang domain tanda kurung siku, seperti kalimat sebenarnya yang menjelaskan berbagai hal.

Jadi dalam hal ini kami memilih konvensi baru, dan kami mendorongnya, dan Redux Toolkit menggunakan konvensi itu secara internal… Tapi createSlice menghasilkan string jenis tindakan itu berdasarkan nama string yang Anda berikan untuk slice, seperti “todos”, dan kemudian digabungkan dengan nama fungsi peredam yang Anda berikan, seperti “rencana ditambahkan”.

Jadi jika saya melihat file dev tools dan saya melihat jenis tindakan todos / todoadded, saya masih bisa grep untuk nama yang dimuat dan menemukan fungsi reducer yang tepat dalam basis kode yang menghasilkan jenis tindakan tersebut. Tapi hal yang menyenangkan adalah string tipe tindakan hampir sekarang merupakan detail implementasi. Anda tidak lagi harus menuliskannya di kode Anda, Anda tidak merujuk ke jenis tindakan di mana pun; itu hanya string yang muncul di alat pengembang saat Anda melihat riwayat tindakan.

Ya, itu cukup keren. Saya pikir sangat menarik bahwa Anda bahkan menyertakan API seperti adaptor – apa namanya?

`createEntityAdapter`, ya. Bisakah Anda ceritakan tentang itu? Apa itu, dan masalah apa yang memecahkannya?

Tentu. Jadi setelah menulis FAQ Redux pada musim semi 2016, saya mengikutinya dengan bagian resep yang disebut Pengurang Struktur, yang memberikan beberapa panduan tentang hal-hal seperti “Mengapa kita membagi logika peredam menjadi beberapa fungsi? Apa sajakah cara Anda dapat mengatur logika peredam itu? Dan salah satu pola yang saya lihat digunakan pada tahun pertama keberadaan Redux adalah gagasan menormalkan keadaan Anda, yang umumnya memiliki dua aspek. Salah satunya adalah Anda tidak ingin memiliki salinan data duplikat yang disimpan di toko.

[00:35:59.13] Jika kita kembali ke contoh blogging itu – jadi kita punya pengguna, posting dan komentar – setiap posting mungkin memiliki pengguna yang membuatnya. Dan jika kita mengambil data itu dari server, setiap objek posting mungkin memiliki salinan terpisah dari objek pengguna yang bersarang di dalamnya. Kami tidak ingin menyimpan 50 salinan objek pengguna dalam status Redux, kami hanya ingin memiliki satu salinan objek untuk setiap pengguna. Dan ada banyak kasus di mana kami ingin dapat menemukan pengguna tertentu, postingan tertentu, komentar tertentu berdasarkan ID mereka.

Jadi keadaan normalisasi umumnya menyiratkan hal itu Anda akan menyimpan sesuatu sebagai tabel pencarian, di mana kuncinya adalah ID, dan nilainya adalah item itu sendiri, bukan menyimpannya sebagai array. Jadi saya menulis halaman dokumen yang disebut “Normalisasi bentuk status” yang menjelaskan pola ini, dan secara khusus menyarankannya sebagai ide yang bagus.

Meskipun demikian, kami tidak pernah memasukkannya apa pun di pustaka Redux itu sendiri yang pernah membantu Anda dalam proses menormalkan status dengan cara apa pun. Ada pustaka yang sangat populer yang telah digunakan dengan Redux yang disebut Normalizer, yang menurut saya Dan memulai atau membantu memelihara untuk sementara waktu. Ada juga perpustakaan yang disebut Redux-ORM, yang menyediakan fasad seperti model kelas di atas data biasa di toko Redux Anda; dan saya menggunakannya di salah satu proyek saya. Tapi tidak ada yang dibangun ke dalam perpustakaan inti itu sendiri.

Jadi setelah kami membangun keluar dari API awal untuk Redux Toolkit, awal tahun ini saya mulai memikirkan tentang gagasan normalisasi sebagai ruang masalah, bahwa kami harus menyediakan sesuatu untuk membantu. Jadi saya melihat-lihat berbagai paket dan pustaka pihak ketiga yang dibuat orang lain yang membantu dengan itu, dan saya menemukan sesuatu yang telah dibuat oleh orang-orang toko NgRx. NgRx pada dasarnya adalah implementasi ulang Redux untuk ekosistem Angular, dibangun di sekitar paket RxJs. Dan karena itu, ada banyak hal yang tumpang tindih yang dilakukan oleh Redux dan NgRx.

Pengelola NgRx telah membuat file add-on disebut createEntityAdapter, yang pada dasarnya menyediakan sekumpulan fungsi peredam yang dibuat sebelumnya untuk hal-hal seperti menambahkan satu, menambahkan banyak, mengatur semua, menaikkan satu, menghapus semua, dll. Operasi tipe CRUD khas yang akan Anda lakukan pada sekumpulan data. Dan saya melihatnya, saya seperti “Anda tahu – paket ini hanya memiliki satu atau dua referensi ke NgRx sama sekali. Ini hampir agnostik perpustakaan. Adakah cara agar kami dapat membuat ini dapat digunakan kembali, jadi kami dapat mulai menggunakannya dengan Redux Toolkit? ” Dan mereka mulai melihatnya, dan saya mulai bermain-main dengannya sendiri, dan saya akhirnya benar-benar memindahkannya dan menulis ulang setengahnya. Saya menambahkan penggunaan Immer di dalam, argumen untuk fungsinya ada di pembaruan, urutan status, instate negara, pembaruan … Jadi saya mengubahnya, jadi kami benar-benar dapat menggunakannya sebagai fungsi peredam.

Jadi akhirnya, saya berakhir mem-portingnya, tetapi tidak ada yang akan ada jika orang-orang NgRx tidak membuatnya di tempat pertama… Dan sangat keren melihat penyerbukan silang ide bolak-balik, karena NgRx terinspirasi oleh Redux, createEntityAdapter kami , adalah port mereka … Jadi ini memungkinkan Anda untuk melewati keharusan menulis logika peredam dalam banyak kasus untuk jenis skenario pembaruan yang paling umum yang mungkin Anda hadapi saat berurusan dengan kumpulan beberapa item. Dan Anda dapat menggunakannya sebagai seluruh fungsi peredam untuk jenis tindakan tertentu, atau Anda dapat menggunakannya sebagai pembantu dalam fungsi peredam yang lebih besar sebagai bagian dari logika yang Anda tulis.

[00:40:11.07] Saya suka bagaimana Anda seperti uber-nerd tentang segala hal, Mark… Luar biasa. [laughs] Ada begitu banyak poin menarik di sana. Salah satunya adalah pemisahan yang sangat bagus tentang apa yang akan kita bahas selanjutnya, yang sebenarnya tidak hanya ekosistem, tetapi lebih spesifik lagi pengelolaan negara secara keseluruhan di dalam aplikasi frontend, dan perdebatan kuno tentang kapan harus menggunakan apa; negara bagian lokal versus negara aplikasi. Lalu ada manajemen data keseluruhan, dan pengambilan, dan klien Apollo. Ada begitu banyak hal baru dalam ekosistem, bahkan hanya React. React memiliki beberapa API baru yang menarik, seperti Reducer Hook… Hanya hal yang sangat keren. Kami akan membahasnya selanjutnya.

Sangat cepat, saya ingin mengatakan bahwa salah satu hal yang dikeluhkan banyak orang – jadi kami berbicara tentang tiga alasannya, “Oke, mengonfigurasi toko Redux terlalu rumit”, hal kedua adalah “Saya harus menambahkan banyak paket Redux untuk mendapatkannya Redux untuk melakukan sesuatu yang berguna ”, dan keluhan ketiga adalah“ Redux membutuhkan terlalu banyak kode boilerplate ”- Saya akan mengatakan semua hal itu berbicara ke hati saya yang aneh, dalam arti bahwa saya merasa sangat terserang ketika saya membacanya… Karena bagi saya , ini seperti – Saya suka arsitektur terbuka Redux. Fakta bahwa itu berdiri selama ini dan masih relevan – itu hanya menunjukkan itu arsitektur terbuka dan arsitektur bersih yang dimilikinya, yang menggunakan plugin dll. Itulah mengapa itu bertahan dalam ujian waktu.

Bagi saya, yang paling menyenangkan bagian dari menyiapkan proyek baru ketika saya menyiapkan toko Redux saya dan segalanya – itu menambahkan semua paket itu. Dan saya menyukai kenyataan bahwa saya tahu persis apa yang terjadi di Redux setiap kali saya mengkonfigurasi aplikasi saya; tergantung pada apa yang dibutuhkan, ini sedikit berbeda. Satu ukuran pasti tidak cocok untuk semua.

Saya mengerti bahwa orang memiliki – oke, ada dasar paket yang selalu diinginkan semua orang, jadi mari kita kirimkan Redux Toolkit dengannya … Tapi ada keindahan yang bagus untuk hanya membangun ekosistem Anda sendiri, sangat mirip dengan Minecraft atau sangat mirip Node.js, di mana Anda cukup mengimpor semua modul Anda, karena Anda menginginkannya dan Anda tahu persis apa yang masuk ke dalam lasagna Anda. Jadi faktor lasagna adalah salah satu yang membuat saya sedih karena kehilangan… Tapi Anda masih dapat menambahkan sesuatu dengan Redux Toolkit.

Ya. Itu tidak menghilangkan apa pun dalam hal kemampuan bagaimana Anda dapat mengonfigurasi toko Anda. Anda masih mengatakan “Ini peredam yang saya inginkan.” Ini menambahkan beberapa middleware secara default, tetapi Anda dapat memilih untuk memasukkan middleware tambahan atau hanya melepaskan default dan berkata “Ini yang saya inginkan.” Anda masih bisa menambahkan store enhancer dari berbagai jenis… Jadi itu semua yang bisa Anda lakukan dengan createStore, tapi sebenarnya API ini lebih mudah, karena createStore mengambil tiga argumen posisi: reducer, status awal, dan satu-satunya store enhancer … Yang berarti bahwa Anda bertanggung jawab untuk menggabungkan bersama, katakanlah, applyMiddleware dan DevTools enhancer ke dalam satu composeEnhancer sendiri, dan meneruskannya secara posisional… Sedangkan configureStore memiliki argumen opsi berbasis objek, dan Anda berkata “Ini reducernya, berikut adalah array dari middleware, berikut adalah serangkaian perangkat tambahan, berikut ini adalah opsi di muka untuk mengaktifkan DevTolls Yes or No ”, dan bahkan itu di sana membuatnya lebih mudah untuk melihat apa yang terjadi dengan cara Anda mengaturnya.

Ya, tentu saja. Baiklah, para hadirin sekalian, Redux – pasti belum mati. Kita akan mendengar lebih banyak tentang kapan harus menggunakan apa dan mengapa di segmen berikutnya.

Jadi dalam semangat pembuatan lasagna Anda sendiri, mungkin Anda mengikuti resep kami, tapi hal-hal itu Amal sedang berbicara tentang, di mana dia adalah seorang pecandu Redux dan dia ingin melakukannya dengan cara yang dia lakukan, dan dia suka memutar-mutar bit dan mengkonfigurasinya begitu… Apakah disarankan, Mark, untuk menggunakan Redux Toolkit dalam gaya resep referensi?

Apa yang dulu saya lakukan pada hari itu dengan HTML5 Boilerplate – Saya tidak yakin apakah kalian ingat proyek luar biasa dari Paul Irish dan teman-temannya – adalah saya tidak akan pernah benar-benar menggunakan kode boilerplate. Saya akan membuat kode boilerplate, dan kemudian saya akan melihatnya saat saya menulis milik saya sendiri, dan hanya memilih apa yang saya suka dan apa yang menurut saya bagus, dan saya hanya membuang sisanya. Dapatkah Anda menggunakan proyek ini dengan cara itu dan tidak benar-benar menginstalnya sendiri, tetapi hanya menggunakan Redux dan mungkin memilih dan memilih, dan menggunakannya sebagai praktik terbaik, sebagai panduan, tetapi bukan kodenya … Atau lebih baik hanya menggunakan kode dan pergi dari sana?

Jadi Redux Toolkit adalah satu set fungsi API yang berbeda. Masing-masing untuk tujuan yang berbeda – konfigurasikan penyimpanan, buat tindakan, peredam, potong, [unintelligible 00:46:35.27] Dan tentu saja kami menyarankan agar Anda menggunakan semuanya sebagai pendekatan default di aplikasi Redux Anda … Tapi semuanya “pilih dan pilih petualangan Anda sendiri”.

Tentu, ada banyak manfaat dari menggunakan configureStore untuk menyiapkan toko Anda, menangkap mutasi yang tidak disengaja, dll. dan saya pribadi akan mengatakan bahwa itu harus menjadi hal pertama yang harus Anda lakukan ketika menyiapkan proyek Redux baru atau mulai memigrasi yang sudah ada, tetapi tidak ada yang mengatakan kami punya untuk. Dan Anda benar-benar dapat memigrasikan aplikasi yang ada ke Redux Toolkit secara bertahap.

Katakanlah Anda punya file aplikasi Redux besar yang sudah ada, dan Anda ingin mulai menggunakan Redux Toolkit. Jadi, Anda menukar kode penyiapan toko Anda untuk configureStore sekali, Anda memilih peredam dan jenis tindakan terkait, Anda menggantinya dengan panggilan ke createSlice, Anda menukar menghubungkan fungsi peredam dan mengirimkan tindakan tersebut. Semua kode yang ada berfungsi dengan baik apa adanya. Dan kemudian Anda terus memigrasi satu peredam dan tindakan terkaitnya pada satu waktu.

Sebenarnya, Mark, itu membawa saya pada pertanyaan – apakah ada perbedaan di luar sana yang dapat dilihat oleh publik, seperti “Ini aplikasi sebenarnya yang menggunakan Redux, dan inilah [unintelligible 00:48:10.17] untuk menggunakan Redux Toolkit… ”

“… dan inilah semua baris kode negatif dihapus ”, atau apa pun. Saya hanya ingin tahu, apakah itu sesuatu yang tersedia di suatu tempat di interwebs?

Sebenarnya, ketika saya menulis satu set tutorial untuk dokumen ReduxToolkit.js.org, saya benar-benar melakukan itu dengan apa yang saya sebut Tutorial Menengah. Jadi dibutuhkan aplikasi to-do standar Redux ini dengan contoh React yang memiliki operator penyebaran objek Anda dan reduksi serta hal-hal lainnya, dan ini menunjukkan cara memigrasi secara bertahap untuk menggunakan Redux Toolkit. Memang, ini bukan aplikasi besar, jadi tidak akan ada perbedaan yang sangat besar… Tapi ini menunjukkan cara bermigrasi, dan sebenarnya saya mengaturnya dengan cara yang ada contoh repo, dan Saya benar-benar menautkan ke komitmen tertentu sepanjang tutorial, mendemonstrasikan proses langkah demi langkah migrasi.

Bagus. Itu luar biasa. Kami harus menautkannya di catatan acara. Kedengarannya bagus. Dan alasan mengapa saya menanyakannya adalah karena saya merasa seperti – saya suka tutorial yang sangat terperinci, dan membahas hal-hal selangkah demi selangkah, tetapi saya pikir ketika pengembang mempelajari sesuatu yang baru dari sesuatu yang lama, peta mental itu yang perlu mereka lakukan, jauh lebih baik untuk melihat perbedaan seperti proyek nyata… Seperti, “Begini cara kerjanya di sini, dan sekarang inilah perbedaannya.” Dan kemudian saya pikir itu jauh lebih mudah untuk mencerna informasi itu, jadi kita pasti harus menautkannya di catatan acara.

Satu pemikiran lain tentang topik itu – Dokumen Redux Toolkit saat ini ditulis (terutama tutorialnya) dengan asumsi bahwa Anda sudah mengetahui apa itu Redux dan cara menulis kode itu dengan tangan. Tapi saya sebenarnya sedang berusaha mengubah asumsi itu secara umum. Kami sekarang merekomendasikan agar orang menggunakan Redux Toolkit sebagai sintaks default untuk menulis kode Redux. Dan seiring dengan itu, banyak orang telah mencatat bahwa dokumentasi inti Redux – jika Anda melihat urutan tutorial yang ada, itu seperti “Ini aplikasi yang harus dilakukan. Ini dia aplikasi Reddit. Pergilah bersenang-senang. Bye! ” Dan sebenarnya tidak ada contoh dunia nyata yang bagus di dokumen itu sendiri.

Saya sebenarnya menghabiskan paruh pertama tahun ini mengerjakan urutan tutorial baru untuk dokumen Redux yang saya beri nama tutorial “The Redux Essentials”. Ini memiliki beberapa tujuan. Salah satunya adalah lebih difokuskan pada pendekatan top-down, “Ini cara yang tepat untuk menggunakannya” untuk mempelajari Redux, sedangkan urutan tutorial yang ada adalah dari bawah ke atas, “Begini cara kerjanya.”

Yang lain adalah bahwa itu memang mengajar Redux Toolkit dan React Redux Hooks API sebagai default, cara standar untuk menulis kode Redux. Aplikasi demo yang dibuatnya adalah aplikasi jenis media sosial kecil yang mendemonstrasikan beberapa perilaku tipe CRUD… Dan juga memiliki cukup banyak penjelasan untuk “Mengapa Redux ada? Kapan masuk akal untuk menggunakannya? ” Tujuannya adalah agar seseorang dapat membacanya dan mulai membuat aplikasi yang bermakna menggunakan Redux Toolkit, tanpa harus mengetahui semua detail dari apa yang sebenarnya terjadi di balik layar.

Sekarang, Redux Toolkit pasti melakukannya berfungsi paling baik jika Anda memahami cara menulis kode itu dengan tangan, sehingga Anda tahu apa yang dilakukan abstraksi itu untuk Anda. Tetapi tujuan saya adalah Anda harus dapat menggunakannya tanpa harus mengetahui apa yang terjadi di balik kap mesin.

[00:52:00.29] Ya, itulah hal favorit kami sebagai pengembang JavaScript – “Ini berfungsi begitu saja, kami tidak perlu tahu caranya; mari kita terus bergerak. Saya punya tiket untuk ditutup, saya punya pengguna untuk dibuat senang, jadi minggir saja. ” [laughs]

Itu sangat bagus. Mark, saya ingin kembali ke masalah kuno, lagi, dari…

Paradigma ini keluar – aplikasi manajemen negara, apa yang tinggal di mana … Sekarang kita memiliki React, sekarang kita memiliki Klien Apollo, sekarang kita memiliki semua hal yang bersaing ini yang benar-benar menyulitkan orang biasa yang datang ke proyek baru, yang perlu membuat beberapa keputusan … Ada banyak penelitian dan pengetahuan kontekstual, dan ada manual yang hilang di sini tentang apa yang harus dilakukan kapan, dan apa yang harus digunakan kapan, dan sesuatu yang obyektif, dalam arti – saya pikir itu harus objektif karena bukan tentang mencoba membuat orang menggunakan alat ini versus alat itu, ini tentang memastikan bahwa Anda menggunakan alat yang tepat untuk masalah yang Anda coba selesaikan, bukan?

Dan pada akhirnya, begitulah selalu turun ke. Sejujurnya, saya sangat menyukai Redux, jika saya menemukan alat lain yang memenuhi kebutuhan saya dengan cara yang lebih baik – tentu saja; Saya akan meninggalkan. Tapi hari itu belum datang.

Hati-hati, Tandai. Dia akan melompatimu. [laughter]

Hari itu belum datang , orang-orang. Namun jika demikian, itu akan menarik, dan saya akan menerimanya dengan tangan terbuka, karena sejujurnya, web adalah tempat yang sangat tak kenal ampun, bukan? Ini meninggalkan banyak orang. Jadi jika Anda perlu mengadopsi, dan Anda perlu mengubahnya –

… beradaptasi agar tetap terkini… Ya, alat baru, tentu. Apakah Anda mengatakan MooTools, atau…?

Oh, nak… Ini lucu bahwa MooTools berima dengan alat baru, bukan? [laughs]

Ya, itu ironis. Tapi bagaimanapun, jadi bisakah kita membicarakannya secepat itu? Karena sungguh, kita bisa melakukan keseluruhan episode tentang ini, dan mungkin kita harus melakukannya di masa depan… Tapi sungguh, apa sajakah prinsip-prinsip panduan? Karena saya telah mendengar Anda mengatakan Anda tidak perlu menggunakan Redux jika Anda akan memiliki XYZ. Misalnya, jika Anda sudah memiliki aplikasi yang menggunakan Apollo untuk pengambilan data, Anda tidak perlu membawa Redux untuk melakukan pengambilan data. Dan kode orang selalu ada di berbagai negara bagian. Mereka selalu mengadopsi alat di berbagai tahap dalam siklus hidup aplikasi mereka… Ya, bagaimanapun juga. Saya sudah selesai mengomel, saya ingin mendengar pemikiran Anda.

Tentu. Jadi saya adalah pendukung besar beberapa ide spesifik. Salah satunya adalah Anda harus selalu mencoba untuk memahami masalah apa yang coba dipecahkan oleh alat tertentu, dan bagian dari itu adalah “Apa waktu dan konteksnya dan alasan mengapa alat ini ditemukan?” Dan yang lainnya adalah Anda perlu memahami dengan tepat masalah apa yang Anda coba selesaikan dalam aplikasi Anda sendiri sekarang, dan memilih alat yang paling tepat untuk memecahkan masalah Anda; bukan karena orang lain mengatakan Anda harus menggunakannya, bukan karena populer, tetapi karena inilah yang paling cocok untuk saya dalam situasi khusus ini.

Jadi dalam kasus Redux , ini diciptakan sebagai implementasi dari arsitektur Flux, yang pada gilirannya dibuat untuk mengatasi keterbatasan yang ditemukan orang dalam manajemen keadaan berbasis pemicu-peristiwa, seperti Backbone secara khusus. Jadi saya menetapkan user.firstname, ini memicu peristiwa “ubah nama depan”, beberapa kode lain mendengarkannya, itu memicu peristiwa lain … Hal berikutnya yang Anda tahu, Anda 15 peristiwa di satu tumpukan panggilan sinkron besar, dan Anda memiliki tidak tahu mengapa ini terjadi di tempat pertama. Itulah yang Flux ciptakan untuk dipecahkan, dan Redux pada dasarnya menyempurnakan pendekatan tersebut. Dan itulah masalah yang coba dipecahkan orang pada tahun 2015.

[00:56:18.25] Sekarang, itu juga terjadi karena React Redux menggunakan React Context API dari awal, menggunakan Redux dalam aplikasi React juga kebetulan secara tidak sengaja memecahkan masalah umum lainnya. masalah, yaitu a) banyak bagian berbeda dari aplikasi saya perlu menggunakan status yang sama pada saat yang sama, dan saya biasanya harus mengangkat status itu mungkin sampai ke komponen aplikasi root agar banyak komponen dapat dibagikan data. Tetapi jika saya melakukan itu, saya kemudian harus mengebor dan meneruskan data itu sebagai alat peraga melalui setiap tingkat pohon komponen, yang merupakan masalah kerajaan. Jadi menggunakan Redux dengan React agar orang-orang mengesampingkan masalah itu… Dan itulah alasan mengapa banyak orang memilih Redux di ’15, ’16, ’17.

Nah, dengan React 16.3, React keluar dengan API Konteks baru yang lebih baik, yang tidak seperti yang lama, direkomendasikan untuk penggunaan produksi sejak diluncurkan. Dan satu-satunya tujuan Konteks adalah untuk bertindak sebagai mekanisme injeksi ketergantungan yang mencakup beberapa bagian dari subpohon Anda, di mana Anda mengatakan “Ini adalah nilai”, dan setiap bagian dari subpohon komponen tersebut dapat meminta untuk membaca nilainya. Hanya itu yang dilakukannya.

Jadi jika satu-satunya hal yang Anda Yang perlu dilakukan dengan Redux adalah menghindari melewatkan data sebagai props melalui 15 level komponen Anda – yah, itulah tujuan sebenarnya dari Context diciptakan. Jadi jika hanya itu yang Anda butuhkan, Anda tidak perlu menambahkan Redux hanya untuk menambahkan kemampuan itu; gunakan Konteks sebagai gantinya.

Sekarang, saya akan pergi off pada titik tertentu di sini. Saya selalu melihat orang membandingkan “Haruskah saya menggunakan Konteks atau haruskah saya menggunakan Redux?” Dan mereka tampaknya berpikir bahwa Konteks itu sendiri adalah sistem manajemen negara. Ini bukan. Ini adalah mekanisme injeksi ketergantungan, dan Anda dapat memasukkan nilai apa pun yang Anda inginkan dalam Context, dan paling sering Anda adalah orang yang mengelola status tersebut dalam komponen React, dengan hook useState atau hook useReducer. Dan Andalah yang memutuskan di mana negara tinggal, menangani bagaimana memperbaruinya, dan kemudian memasukkan nilainya ke dalam Konteks untuk distribusi.

Jadi ya, useReducer plus useContext bersama-sama membentuk sistem manajemen negara. Dan yang itu lebih setara dengan apa yang dilakukan Redux dengan React. Tapi Konteks itu sendiri bukanlah sistem manajemen negara.

Di sisi lain, hampir semua orang perlu menyimpan beberapa status server di aplikasinya. Mari kita ambil beberapa data tentang pengguna kita, pada posting kita, pada komentar kita, dan kemudian menampilkannya. Dan secara tradisional, itu dilakukan oleh REST API dan yang lainnya… Tapi sekarang kami memiliki GraphQL. Dan meskipun tidak semua orang menggunakan GraphQL, banyak juga yang menggunakannya. Dan meskipun GraphQL dengan sendirinya hanyalah protokol transfer data, “Berikut cara saya memformat permintaan saya, berikut cara saya memformat tanggapan saya”, asumsinya adalah Anda mungkin menggunakan klien canggih seperti Apollo Client untuk mengelola data tersebut. Dan Apollo Client memiliki banyak fitur bawaan, seperti menangani cache yang dinormalisasi dari semua data, dan jika saya meminta hal yang sama, itu sudah ada. Dan ini memberi Anda antarmuka kecil yang bagus ini seperti “gunakan kueri” dan memberikan Anda kembali “data sedang memuat kesalahan” di komponen Anda, sehingga Anda dapat memutuskan apa yang akan dirender.

[01:00:14.16] Demikian pula, jika satu-satunya hal yang Anda lakukan dengan Redux adalah menyimpan data cache dari server, dan Anda memilih untuk menggunakan GraphQL dan Anda memilih untuk menggunakan Apollo Client, maka Anda ‘ Anda baru saja memenuhi kasus penggunaan yang sebelumnya Anda pilih untuk menggunakan Redux, dan untuk situasi tersebut Anda tidak memerlukan Redux.

Demikian pula, ada beberapa yang baru perpustakaan – SWR dan React-query, yang melakukan hal yang sama, tetapi lebih berfokus pada REST API. Ini hanya “Ini URL saya, ambil, kembalikan” data sedang memuat error “dan mereka menyimpan cache secara resmi dan dapat membagikannya beberapa. Dan lagi, jika itu satu-satunya hal yang Anda lakukan dengan Redux dan Anda memilih alat lain ini, maka alat tersebut menggantikan kasus penggunaan tersebut dan Anda tidak benar-benar memerlukan Redux pada saat itu.

Di sisi lain, sementara Anda dapat melakukan beberapa bit terbatas dari manajemen status klien dengan Apollo atau mungkin dengan React-query, itu sebenarnya bukan kasus penggunaan yang dimaksudkan untuk itu. Jadi cara saya membedakannya adalah Redux adalah alat manajemen status yang sangat umum yang dapat digunakan untuk beragam kasus penggunaan. Status cache dari server, status UI, pengelolaan data kompleks lainnya di klien … Namun, ini mungkin tidak akan menjadi alat terbaik atau paling efisien di salah satu kasus penggunaan tersebut. Alat lain seperti React-Query atau Apollo jauh lebih terspesialisasi untuk kasus pengambilan data khusus ini.

Jadi, Anda dapat melakukan banyak hal dengan Redux. Ini mungkin bukan yang terbaik dari semuanya, tetapi Anda dapat melakukan banyak hal berbeda. Anda dapat melakukan cache server dengan Apollo dan React-query, mereka akan sangat ahli dalam hal itu, tetapi Anda tidak dapat melakukan beberapa hal lain ini. Jadi pertanyaannya adalah “Masalah spesifik apa yang Anda coba selesaikan? Masalah apa yang dipecahkan oleh alat ini? ” dan “Di mana tumpang tindih antara keduanya?”

Itu sangat masuk akal. Ini benar-benar topik yang dalam. Sangat menarik, dan sangat menyenangkan melihat bagaimana ekosistem juga telah berevolusi untuk berspesialisasi dalam bidang pengelolaan negara, yang juga bagus… Tapi menurut saya kita semua berdiri di atas pundak raksasa, dan saya pikir Redux dan pola dari arsitektur Flux secara umum telah benar-benar membuka jalan bagi manajemen status yang lebih waras secara keseluruhan. Jadi sangat menarik untuk melihat seberapa jauh kita telah datang.

Bahkan hanya dengan keberadaan file Redux DevTools pada dasarnya adalah taruhan tabel pada saat ini. Jika Anda memperkenalkan pustaka baru, Anda harus memiliki alat pengembang sendiri, atau menemukan cara untuk mengintegrasikan pustaka Anda dengan Redux DevTools sebagai dasar… Dan saya telah melihat banyak pustaka mencoba melakukan itu.

Ada apa, Jerod – menaikkan air pasang untuk semua perahu? Apakah saya mengatakannya dengan benar?

Tepat sekali. Pasang naik menaikkan semua kapal.

Ya terima kasih. Ini dia. Jauh lebih baik. Ya, terima kasih banyak atas waktunya, Mark. Luar biasa.

Ya, tentu saja, Mark. Anda pasti telah naik air pasang – Saya tidak tahu bagaimana Anda naik pasang, tetapi –

Bangkit … Kami bahasa Inggris yang baik! Hanya bercanda.

Kami bahasa Inggris yang baik di sini. Itulah mengapa kami membuat podcast…

Kami berterima kasih kepada Anda untuk datang ke JS Party dan berbagi – Anda memiliki pengetahuan mendalam yang luar biasa tidak hanya tentang Redux, tetapi juga arsitektur aplikasi. Terima kasih banyak telah membagikannya dengan kami, dan untuk semua pekerjaan yang Anda lakukan… Pekerjaan yang sering kali tanpa pamrih dalam menjawab pertanyaan orang di internet – kami di sini untuk berterima kasih atas nama mereka. Itu sangat keren.

Apa cara terbaik yang bisa dilakukan orang terhubung dengan Anda dan mungkin memanfaatkan kebijaksanaan Anda, dan mungkin mengucapkan terima kasih atas semua pekerjaan yang Anda lakukan di Redux dan di komunitas?

[01:03:57.21] Tentu. Blog saya ada di blog.isquaredsoftware.com. Saya memiliki banyak React dan Redux dan beberapa hal lainnya di sana juga… Mungkin posting terbaru saya yang paling populer adalah risalah 6.000 kata tentang cara kerja perilaku rendering React. Seperti, kapan React merender ulang, apa yang menghentikan React dari rendering, bagaimana Anda mengoptimalkannya, bagaimana Context dan React Redux berinteraksi dengannya. Saya juga baru saja memasang beberapa pos baru dalam beberapa hari terakhir dengan beberapa saran karier pengkodean tentang hal-hal yang menurut saya berguna dalam karier saya sebagai pengembang. Satu posting tentang nilai menyimpan jurnal pekerjaan harian, dan yang lainnya adalah beberapa tip tentang cara mengevaluasi perpustakaan pihak ketiga dan alat perangkat lunak dengan benar. Begitu banyak dan banyak tulisan di blog saya.

Saya cukup aktif di Twitter di @acemarke. Juga di saluran obrolan Reactiflux Discord, pegangan yang sama. Saya biasanya @acemarke atau @markerikson di berbagai tempat di internet.

Mark, saya lakukan ceramah di NodeConf EU tentang pengelolaan ketergantungan dalam skala besar, dan itulah salah satu hal yang akan saya bicarakan – rubrik yang saya gunakan saat memilih paket… Jadi sekarang saya akan menambahkan blog Anda sebagai daftar sumber daya untuk pembicaraan saya. Terima kasih untuk itu. [laughs]

Benar. Saya menemukan yang satu itu sebagian besar panduan lengkap untuk rendering React. Semua tautan ke semua hal ada di catatan pertunjukan untuk kesenangan mengklik Anda. Terima kasih banyak sudah mendengarkan. Itulah Pesta JS untuk minggu ini.

Hai, nantikan minggu depan , ini adalah pertunjukan game perseteruan frontend kami. Ini akan menjadi ekstravaganza, Anda tidak ingin melewatkannya!

Pengembang JavaScript senang, saya akan katakanlah, tidak ada kode… Dalam arti seperti “Lebih sedikit kode itu baik.”

Yang disukai pengembang lebih banyak kode… ?

Saya diberitahu bahwa itu Orang-orang Jawa…

Oke, saya sedang menunggu yang satu itu… Menyajikan itu di atas piring…

Terkadang lebih banyak kode adalah… Ya , Saya merasa terkadang lebih banyak kode adalah –

Jadi singkatnya adalah jiwa memang, tapi itu belum tentu jiwa dari keterbacaan.

Atau rawatan. Itulah masalahnya. Tepat seperti itu.

Sangat mudah untuk over- abstrak, dan saya sendiri pernah bersalah akan hal itu sebelumnya.

Terima kasih. Terima kasih! Tepat seperti itu. Jadi alangkah baiknya untuk membahasnya, dan tentunya beberapa kekuatan super lain yang Anda miliki Sudah terpasang di Redux Toolkit… Seperti fakta bahwa ini sangat terisi, tetapi ada juga rel… Anyways.

Oke, suka. Jadi Amal, bisakah kamu mengatakannya kembali? … Kerjakan sisi singkatnya, kencangkan.

Oke, saya akan bekerja di sisi singkatnya.

Kami akan memulai pertunjukan , dan saya hanya akan mengatakan “Pergi!” lalu Anda membukanya kembali dan kami akan melakukannya seolah-olah kami tidak hanya mengatakannya dengan lantang; kita bisa mengatakannya di acara, oke?

Ya, ya. Katakan di acara itu, ya.

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments