Redux: Tambahkan resep "Structuring Reducers"

Ini mungkin sedikit membantu https://github.com/nosovsh/reduceless

@BananaBobby : terima kasih atas tautannya, tetapi saya ingin mendokumentasikan dan mengklarifikasi penggunaan Redux idiomatik.

Terkait http://stackoverflow.com/questions/37647178/is-there-an-idiomatic-way-to-test-nested-state-branches/37647357#37647357

Kutipan Reactilux:

[8:33 PM] Francois Ward: di mana negara tinggal lebih merupakan masalah bagaimana Anda berencana untuk memanipulasinya daripada yang lainnya.
[8:34 PM] Francois Ward: jadi jika Anda memiliki, katakanlah flag "loading: true/false" yang -selalu- diperbarui saat Anda menyetel beberapa entitas, mungkin harus tetap ada di sana.
[8:34 PM] Francois Ward: jika sepenuhnya independen, berubah secara terpisah, dll, maka itu harus menjadi miliknya sendiri.
[8:34 PM] Francois Ward: saat Anda mengembangkan aplikasi, Anda akan sering memfaktorkan ulang hal itu.
[8:35 PM] Francois Ward: karena hubungan antara tindakan, komponen, dan reduksi benar-benar longgar dan dapat diubah, itu dapat berubah setiap saat.

Ini mungkin berguna: http://stackoverflow.com/questions/37738268/how-to-avoid-race-conditions-when-fetching-data-with-redux/37738420#37738420

Saya dapat menggunakan beberapa saran seputar penggunaan combineReducers ketika beberapa bagian status statis dan tidak perlu dikurangi. Berikut adalah contoh yang dibuat-buat:

// This is what I'd like the state to look like:
{
  isUserSignedIn: true, // static, hydrated data - doesn't need a reducer
  todoTemplates: [...], // same
  todos: [...] // hydrated then manipulated - needs a reducer
}

// This is one way of making it work:
const reducer = combineReducers({
  isUserSignedIn: (state = false) => state, // basically a noop reducer
  todoTemplates: (state = []) => state, // same
  todos: todosReducer
});

Solusi di atas sangat tidak praktis dan terukur ketika jumlah irisan statis dari status meningkat. Saya dapat memikirkan beberapa cara lain untuk membuat ini berfungsi, tetapi tidak ada yang benar-benar menonjol sebagai solusi yang tepat:

• jangan gunakan combineReducer => tidak terukur
• pindahkan semua data statis di bawah kunci umum, seperti static , dan gunakan peredam noop pada itu => scalable, tetapi static agak jelek dan tidak menjelaskan apa sebenarnya data itu (dan mungkin tidak ada nama yang sesuai, karena semua sub-kunci statis mungkin tidak memiliki kesamaan).

Tidak benar-benar dimaksudkan sebagai utas Tanya Jawab, tetapi itu jelas merupakan pertanyaan menarik yang belum pernah saya pertimbangkan sebelumnya.

Pikiran awal saya adalah bahwa nilai statis seperti itu seharusnya tidak benar-benar dalam status Redux, tetapi mengingat itu adalah sesuatu yang terhidrasi server, saya dapat melihat maksudnya. Saya sebenarnya mendapatkan beberapa data statis yang kembali di halaman Host saya (nama lengkap pengguna, dll), dan saat ini beberapa komponen saya hanya merujuk window.theVariableFromTheServer , tapi itu ide yang menarik sekarang Saya memikirkannya.

Saya akan berpikir bahwa meletakkannya di bawah kunci staticData dengan peredam noop akan masuk akal. Misalkan pertanyaan besarnya adalah berapa banyak jenis data ini yang ada, dan dari mana asalnya.

@axelboc berikut adalah beberapa opsi:

1. Jangan menaruh barang statis di toko.
2. Cukup tulis peredam root Anda sendiri yang menyimpan semua kunci status, lalu menimpanya dengan apa pun yang dikembalikan oleh reduksi gabungan Anda. Dengan kata lain, kunci statis disimpan, dan kunci dinamis masih dapat menggunakan combineReducers

combinedReducers = combineReducers({
  todos: todosReducer
 })

rootReducer = function(state, action) {
  return Object.assign({}, state, combinedReducers(state, action));
}

Lihat juga masalah ini: https://github.com/reactjs/redux/issues/1457

Secara khusus, komentar Dan di sini: https://github.com/reactjs/redux/issues/1457#issuecomment -191347804

Wow terima kasih! Ini pasti harus masuk ke dokumen. Saya akan menggunakan solusi kedua Anda @naw , karena berurusan dengan data statis dengan cara yang sama seperti data dinamis akan menghasilkan kode terbersih dalam situasi saya.

Peredam root khusus ini sangat mudah, logis, dan nyaman, sehingga agak mengejutkan bagi saya bahwa itu belum menjadi fitur bawaan combineReducers (mungkin fitur keikutsertaan). Bagaimanapun, saya yakin ada alasan mengapa tidak, dan ini jelas bukan utas untuk itu ... Jadi terima kasih atas bantuan Anda!

Dua pemikiran:

• menempatkan data "statis" di toko Redux adalah kasus penggunaan yang relatif kurang umum. Bagaimanapun, artikel asli Dan tentang "The Case for Flux" menunjukkan bahwa pendekatan mirip Flux sebagian besar berguna untuk data yang berubah seiring waktu.
• Per komentar saya di bagian atas utas ini: reduksi adalah _hanya fungsi_, dan combineReducers adalah _just_ fungsi utilitas untuk kasus penggunaan yang paling umum. Sama seperti bagian lain dari kode aplikasi Anda, Anda dapat memecah hal-hal menjadi fungsi dengan cara apa pun yang masuk akal bagi Anda, hanya saja dengan reduksi secara keseluruhan harus mematuhi aturan dasar (state, action) -> newState dan pembaruan yang tidak dapat diubah. Tentu saja tidak berarti bahwa fungsi _every_ reducer harus memiliki tanda tangan (state, action) tepat, hanya saja hasil akhirnya perlu disatukan seperti itu.

Senang Anda membuat semuanya berfungsi!

@markerikson Mengenai maksud asli dari masalah yang Anda buat ini --- saya pasti setuju halaman tentang penataan reduksi akan sangat membantu.

Saya juga sangat setuju dengan pernyataan Anda:

Penekanan bahwa combineReducers hanyalah fungsi utilitas untuk kasus penggunaan umum dalam mendelegasikan logika pembaruan berdasarkan organisasi domain negara, dan bukan persyaratan

Secara pribadi saya pikir satu hal yang mungkin membantu adalah menstandarisasi terminologi mengenai hal-hal seperti "peredam akar", "sub-pereduksi", "pereduksi", "fungsi pembantu", "pabrik peredam", "status", "irisan", dll. beberapa kasus kami menggunakan istilah yang sama untuk merujuk pada hal yang berbeda, dan kasus lain kami menggunakan istilah yang berbeda untuk merujuk pada hal yang sama.

Misalnya, apa yang _harus_ kita sebut fungsi yang mengelola bagian tertentu dari status? Apakah mereka "pereduksi", "sub-pereduksi", keduanya, bukan? Apakah suatu fungsi dianggap sebagai peredam hanya karena "membantu" rootReducer mengelola status dalam beberapa cara, atau apakah itu _only_ peredam jika memiliki tanda tangan metode tertentu?

Pindah ke combineReducers secara umum:

Saya pikir Anda dapat membuat argumen bahwa combineReducers sebenarnya bukan "inti" redux . Ini adalah pola organisasi tingkat tinggi yang dihubungkan ke mesin redux utama (toko tunggal dengan operator dan langganan). Ada pola lain yang bisa dibilang berfungsi dengan baik, dan seperti yang telah Anda tunjukkan, yang terpenting adalah rootReducer itu sendiri memperlihatkan tanda tangan metode yang benar.

Kita perlu membantu orang memahami bahwa combineReducers hanyalah sebuah pola, dan mungkin membungkus beberapa terminologi standar di sekitar pola ini serta pola lainnya, sehingga kita memiliki bahasa untuk ekosistem secara keseluruhan. Misalnya, jika pihak ke-3 menyediakan "sub-reducer", ia memerlukan cara untuk mengomunikasikan cara yang diharapkan untuk disematkan ke rootReducer. Apakah itu akan disematkan melalui combineReducers dalam kunci/slice yang diberikan, atau apakah itu akan disematkan di tingkat atas, atau apakah itu sesuatu yang lain?

Sangat mudah bagi alat pihak ke-3 hanya untuk "mengasumsikan" semua orang menggunakan combineReducers , meskipun combineReducers tidak diperlukan. Terkadang layak untuk alat pihak ke-3 untuk mengakomodasi lebih dari satu pola sekaligus. Misalnya, https://github.com/reactjs/react-router-redux dapat menampung combineReducers _and_ reduce-reducers : https://github.com/reactjs/react-router-redux/pull/183

Mungkin akan membantu untuk menyoroti beberapa pola lain ini di samping combineReducers untuk membuatnya lebih jelas bahwa combineReducers _tidak_ diperlukan?

Hanya mencoba untuk bertukar pikiran dengan Anda ...

@naw : komentar yang luar biasa, dan pasti beberapa hal yang

Oke. Saya akhirnya, _finally_ duduk untuk mulai mengerjakan ini. Sejujurnya, ada begitu banyak topik terkait yang terlibat di sini sehingga saya tidak yakin bagaimana menanganinya.

Halaman dokumen kosong awal didorong ke https://github.com/markerikson/redux/blob/structuring-reducers-page/docs/recipes/StructuringReducers.md . Saya akan mencoba untuk memperbaruinya saat saya pergi. Saran dan umpan balik diinginkan!

Saya bisa memulai ini dan menyelesaikan pekerjaan pertama yang layak. Sayangnya, ini pada dasarnya menduplikasi sebagian besar dari apa yang sudah ada di halaman dokumen "Pereduksi", dan video Dan.

Ada beberapa alasan untuk itu. Pertama, saya merasa perlu menutupi hal-hal dari prinsip pertama. Hal-hal seperti apa itu "mutasi" dan "kekekalan", cara memperbarui data secara permanen, mendemonstrasikan cara memfaktorkan ulang peredam menjadi fungsi yang lebih kecil, dll.

Saya mungkin akan mengambil saran dari @naw dan http://reactkungfu.com/2015/08/pros-and-cons-of-using-immutability-with-react-js/ fantastis, http://wecodetheweb.com/2016/02/12/immutable-javascript-using-es6-and-beyond/ dan http://t4d.io/javascript-and-immutability/ cukup bagus.

Bagaimanapun, saya juga sedang memikirkan untuk memecah ini menjadi subhalaman. Sketsa kasar:

• Konsep pengantar dan aturan peredam
  
  
  
  • Artikel prasyarat
  
  
  • Struktur peredam dasar dan bentuk keadaan
  
  
  • Memisahkan reduksi (istilah dan konsep)
  
  
  • Memisahkan reduksi (contoh refactoring progresif)
  
  
  • Menggunakan combineReducers
  
  
  • Menggunakan sesuatu yang LAIN selain combineReducers
  
  
  • Menormalkan bentuk keadaan
  
  
  • Menulis reduksi untuk data yang dinormalisasi
  
  
  • Menargetkan pembaruan dan logika yang dapat digunakan kembali/dibagikan/duplikat
  
  

Dan, eh, apa pun yang saya temukan.

Satu sisi lain berpikir bahwa saya menulis di sini untuk referensi, tetapi belum akan membuat masalah: mungkin berguna untuk memiliki halaman "Arsitektur Redux Idiomatik" atau sesuatu, yang berbicara tentang hal-hal seperti menggunakan mapDispatch dan mengikat untuk menjaga komponen Anda "tidak menyadari" Redux, dll.

Terima kasih atas upaya Anda untuk mendidik masyarakat. Sangat menyenangkan memiliki akses ke begitu banyak materi sambil mencoba mempelajari hal-hal baru. Saya telah membaca sebagian besar artikel/postingan yang telah Anda tulis dan tautkan.

Saya benar-benar baru di Redux dan saya benar-benar ingin membaca beberapa praktik terbaik tentang apa yang harus disimpan di toko. Mungkin informasi seperti itu cocok dengan dokumen baru Anda? Saya mungkin jauh dari sini atau keluar sebagai orang bodoh, tetapi saya akan mencoba menjelaskan apa yang sulit saya pahami dengan menggambarkan alur dalam proyek baru yang sedang saya kerjakan.

• Sisi server adalah Node.js dan Postgres.
• REST-API untuk saat ini, mungkin soket web nanti.
• Aplikasi harus dapat digunakan tanpa jaringan, yaitu sinkronisasi data perlu dilakukan dua arah (data baru di aplikasi masuk ke server, data baru di server masuk ke aplikasi saat jaringan tersedia lagi)
• Penyimpanan lokal di aplikasi belum diputuskan (SQLite, AsyncStore, Realm, atau apa pun)
• Penyimpanan lokal di aplikasi perlu dienkripsi
• Data yang di-cache secara lokal mungkin ditarik setelah sinkronisasi jika hak akses pengguna diubah untuk beberapa objek di server.
• Beberapa data akan dijelaskan dengan Skema JSON untuk tata letak formulir dinamis. Skema akan diambil dari server juga. Apakah skema ini akan masuk ke toko juga? Mereka benar-benar statis setelah diambil.

Data apa yang pergi ke mana? Saya pikir saya ingin database lokal menjadi kebenaran. Setelah beberapa waktu penggunaan, basis data ini akan menyimpan sebagian besar data relevan yang diambil dari server sebagai cache offline. Setelah beberapa saat saya akan membuang data lama.

Saya berasumsi bahwa Redux akan berfungsi sebagai semacam cache sekunder? Yaitu tidak akan menyimpan data yang tidak dimuat/digunakan dalam sesi aplikasi ini, bukan? Atau haruskah Redux menyimpan semua data? Jika demikian halnya, database lokal akan menjadi salinan persis dari toko Redux dan toko Redux berpotensi menjadi cukup besar.

Saya memiliki banyak penanganan gambar di aplikasi. Gambar akan direferensikan dari objek di toko Redux oleh UUID (juga kunci dalam DB Postgres). Disk lokal pada perangkat berfungsi sebagai cache gambar dengan UUID sebagai nama file. Saya seharusnya tidak menyimpan data biner di toko Redux bukan? Atau ada keseimbangan di suatu tempat? Mungkin thumbnail yang disandikan Base64 dapat hidup di toko? Tapi bukan file jpg 5 Mb pastinya..

Dalam urutan apa saya harus mengambil data?
A. Wadah membutuhkan alat peraga. Alat peraga diambil dari DB lokal jika tersedia, jika tidak dari REST API. Setelah mengambil, data akan diduplikasi di db lokal dan toko Redux.

atau B. Wadah membutuhkan alat peraga. Alat peraga diambil dari DAO lokal yang menangani DB lokal sebagai cache

Dan bagaimana dengan menulis perubahan lokal ke database lokal untuk sinkronisasi nanti dengan server? Haruskah saya memiliki DAO yang berlangganan untuk menyimpan perubahan dan menyimpan perubahan ke database. Dan pada saat yang sama memiliki sinkronisasi berlangganan perubahan untuk mengirim ke server jika jaringan tersedia?

Saya mengalami kesulitan untuk membayangkan bagaimana Redux cocok dengan database lokal. Semoga saya terlalu banyak memikirkan hal-hal dan sebagai gantinya ada solusi yang sangat sederhana untuk semua ini =)

Dan beberapa pemikiran tentang kekekalan (konsep yang cukup baru bagi saya juga)..
Jika saya mengerti dengan benar, saya dapat membuat salinan dangkal dari keadaan di peredam untuk menghemat waktu yang diperlukan untuk membuat salinan yang dalam? Ini akan dilakukan hanya untuk mendapatkan referensi objek baru dan mengelabui konsumen data bahwa saya telah memberikan objek baru yang mengkilap. Tetapi sebenarnya saya memiliki data referensi lama yang sama lebih dalam di objek. Apakah ini benar-benar kekekalan? Saya baik-baik saja dengan apa pun, tetapi saya benar-benar ingin membaca lebih banyak tentang ini. Berapa banyak bagian negara yang harus tidak berubah agar negara dianggap tidak berubah? Saya mungkin telah salah memahami sesuatu di sini ...

Btw, terima kasih banyak atas jawaban Anda di SO tentang struktur toko.

Setelah tidur, saya sekarang melihat bahwa saya mungkin telah membajak utas Anda dengan pertanyaan saya sendiri. Silakan ambil pertanyaan di atas sebagai masukan dan saran tentang apa yang harus dimasukkan dalam StructuringReducers Anda.

Ya, sedikit penyimpangan di sana. Anda mungkin ingin masuk ke saluran obrolan Reactiflux dan mengajukan beberapa pertanyaan di sana.

Untuk kekekalan, kuncinya adalah Anda tidak pernah mengubah konten referensi objek yang ada. Jika Anda memiliki tanda = untuk tugas, dan benda di sisi kiri = belum menjadi salinan, Anda mungkin secara langsung memutasikan data. Jadi ya, itu berarti membuat salinan dangkal, dan menimpa beberapa bidang di objek yang disalin itu. Lihat daftar artikel yang saya tautkan untuk topik ini di https://github.com/markerikson/react-redux-links/blob/master/immutable-data.md. Anda mungkin juga ingin membaca FAQ Redux, yang mencakup topik-topik seperti kloning dalam vs kloning dangkal: http://redux.js.org/docs/FAQ.html#performance -clone-state

Meskipun saya tidak ingin membahas seluruh konsep memperbarui data secara permanen, mungkin akan berguna untuk menambahkan halaman yang menunjukkan berbagai resep dan pendekatan untuk tugas-tugas tertentu. Misalnya, memperbarui bidang objek bersarang menggunakan Object.assign vs penyebaran objek vs beberapa utilitas pembaruan yang tidak dapat diubah vs lensa Ramda.

Topik terkait lainnya: reduksi "tipis" vs reduksi "tebal", per http://redux.js.org/docs/FAQ.html#structure -business-logic . Saya sendiri sangat cenderung ke arah reduksi 'tebal', tetapi saya telah melihat sejumlah utilitas dan lib yang memperlakukan sebagian atau seluruh toko Redux sebagai penyimpanan kunci/nilai sederhana, dengan logika peredam sepanjang baris return {...state, ...action.payload} .Saya tahu @phoenixmatrix tampaknya lebih suka pendekatan semacam itu. Itu jelas sangat mengubah struktur logika peredam.

Bagi siapa pun yang benar-benar memperhatikan hal ini: Saya sedang dalam perjalanan kerja, tidak mendapatkan apa-apa dalam jadwal saya untuk akhir pekan, dan pada dasarnya bermaksud menghabiskan seluruh akhir pekan untuk mencoba membuat lebih banyak dokumen ini. Kita lihat seberapa banyak kemajuan yang saya buat.

Alat pembaruan data yang tidak dapat diubah:

• utilitas seperti dot-prop-immutable dan React Update Addons
• utilitas umum seperti Lodash (dalam mode "FP") dan Ramda
• Redux-ORM

Mampu membuat draf pertama untuk "Menggunakan combineReducers " dan "Di luar combineReducers " kemarin. Sepertinya beberapa topik berikutnya dalam daftar saya berurusan dengan data yang dinormalisasi.

Saya juga harus memasukkan sesuatu tentang pendekatan yang digunakan Dan dalam seri video pertamanya, di mana ia mendefinisikan fungsi peredam untuk _single_ todo, dan kemudian menggunakannya kembali dalam beberapa konteks berbeda untuk melakukan pembaruan ( https://github.com/tayiorbeii/ egghead.io_redux_course_notes/blob/master/08-Reducer_Composition_with_Arrays.md )

Pembacaan data yang dinormalisasi:

• https://github.com/paularmstrong/normalizr/pull/80#issuecomment -206981676
• https://Gist.github.com/amannn/89b8f4e1c52541d323c574fcb5a80b83
• http://www.robinwieruch.de/the-soundcloud-client-in-react-redux-normalizr/
• https://medium.com/@mcowpercoles/using -normalizr-js-in-a-redux-store-96ab33991369
• https://github.com/reactjs/redux/issues/1255
• https://github.com/reactjs/redux/issues/1824
• https://github.com/reactjs/redux/issues/994#issuecomment -153341165
• http://stackoverflow.com/questions/34954726/how-do-you-add-remove-to-a-redux-store-generated-with-normalizr

@markerikson utas ini sangat informatif, terima kasih untuk semua

@mmazzarolo : Terima kasih. Jika Anda memiliki umpan balik khusus tentang versi WIP halaman dokumen saat ini, saya pasti ingin mendengarnya.

Terima kasih @markerikson untuk ikhtisar luar biasa tentang penataan reduksi ini! Menantikan untuk membaca https://github.com/markerikson/redux/blob/structuring-reducers-page/docs/recipes/reducers/07-UpdatingNormalizedData.md ;)

@davincho : Terima kasih. Jika Anda memiliki komentar atau saran lain, beri tahu saya.

Adakah hal khusus yang berkaitan dengan data yang dinormalisasi yang ingin Anda bahas?

@markerikson Mungkin makanan untuk bab "Memperbarui data yang dinormalisasi":
http://stackoverflow.com/questions/39243075/redux-structure-for-image-capturing

Saya akan senang mendengar jika ada praktik terbaik untuk pembaruan "kepemilikan" semacam ini. Yaitu entitas mana yang harus bertanggung jawab untuk memperbarui hubungan.

Dalam "peredam irisan", apakah lebih baik memberi nama status arg state atau sesuatu yang lebih dekat dengannya? Dengan kata lain:

• function todosReducers(state, action)
• function todosReducer(todos, action)
• function todosReducer(todosState, action)

Karena itu hanya penamaan variabel lokal, sepenuhnya terserah Anda. Saya bisa melihat argumen dua arah. Menyebutnya state akan tetap berpegang pada konvensi yang konsisten. Memberinya nama tertentu bisa lebih mudah dibaca untuk maksud dan konteksnya.

@michaelswe : Baca pertanyaan SO Anda, dan saya tidak yakin saya cukup memahami konteksnya. Bisakah Anda membuat sketsa struktur toko Anda saat ini untuk saya?

Juga, saya tidak yakin saya memahami frasa "entitas mana yang harus bertanggung jawab untuk memperbarui hubungan". Entitas sebenarnya hanyalah data biasa - logika peredamlah yang bertanggung jawab untuk melakukan pembaruan.

@markerikson beberapa masukan dari saya:

• Praktik terbaik berbagi logika pembaruan entitas (Memperbarui jenis entitas yang sama tetapi dalam pembuat tindakan yang berbeda)
• Memperbarui entitas bersarang (dinormalisasi dengan normalizr ). Mungkin solusi umum dimungkinkan karena hubungan antar entitas diketahui melalui definisi Schema .

@markerikson Terima kasih telah meluangkan waktu untuk pertanyaan SO saya. "Aku seharusnya menulis peredam mana yang harus bertanggung jawab .."

Ini hampir bermuara pada skenario master/detail, tetapi ini adalah hubungan 1: 1 jadi saya perlu memperbarui kunci asing master setelah membuat detail. Tampilan menunjukkan catatan master dan saya perlu membuat catatan detail dan menautkannya ke master.

Dalam kasus ketika gambar adalah "detail" beberapa tipe entitas master perlu mereferensikan gambar dengan cara yang berbeda. Beberapa contoh:

project.coverImage
profile.avatar
profile.avatarThumbnail
controlpoint.imageSebelumnya
controlpoint.imageAfter

Jadi, setelah gambar disimpan ke disk, saya perlu menginstruksikan peredam untuk mengisi catatan master dengan cara yang benar. Ini dapat dilakukan dengan berbagai cara, tetapi saya pikir mungkin ada praktik terbaik untuk ini.

1. "Tampilan master" dapat mengirimkan tindakan yang mendorong cameraView ke tumpukan navigasi dan mengisi props dengan idnya sendiri (master id) dan id dari catatan detail di masa mendatang. Ini dapat dilakukan dalam thunk yang juga mengirimkan informasi yang diperlukan untuk memperbarui catatan master dengan id detail. Saya harus menangani kasus di mana pengguna menutup cameraView tanpa menyimpan gambar dan mengatur ulang catatan detail yang diatur secara optimis di master.
2. Tampilan master dapat mengirimkan tindakan yang mendorong cameraView dan menyertakan semua instruksi yang diperlukan untuk peredam untuk memperbarui entitas master setelah fakta bahwa gambar disimpan.

Saya berharap bahwa saya berhasil menjelaskan diri saya lebih baik kali ini.

Pasti perlu mengatasi keadaan inisialisasi. Mungkin yang terbaik jika saya hanya menyalin jawaban Dan di http://stackoverflow.com/questions/33749759/read-stores-initial-state-in-redux-reducer/33791942 .

Rangkuman masalah/diskusi "beberapa data yang dimasukkan": https://github.com/reactjs/redux/issues/1602#issuecomment -208987442

Ya. Saya AKHIRNYA berhasil menjalankan "Mengelola Data yang Dinormalisasi". Saya juga melanjutkan dan menyalin jawaban Dan tentang "Inisialisasi Status" dari Stack Overflow ke subhalaman terpisah dan memperbarui pemformatan.

Dengan itu, saya _berpikir_ saya telah menyelesaikan semua konten utama yang ingin saya liput untuk upaya ini. Langkah selanjutnya adalah melihat hal ini, dan melihat kegunaan konten, organisasi, dll.

Saya belum mencoba untuk benar-benar membangun barang-barang Gitbook di cabang ini. Saya pikir saya akan menunggu sampai saya selesai konten-bijaksana untuk mencobanya.

@reactjs/redux , @jimbolla , @Aweary , @naw , @phoenixmatrix , @tommikaikkonen , et al: Saya akan sangat menghargai setiap dan semua umpan balik tentang hal-hal yang telah saya kumpulkan di sini. Saya pasti berpikir bahwa urutan topik perlu dikocok sedikit. Juga, tautan saat ini ke "Konsep Prasyarat" di halaman TOC mungkin perlu diformat ulang dengan lebih baik. Di luar itu... pikiran? Komentar? Saran?

Bisakah kamu membuat PR? Itu akan memungkinkan kami mengomentari hal-hal baris demi baris, bukan pada dokumen secara keseluruhan.

@timdorr : Selesai. Lihat #1930 .

Oke, jadi kami telah menggabungkan konten utama. File TOC perlu diperbarui untuk menyertakan halaman baru, dan saya juga ingin mengganti nama.

Sebagai catatan tambahan, dokumen tampaknya memiliki beberapa penomoran ganjil yang terjadi. Mereka _harus_ diberi nomor "1, 2, 3", tetapi malah "1.1, 1.2, 1.3", dll. Melihat beberapa contoh Gitbook lainnya dan tidak dapat melihat perbedaan nyata dalam definisi TOC.

Ini digabungkan! Ya!

W00t!