Redux: Merekomendasikan agar konstanta Action diberi nama dalam bentuk lampau

Ini terdengar masuk akal bagi saya!

saya setuju :+1:

Saya tidak yakin (belum), tetapi terbuka untuk diyakinkan.
Bagi saya Tindakan adalah niat, peredam mungkin memilih untuk tidak bertambah, jadi COUNT_INCREASED terasa agak aneh saat itu.
Juga { type: 'COUNT_INCREASED', data: 2 } memiliki arti yang sama sekali berbeda ("meningkat menjadi 2") dengan { type: 'INCREASE_COUNT', data: 2 } ("meningkat 2").

Dalam kasus BUTTON_PUSHED, masuk akal - tetapi saya tidak setuju bahwa INCREASE_COUNT harus menjadi COUNT_INCREASED - jumlah tidak meningkat ketika AC membuat tindakan itu.

Saya tidak langsung yakin. Aku harus memikirkan idenya.

Sebenarnya, dalam hal ini nama lengkapnya adalah COUNT_INCREASE_REQUESTED,
yang memang agak panjang tapi tetap menyampaikan maksud sebenarnya.

COUNT_INC_REQD?

Pada Minggu, 2 Agustus 2015, 04:12 Kier Borromeo [email protected] menulis:

Saya tidak langsung yakin. Aku harus memikirkan idenya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/gaearon/redux/issues/384#issuecomment -126977702.

Tidak.
(diketik di ponsel, maaf singkat)

Saya pikir ActionCreator memiliki kewajiban untuk memeriksa apakah suatu tindakan
mungkin (melalui thunk) sebelum mengirimkannya secara membabi buta.

Reducer memiliki kewajiban untuk selalu menjaga status yang dikembalikan tetap valid.

Log tindakan adalah kebenaran dari apa yang terjadi, dan keadaan hanyalah
refleksi dari itu.

Pada Minggu, 2 Agustus 2015, 07:07 Wout Mertens wout. [email protected] menulis:

Sebenarnya, dalam hal ini nama lengkapnya adalah COUNT_INCREASE_REQUESTED,
yang memang agak panjang tapi tetap menyampaikan maksud sebenarnya.

COUNT_INC_REQD?

Pada Minggu, 2 Agustus 2015, 04:12 Kier Borromeo [email protected] menulis:

Saya tidak langsung yakin. Aku harus memikirkan idenya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/gaearon/redux/issues/384#issuecomment -126977702.

Tidak.
(diketik di ponsel, maaf singkat)

Tidak.
(diketik di ponsel, maaf singkat)

COUNT_INCREASED :-1: untuk alasan yang sudah disebutkan di utas
COUNT_INCREASE_REQUESTED :+1: tapi mungkin terlalu bertele-tele

Bagaimana dengan rekomendasi untuk menulis jenis tindakan dalam "mood imperatif" ( ala panduan gaya pesan commit Git Chris Beams yang terkenal). Jadi dalam hal ini INCREASE_COUNT bekerja dengan baik karena dalam mood imperatif, yaitu "ditulis seolah-olah memberi perintah atau instruksi", dan menyampaikan gagasan bahwa membuat tindakan hanya menandakan keinginan atau niat bahwa sesuatu harus terjadi pada satu titik waktu.

Saya cenderung melihat ActionTypes sebagai hal-hal yang telah terjadi di masa lalu juga. Saya menemukan fluks lebih mudah untuk awalnya grok dengan membandingkannya dengan ddd/cqrs/es yang sudah saya kenal. Diskusi antara @abdullin dan @fisherwebdev mungkin menarik di sini. Terutama bit berjudul "Tindakan -> Acara"

Secara pribadi, saya sampai pada kesimpulan bahwa kami menggabungkan dua pola desain dan dua model cara berpikir tentang suatu sistem. Keduanya valid dalam pemisahan dan mungkin mereka dapat dicampur dalam beberapa aplikasi.

Yang satu didasarkan pada EventSourcing di mana objek Action mewakili apa yang terjadi. Reducer kemudian menafsirkan masa lalu menjadi keadaan, reduksi yang berbeda dapat menafsirkannya ke dalam pandangan yang berbeda tentang masa lalu.

Yang kedua didasarkan pada write ahead log (WAL) . Ini digunakan untuk menyelesaikan segala macam masalah sulit, mulai dengan pemulihan sistem file dari jurnal, transaksi basis data, replikasi, pemulihan di komputer lain setelah kegagalan... Juga dikenal sebagai jurnal, log transaksi, log perintah...
Dalam hal ini, objek Tindakan mewakili niat utama untuk mengubah status dan apa pun yang diperlukan, misalnya TRANSACTION_BEGIN, TRANSACTION_COMMIT... WAL banyak digunakan dalam basis data untuk mengubah status. Segala macam masalah terdistribusi diselesaikan berdasarkan itu.

Saya pikir fluks vanila lebih mirip WAL. Saya pikir keduanya adalah pendekatan yang valid dan itu mungkin tergantung pada jenis aplikasi mana yang lebih masuk akal. Mungkin Redux harus tetap agnostik terhadap mereka.

Masalah saya dengan past tense adalah terkadang sulit untuk menamai objek tindakan dalam bentuk lampau. Masalah saya dengan mood imperatif adalah bahwa hal itu terikat pada pola desain WAL. Oleh karena itu saya sedang menyelidiki opsi untuk menggunakan kata benda untuk menggambarkan objek tindakan saya. Mereka tampaknya berfungsi untuk kedua pola desain dan memungkinkan nama yang rumit. Mereka serupa, terkadang sama dengan mood imperatif, INCREASE_COUNT berubah menjadi COUNT_INCREASE, KUNJUNGAN adalah KUNJUNGAN dll.

Sebagai contoh kita dapat mengambil event DOM. Coba beri nama 'mousemove', 'mouseup', 'mousedown' dalam bentuk lampau, saya pikir tidak akan lama untuk menemukan tindakan rumit yang sama di domain Anda. Ini memungkinkan 'contextmenu' dan semacamnya.

Redux hanya dapat menjelaskan semua pendekatan dengan pro dan kontra dan membiarkan pengembang memilih model mana yang sesuai dengan aplikasinya dan berpikir lebih baik. Saya percaya bahwa Redux dapat menjadi agnostik dan dengan mudah mendukung keduanya.

Mungkin keduanya dapat diterima untuk kedua pola desain - COMMENT_DELETE atau COMMENT_DELETION, yaitu OBJECT_VERB atau OBJECT_NOUN sejauh OBJECT_VERB tidak dipahami sebagai suasana imperatif, yang tidak terlalu banyak dibandingkan dengan DELETE_COMMENT.

Inilah alasan mengapa memiliki keduanya dalam dokumen mungkin membingungkan (sementara secara teknis benar dalam pemisahan):

_Satu-satunya cara untuk mengubah status adalah dengan memancarkan tindakan, objek yang menjelaskan apa yang terjadi. (Tiga Prinsip)_

_Sebuah tindakan adalah objek polos yang mewakili niat untuk mengubah keadaan. (Aksi dalam Glosarium)_

@vladap Saya kira saya melihatnya dengan cara yang sama.
Saya pikir menjadi jelas bahwa tindakan itu sendiri didefinisikan cukup buruk untuk membuat banyak kebingungan. Kami memiliki kekurangan semantik tentang itu sekarang.
Tindakan - panggilan untuk melakukan sesuatu atau fakta bahwa sesuatu telah terjadi?
Jawaban atas pertanyaan ini mendefinisikan seberapa pintar seharusnya peredam. Ini membentuk seluruh aplikasi.
Saya pikir ada beberapa kesepakatan umum bahwa reduksi harus dibuang. Ini adalah inti dari redux yang harus sederhana, sinkron, dan dapat dimuat ulang. Untuk mendapatkan reduksi dump, kita harus menyebarkan kepada mereka tindakan seperti "panggilan untuk melakukan sesuatu" bukan "fakta". Karena fakta dapat diinterpretasikan secara berbeda, maka reducer cenderung membuat beberapa interpretasi yang otomatis membuatnya lebih pintar. Saya lebih suka memanggil "panggilan untuk melakukan sesuatu" - instruksi (nama panjang yang buruk, tapi saya suka semantik).
Saya pikir ada kesenjangan antara instruksi dan fakta sebagai nilai, tetapi sekarang kita menyebut keduanya tindakan - ini adalah sumber utama kebingungan.
Seperti yang dikomentari @gaearon
"Ada tindakan "pintar" yang berubah menjadi tindakan "bodoh" di beberapa titik, mereka sering menggambarkan "apa yang harus terjadi" Middleware menafsirkan tindakan cerdas dan mengubahnya menjadi tindakan bodoh."
Bentuk lampau cenderung bahwa suatu tindakan adalah fakta, jadi saya pikir ini sebenarnya ide yang buruk. Saya percaya bahwa peredam harus mendapatkan instruksi. Satu hal lain yang ingin saya sebutkan adalah bahwa ini semua terhubung dengan pertanyaan lain "di mana logika bisnis harus tinggal di aplikasi saya?". Pengguna mengklik di suatu tempat ( fakta ) yang diinterprietasikan sebagai array instruksi . (fakta)=>(Daftar[instruksi]) - inilah yang sebenarnya dilakukan actionCreator sekarang. Dan tidak jelas bagi saya bagaimana middleware berkorelasi dengan actionCreator. Saya pikir middleware lebih rendah dan seharusnya tidak membuat keputusan apa pun. Hanya beberapa hal isomorfik seperti unboxing promise dan thunks. PS Mungkin niat lebih baik karena lebih pendek seperti yang dikatakan @ioss tetapi sekali lagi instruksi lebih baik dalam semantik.

Saya suka ide untuk menggunakan kata benda! Ini - selain mudah disebutkan namanya - membuat mereka abadi, mereka adalah fakta dan maksud/instruksi pada saat yang bersamaan.

Meskipun reduksi mungkin sangat bodoh, mereka masih - menurut saya - dapat berisi logika bisnis, seperti: "hitungan tidak boleh menjadi negatif".
Jika mereka benar-benar bodoh, mereka harus dihapus dan diganti dengan yang generik.

Meskipun ini adalah diskusi akademis yang cukup, selama kita tidak memiliki validator tipe-tindakan-is-a-kata benda ;) +1 untuk kata benda

Contoh Couter terlalu sederhana dan tidak mewakili use case ini. Pertimbangkan bahwa kami menyinkronkan beberapa database. Dan kami ingin menunjukkan progress bar dari proses itu.

export function syncDb() {
    return (dispatch, getState) => {
        const {db:{client}} = getState().toJS();

        dispatch(createAction(STATUS_SYNC_DB)('syncing'));
        client.sync((progress)=> {
            dispatch(createAction(PROGRESS_SYNC_DB)(progress))
        }).then(()=> {
            dispatch(createAction(STATUS_SYNC_DB)('complete'));
        })
    };

Kode tidak lengkap tetapi menunjukkan ide. Karena kami memiliki async, bahkan tidak mungkin melakukan ini di peredam, jadi terpaksa dibuang di sini, tetapi pengguna mungkin tergoda untuk melakukan beberapa tindakan seperti SYNC_STARTED dalam kasus lain dan menulis beberapa logika bisnis di peredam.
Pereduksi adalah dump tetapi kami masih membutuhkannya dan kami dapat menggunakannya kembali untuk sinkronisasi dengan beberapa sumber lain, karena mereka adalah dump.

INIT_DB: (state, action) => state.merge(action.payload),
PROGRESS_SYNC_DB: (state, action) => state.set('dbSyncProgress', action.payload),
STATUS_SYNC_DB: (state, action) => state.set('dbSyncMode', action.payload)

Saya menggunakan immutablejs tetapi beberapa orang lain mungkin lebih suka js biasa dan menghapus semua js yang tidak dapat diubah dari reduksi, dan aplikasi masih akan berfungsi. Dan itu bisa dengan mudah dilakukan karena semua logika bisnis terletak di action creator. @ioss itu yang saya maksud dengan dump reducer. Jadi ada pemisahan kekhawatiran.

Satu hal lagi adalah akan luar biasa untuk mengirimkan instruksi dan fakta. Tetapi fakta harus dikirim sedemikian rupa sehingga mendahului eksekusi pembuat tindakan karena ini memungkinkan untuk menghasilkan tes untuk pembuat tindakan yang menurut saya merupakan bagian yang paling menarik untuk pengujian.

@lapanoid : Saya menentang reduksi yang benar-benar bodoh.
Pereduksi Anda adalah contoh yang baik karena begitu bodoh sehingga bisa diganti dengan sesuatu seperti:
(status, aksi) => state.set(action.type, action.payload)

Ini berarti: Jika action.payload tidak pernah diproses atau diputuskan oleh reduksi (karena mereka seharusnya tidak memiliki logika bisnis), pembuat tindakan mungkin hanya melewatkan payload yang dapat digabungkan, sehingga menjadi semacam peredamnya sendiri dan "nyata" reduksi dapat dihilangkan.

Juga jika mereka sebodoh itu, mengapa harus memuat ulang untuk reduksi? Mereka hampir tidak akan pernah berubah.
Video demonstrasi oleh Dan, menunjukkan reduksi yang cukup bodoh, tetap saja dia mengubah jumlah kenaikan, yang membuatnya mengandung "logika bisnis", di tempat yang menurut saya seharusnya.

Ini adalah kasus penggunaan yang berbeda.

Untuk status yang "tinggal" di server, reduksi bodoh karena ada sedikit logika bisnis. Sebenarnya masuk akal untuk menghasilkan reduksi dari skema.

Untuk status yang "hidup" di klien (misalnya editor posting kompleks), logika bisnis dijelaskan dalam reduksi.

@lapanoid Dibandingkan dengan pemahaman saya, saya pikir Anda memiliki fakta yang bergeser satu lapisan ke arah pengguna.

pengiriman(createAction(STATUS_SYNC_DB)('sinkronisasi'));
pengiriman(buatAction(PROGRESS_SYNC_DB)(kemajuan))
pengiriman(createAction(STATUS_SYNC_DB)('selesai'));

Ini adalah fakta (tindakan sebagai objek) yang terjadi dalam logika AC Anda. Kumpulan fakta menggambarkan eksekusi logika di AC.

Pengguna mengklik di suatu tempat ("fakta") yang diinterprietasikan sebagai larik "instruksi". (fakta)=>(Daftar) - inilah yang sebenarnya dilakukan actionCreator sekarang.

Ketika pengguna mengklik, itu belum menjadi fakta secara default. Ketika dia mengklik dia mengeksekusi tindakan sebagai fungsi (ActionCreator) dan beberapa logika yang menghasilkan fakta (tindakan sebagai objek). Biasanya operasi sinkron diterjemahkan 1:1 ke tindakan sebagai fakta dan seluruh logika dilakukan dalam peredam. Async merusak ini dan memaksa kami untuk memindahkan semua kode async dengan semua ketergantungannya ke ActionCreators yang dapat mengakibatkan pemisahan logika bisnis buatan, terutama dalam kasus ketika logika perlu bergerak bolak-balik antara pembuat tindakan dan peredam.

Pereduksi berdasarkan fakta adalah model longgar. Reducer dapat melakukan apa pun yang masuk akal berdasarkan fakta. Mereka bisa pintar, mereka bisa bodoh (hanya mengurangi hasil AC ke status).

Anda dapat menggunakan tindakan sebagai objek untuk menggambarkan instruksi tetapi model pemikiran lain yang lebih digabungkan (tetapi dapat lebih disukai).

Saya akan baik-baik saja memiliki TINDAKAN SEBAGAI FUNGSI (ActionCreator) dan TINDAKAN SEBAGAI OBYEK.

@gaearon : setuju. Saya tidak bermaksud bahwa tidak ada tempat untuk reduksi bodoh, hanya saja saya tidak melihat bahwa semua harus bebas logika.

Objek tindakan saya (fakta) sombong, mereka tidak punya niat, mereka hanya mengatakan - "ini sudah selesai" dan Anda, peredam sayang, lakukan bisnis Anda. Saya tidak peduli. Saya tidak akan memberi tahu Anda apa yang harus Anda lakukan, itu urusan Anda. Objek tindakan saya mungkin peduli jika peredam dengan ramah meminta untuk menggambarkan dengan lebih baik apa yang terjadi tetapi umumnya dia ragu untuk mengubah (untuk mempertahankan jenis API yang ada).

Memiliki 100 reduksi mungkin lebih sulit untuk menemukan semua yang terjadi pada fakta tertentu. Itulah yang terjadi dengan semua pemrograman yang digerakkan oleh peristiwa dan arsitektur yang sangat terpisah.

@vladap

Ketika dia mengklik dia menjalankan tindakan sebagai fungsi (ActionCreator) dan beberapa logika yang menghasilkan fakta > (tindakan sebagai objek).

Ini adalah desain saat ini, tetapi saya pikir itu salah sebenarnya. Jika iterasi pengguna menghasilkan beberapa yang tidak dapat diubah secara default dan hanya kemudian AC akan dipicu oleh itu, kami dapat menguji eksekusi AC. Ini bisa dilakukan di inti secara transparan saya pikir, mendorong pengguna untuk melakukan tindakan tambahan pada setiap AC akan brutal.
Di dunia nyata ketika pengguna mengklik - engah - fakta terjadi. Bahkan jika redux tidak berpikir begitu.

Objek tindakan saya mungkin peduli jika peredam meminta untuk menjelaskan dengan lebih baik

Bagaimana itu bisa dilakukan?

@ioss

Juga jika mereka sebodoh itu, mengapa harus memuat ulang untuk reduksi?

AC juga hot-realoded - jadi ini bukan argumen

tetap saja dia mengubah jumlah kenaikan, yang membuatnya mengandung "logika bisnis", di tempat yang menurut saya seharusnya.

mereka menerima INCREMENT_COUNTER, mereka tidak membuat keputusan apa pun, hanya melakukan operasi. Jadi tidak ada logika bisnis di sini. Mereka adalah dump, tetapi Anda masih membutuhkannya bahkan dalam kasus sederhana seperti itu. Mereka tahu bagaimana mempertahankan status pada tindakan.

Saya pikir masalahnya adalah kata "Action" (dalam Action dan ActionCreator, dan AC sering digunakan sebagai penangan DomEvent).
Jika saya membaca Action, pikiran saya menghubungkannya dengan peristiwa dalam tampilan (atau peristiwa lain, seperti dari backend) dan saya selalu memiliki pikiran untuk mundur selangkah. Saya mungkin hanya perlu membiasakan diri, untuk memasukkannya ke alam bawah sadar saya. :)

Saat ini saya sedang berpikir untuk pergi: DomEvent -> ViewActionCreator (bagian "kiri" dari ActionCreator dengan VL) -> ViewAction/ExternalAction -> (opsional) middleware/toko dengan ViewActionHandler (bagian "kanan" dari ActionCreator dengan BL dan kemungkinan efek samping ) -> (Store)Action -> reduksi.
Dengan cara ini dimungkinkan untuk menghubungkan ViewActions ke StoreAction mereka, yang dapat memberi saya kesempatan untuk memutar ulang View/ExternalActions "secara visual" di devtool, tetapi menerapkan StoreActions ke status, tanpa memutar ulang efek samping.
Tidak yakin, hanya ide ...

Masalahnya adalah logika bisnis (BL) dalam kasus umum tidak sinkron, jadi AC adalah tempat yang lebih baik untuk itu. Menempatkan BL terkadang di AC dan terkadang di reduksi membingungkan (mungkin membingungkan hanya untuk saya tapi bagaimanapun = ))

Dalam hal gaya penamaan acara, menurut pendapat saya, gaya lampau bekerja paling baik untuk jenis peristiwa ChildView menengah ke ParentView yang sering Anda tulis saat membuat aplikasi Backbone, misalnya CLOSE_BUTTON_CLICKED atau DROPDOWN_CHANGED . Pengontrol semacam itu kemudian dapat mengabstraksikan peristiwa ini dari detail implementasi UI dan mengirimkannya kembali sebagai peristiwa domain aplikasi yang lebih umum/dapat digunakan kembali (atau Perintah) dalam suasana imperatif seperti CLOSE_MODAL atau SET_SELECTED_ITEM masing-masing. Di React/Redux kita melewatkan beberapa langkah tampilan untuk melihat ke komunikasi pengontrol dan mengirimkan tindakan domain aplikasi langsung dari komponen. Jadi saya menemukan diri saya memikirkan tindakan Redux sebagai agak analog dengan perintah yang dikirim ke bus acara global yang dapat diakses oleh setiap tampilan, itulah sebabnya saya merasa mood imperatif paling cocok dengan penamaan jenis tindakan.

Selain itu, transformasi dari peristiwa DOM menjadi tindakan domain aplikasi yang sering terjadi pada penangan klik atau perubahan ini secara implisit membocorkan beberapa logika bisnis ke dalam lapisan tampilan imo. Saya tidak yakin bagaimana perasaan saya tentang itu, tetapi selama itu secara alami terbatas pada komponen pintar/terhubung tampaknya OK karena mereka akan jauh lebih erat digabungkan ke lapisan status.

Kita tahu bahwa begitu suatu tindakan mengenai permukaan peredam, tindakan itu pasti bodoh, hanya dikompromikan dengan jenis dan muatan opsional. Saya merasa nyaman dengan pembuat tindakan dan middleware yang berisi logika bisnis, tetapi tampaknya membantu untuk menetapkan bahwa logika bisnis semacam itu hanya terkait dengan transformasi tindakan cerdas menjadi tindakan bodoh, tidak ada yang lain. Logika bisnis lain kemungkinan besar akan terjadi di server, atau sebagai alternatif peredam.

Fwiw saya akan mendukung nama ulang Actions to Commands karena secara konseptual tampaknya cukup cocok dengan pola perintah. Bagi saya, suatu tindakan memberi kesan bahwa _bagaimana_ operasi telah ditentukan sebelumnya yang tidak terlalu cocok dengan logika bisnis inti yang terjadi di tempat lain (server atau peredam). Kenyataannya di Redux semua yang telah kita lakukan adalah mengubah acara DOM menjadi salah satu jenis perintah domain aplikasi yang tersedia, menyediakannya dengan data yang diperlukan dan melupakannya ... dengan kata lain kita mengeluarkan perintah.

Jika ada sesuatu yang harus disebut "tindakan", itu akan menjadi deskripsi peristiwa yang terjadi ketika perintah bodoh mengenai peredam pada titik waktu tertentu. Jadi _actions_ yang kami putar ulang selama perjalanan waktu bukan perintah dan potensi efek sampingnya. Peredam _acts_ pada sebuah perintah, karenanya melakukan _action_ konkret, tetapi ini akan menjadi terminologi implementasi internal yang diabstraksikan dari pengguna perpustakaan, yang hanya perlu khawatir tentang mengeluarkan perintah ... yaitu bermaksud bahwa sesuatu _harus_ terjadi.

Dari Wikipedia tentang pola Perintah:

pola perintah adalah pola desain perilaku di mana suatu objek digunakan untuk merangkum semua informasi yang diperlukan untuk melakukan suatu tindakan atau memicu suatu peristiwa di lain waktu.

Bagaimanapun, maaf jika mengganti nama menjadi Perintah telah dibahas sebelumnya dan diputuskan, jangan ragu untuk mengabaikannya. Juga maaf jika saya mengambil di luar topik ini, jangan ragu untuk mengarahkan saya ke arah yang benar. Nilai saya hanya 2 sen :-)

Objek tindakan saya mungkin peduli jika peredam meminta untuk menjelaskan dengan lebih baik
Bagaimana itu bisa dilakukan?

Itu hanya metafora :) Mencoba menyampaikan bahwa objek tindakan harus dipikirkan dengan baik karena akan sulit untuk mengubahnya setelah ditentukan dan beberapa reduksi sudah terhubung dengannya.

@jedrichards haha, sekarang kami memiliki fakta, tindakan, instruksi, maksud dan perintah =) Lucu bagaimana orang melihat hal yang sama secara berbeda Saya melihat bahwa tindakan/perintah/fakta dump sebenarnya menjadi lebih pintar dalam beberapa cara sebagai tindakan/niat/instruksi menentukan apa harus terjadi berikutnya dan membawa beberapa info dalam diri mereka sendiri tentang hal itu. Dan BUTTON_CLICKED sebagai fakta tidak melakukan itu, jadi dumper. Sebuah fakta menginterpretasikan beberapa instruksi yang mungkin Anda katakan.

Mencoba menyampaikan bahwa objek tindakan harus dipikirkan dengan matang karena akan sulit untuk mengubahnya setelah ditentukan dan beberapa reduksi sudah terhubung dengannya.

Ya. Karena itu saya ingin kejelasan dengan tindakan, pendekatannya benar-benar memengaruhi seluruh aplikasi.

Masalahnya adalah logika bisnis (BL) dalam kasus umum tidak sinkron, jadi AC adalah tempat yang lebih baik untuk itu. Menempatkan BL terkadang di AC dan terkadang di reduksi membingungkan (mungkin membingungkan hanya untuk saya tapi bagaimanapun = ))

Ini adalah harga yang saat ini dibayar untuk menulis kode hot-reloadable.

AC juga hot-realoded - jadi ini bukan argumen

Jika mereka berisi kode async, mereka tidak dapat diputar ulang, Anda tidak dapat melakukannya secara deterministik. Redux DevTools mengabaikannya saat replay dan replay beroperasi pada hasil dari async AC - hanya pada objek tindakan => kode hot-replay hanya ada di reduksi.

@vladap Itu masuk akal, saya tidak tahu bahwa DevTools berperilaku seperti ini, terima kasih. Jadi mereka hanya dapat diputar ulang jika disinkronkan? Kemudian kami dapat menemukan BL selalu di AC mencoba membuatnya sinkron mungkin

Jadi mereka hanya dapat diputar ulang jika disinkronkan?

Ya, combineReducers default hanya mendukung kode sinkronisasi. Anda dapat menulis combineReducers Anda sendiri dan mengeksekusi beberapa kode async secara deterministik tetapi karena semua reduksi harus menyinkronkan hingga tindakan selanjutnya dieksekusi, perolehan bersihnya dipertanyakan - pemrosesan tindakan dan rendering digabungkan (tidak seperti fe di mesin game) maka eksekusi reduksi harus cepat untuk menghindari UI yang tidak responsif.

Lebih banyak kode yang Anda masukkan ke AC, lebih sedikit kode yang dapat Anda putar ulang/perjalanan waktu dan edit langsung, Anda akan berakhir dengan log debug sederhana - dalam kasus seperti itu Anda mungkin bisa bermutasi secara langsung dan alih-alih tindakan gunakan console.log(). Jika Anda mengubah kode AC dan menerapkannya ke tindakan yang disimpan, Anda tidak akan melihat efek dari perubahan Anda. Jika Anda mengubah kode peredam, tindakan tersimpan Anda akan diputar ulang secara berbeda -> Anda dapat mundur ke masa lalu, mengubah kode, dan memajukan waktu untuk melihat bagaimana penerapannya.

@vladap apa contoh jenis efek samping yang ingin Anda

Diberikan lapisan tampilan tanpa kewarganegaraan, saya hanya bisa memikirkan interaksi jaringan, dan
itu tidak menurut saya sebagai hal yang sangat aman untuk dilakukan…

Saya setuju dengan apa yang Anda tulis sebelumnya, ketika mengirim perintah ke server mereka
tidak sama dengan fakta yang kami kirim ke peredam tetapi kami menggabungkannya.
Realisasi yang bagus untuk #313!

Pada Senin, 3 Agustus 2015, 22:11 vladap [email protected] menulis:

Jadi mereka hanya dapat diputar ulang jika disinkronkan?

Ya, combineReducers default hanya mendukung kode sinkronisasi. Anda bisa menulis Anda
memiliki combineReducers dan mengeksekusi beberapa kode async secara deterministik tetapi
karena semua reduksi harus menyinkronkan hingga tindakan selanjutnya dijalankan
keuntungan bersihnya dipertanyakan - pemrosesan tindakan dan rendering digabungkan
(tidak seperti fe di mesin game) maka eksekusi reduksi harus cepat
untuk menghindari UI yang tidak responsif.

Lebih banyak kode yang Anda masukkan ke AC, lebih sedikit kode yang dapat Anda putar ulang/perjalanan waktu dan edit
hidup, Anda akan berakhir dengan log debug sederhana - dalam kasus seperti itu Anda bisa
mungkin hanya bermutasi secara langsung dan alih-alih tindakan gunakan console.log(). Jika
Anda mengubah kode AC dan menerapkannya ke tindakan tersimpan yang tidak akan Anda lihat efeknya
perubahan Anda. Jika Anda mengubah kode peredam, tindakan tersimpan Anda akan diputar ulang
berbeda -> Anda dapat mundur ke masa lalu, mengubah kode, dan memajukan waktu
untuk melihat bagaimana penerapannya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/gaearon/redux/issues/384#issuecomment -127393209.

Tidak.
(diketik di ponsel, maaf singkat)

@wmertens Saya tidak bermaksud memutar ulang efek samping, ini dibahas di #307.

@jedrichards Pola perintah secara eksplisit mendefinisikan perintah mana yang harus dijalankan, dengan kata lain perilaku yang tepat untuk dieksekusi. Ini adalah hubungan 1:1. Flux umumnya memiliki hubungan 1:M (banyak) antara Tindakan dan perilaku yang dieksekusi. Pola dengan relasi 1:M disebut pola Pengamat sepengetahuan saya.

Mengganti nama tindakan menjadi perintah tidak akan membantu memecahkan akar penyebab kebingungan (yaitu istilah yang digunakan vs. pola desain yang mereka sarankan secara default). Tindakan digunakan sebagai pengganti Perintah dalam beberapa implementasi pola Perintah. Dalam konteks kita, mereka praktis hal yang sama.

Ketika saya diberi tahu bahwa itu adalah pola Perintah, saya berharap satu sisi menentukan apa yang harus dieksekusi, memberikannya ke sisi lain yang secara membabi buta mengeksekusinya. Jika perintah turnOnRadio didefinisikan, akan aneh untuk menyalakan lampu.

Flux asli adalah pola Perintah yang kelebihan beban di mana objek tindakan mampu memicu lebih banyak dan mungkin perilaku yang tidak terkait, yang dapat membingungkan.

Atau itu adalah pola Perintah yang kelebihan beban di mana eksekusi satu perilaku dapat tersebar di lebih banyak toko. Jadi untuk menyalakan radio, satu toko harus mencolokkannya sementara toko lain akan menunggu sampai terpasang dan kemudian menyalakannya.

Atau itu adalah pola Pengamat dengan peristiwa yang secara aneh disebut sebagai objek tindakan, yang membingungkan. Daripada saya berharap bahwa satu sisi hanya menandakan sesuatu terjadi tanpa mengetahui apa yang akan terjadi selanjutnya. Jika satu sisi memberi sinyal bahwa radio dihidupkan maka sisi lain dapat menyalakan lampu jika diinginkan.

Dalam semua kasus itu bisa berarti bahwa beberapa logika sudah dieksekusi yang menghasilkan perintah atau peristiwa. Perintah vs. peristiwa hanya menentukan tingkat sambungan.

@wmertens Saya tidak bermaksud memutar ulang efek samping, ini dibahas di #307.

Tapi ya, tidak murni menggunakan janji di peredam yang berarti saya akan benar-benar memutar ulang efek samping.

@vladap bisakah Anda menguraikan kalimat terakhir Anda? Saya tidak mengerti.

@ioss : Lupakan, itu salah. Saya pikir, itu tidak bisa dilakukan hanya dengan combineReducers.

Seperti yang disebutkan vladap, saat ini tidak konsisten. Ini harus diperbaiki, lihat:

Satu-satunya cara untuk mengubah status adalah dengan memancarkan tindakan, objek yang menggambarkan apa yang terjadi. (Tiga Prinsip, Peredam)
Tindakan adalah objek polos yang mewakili niat untuk mengubah keadaan. (Aksi dalam Glosarium)

Sebuah lamaran:

Tindakan: Seperti yang telah disebutkan beberapa orang, suatu tindakan dipandang sebagai menyatakan _niat_ untuk melakukan sesuatu. Saat ini pembuat tindakan mengembalikan _intents_ niat dari pengguna tetapi entah bagaimana nanti _intents_ ini dilihat sebagai fakta.

Events: In Event Sourcing, peristiwa dilihat sebagai fakta yang terjadi di masa lalu. Sudah ada konsep toko acara (_not_ toko tindakan).

Acara alih-alih tindakan
Saya pikir pembuat aksi harus mengembalikan acara. Sebenarnya pembuat tindakan sudah menjadi _intents_. Dengan memanggil fungsi pembuat tindakan, tindakan tersebut dijalankan. Saat tindakan dijalankan, acara dapat dikirim, baik dengan mengembalikan atau mengembalikan fungsi panggilan balik.

Ini hanya penggantian nama yang sederhana tapi saya pikir itu akan membantu. Bagaimana menurutmu?

Anda dapat menulis combineReducers Anda sendiri dan mengeksekusi beberapa kode async secara deterministik, tetapi karena semua reduksi harus menyinkronkan hingga tindakan selanjutnya dieksekusi, perolehan bersihnya dipertanyakan - pemrosesan tindakan dan rendering digabungkan (tidak seperti fe di mesin game) maka eksekusi reduksi harus cepat untuk menghindari UI yang tidak responsif.

Pernyataan saya ini juga tidak masuk akal. Tindakan lain masih akan dilakukan. Saya tidak yakin mengapa saya pikir ada semacam langkah kunci seperti di game. Sebaiknya disadari karena beberapa eksekusi pembuat tindakan yang mengirimkan tindakan yang sama berpotensi menyebabkan kondisi balapan dan status yang tidak dapat diprediksi.

Saya pikir ini harus ditutup juga https://github.com/gaearon/redux/issues/377#issuecomment -127703551 untuk alasan yang sama @gaearon. (namun diskusi ini cukup mencerahkan, setidaknya bagi saya)

Yah, saya pikir hanya merekomendasikan sesuatu di dokumen sangat berbeda
dari refactoring API.
Saya pikir kami mencapai konsensus bahwa konstanta tindakan paling masuk akal di
bentuk lampau, dan perintah itu bisa menjadi keharusan tetapi harus diubah
untuk tindakan lampau oleh pembuat tindakan atau middleware.

Pada Selasa, 4 Agustus 2015, 21:25 Sergey Lapin [email protected] menulis:

Saya pikir ini harus ditutup serta #377 (komentar)
https://github.com/gaearon/redux/issues/377#issuecomment -127703551 untuk
alasan yang sama @gaearon https://github.com/gaearon. (namun ini
diskusi itu cukup mencerahkan, setidaknya bagi saya)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/gaearon/redux/issues/384#issuecomment -127728289.

Tidak.
(diketik di ponsel, maaf singkat)

Pada akhirnya kami mulai membahas hal yang sama - sifat tindakan yang baik karena semuanya terhubung. Dan saya tidak melihat konsensus di sini. Jika tindakan adalah niat, itu seharusnya tidak menjadi bentuk lampau dan jika itu adalah fakta, itu seharusnya. Tetapi tidak akan ada penggantian nama karena alasan dari #377

Tindakan sebenarnya digunakan dalam kedua cara sekarang, karena bisa menjadi keduanya. Seperti foton baik gelombang dan partikel itu tergantung pada perspektif.

ya tetapi pada saat mencapai toko, Intent telah runtuh
Fakta :-)

Pada Rabu, 5 Agustus 2015, 10:25 Sergey Lapin [email protected] menulis:

Actioin sebenarnya digunakan dalam kedua cara sekarang, karena bisa keduanya. Seperti foton adalah
baik gelombang dan partikel itu tergantung pada perspektif.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/gaearon/redux/issues/384#issuecomment -127912543.

Tidak.
(diketik di ponsel, maaf singkat)

Saya pasti tidak berpikir begitu.

Saya pikir Maksud umumnya dipahami sebagai maksud pengguna, mereka mewakili interaksi pengguna dengan UI. Maksud kemudian diterjemahkan ke peristiwa/fakta atau tindakan/perintah pola mana pun yang Anda putuskan untuk menjadi dasar sistem Anda. Saya lebih suka menghindari untuk menggunakan istilah Intent dalam konteks lain.

Niat pengguna dapat berupa showMeTop10Todos yang diterjemahkan ke TODOS_LOAD_BEGIN dan TODOS_LOAD_SUCCESS/FAILURE. Pengguna tidak peduli dengan salah satu dari mereka, itu adalah peristiwa/fakta internal atau tindakan/perintah. Pengguna memiliki niat dan umumnya peduli dengan hasil yang ditampilkan, dia tidak peduli apa yang harus dilakukan di antaranya.

Seperti yang @adri sebutkan, istilah umum dalam EventSourcing adalah Event atau DomainEvent. Event adalah istilah umum juga dalam pola Observer yang lebih tepat melihat TODOS_LOAD_BEGIN dan TODOS_LOAD_SUCCESS/FAILURE sebagai apa yang terjadi dan ketika ada relasi 1:M.

Istilah FACT digunakan dalam analisis OLAP yang digunakan untuk tabel fakta dalam skema bintang, bersama dengan tabel dimensi. Saya akan mengatakan bahwa Fakta adalah istilah yang lebih umum yang mewakili apa pun yang dianalisis, itu bisa berupa peristiwa, pengukuran .... Saya tidak sadar itu digunakan secara langsung dalam beberapa pola desain pemrograman, meskipun saya tidak tahu semuanya.

Niat pengguna satu tingkat lebih tinggi menurut saya. Maksud pengguna diubah menjadi ActionCreators di komponen React. Kita dapat mengambil maksud pengguna, mengambil status Redux.state saat ini dan/atau status lokal saat ini yang dipertahankan dalam komponen React dan memutuskan apakah kita benar-benar menjalankan ActionCreator atau tidak.

Alurnya adalah UserIntent (istilah virtual, diwakili oleh event handler DOM) > ActionCreator > Objek tindakan.

Mungkin harus ada Empat Prinsip dalam dokumen.

State is a result of an immutable past.

Hal ini kontroversial sebagaimana dibuktikan oleh diskusi ini. Kami tidak akan meresepkan skema penamaan tertentu dalam dokumentasi.

Kami juga telah membekukan terminologi sekarang, jadi kami tidak akan memperkenalkan "peristiwa", "fakta" atau yang lainnya.

Terima kasih kepada semua orang untuk berpartisipasi ;-). Penutupan sebagai tidak dapat ditindaklanjuti.

Saya setuju dengan @lapanoid bahwa ada sangat sedikit konsensus di utas ini.
Salah satu hal yang saya lewatkan adalah pendapat tentang pendekatan EventSourcing vs WAL, lihat https://github.com/rackt/redux/issues/384#issuecomment -127163050 dan https://github.com/rackt/redux/ issue/384#issuecomment -127272825.

Haruskah komponen pintar mengirimkan tindakan CLOSE_BUTTON_CLICKED (EventSourcing, Observer) atau CLOSE_MODAL (Pola perintah)?
(Saya tidak berbicara tentang bentuk lampau / naun / ... formulasi)

Secara pribadi saya suka poin @jedrichards bahwa komponen pintar dapat menerjemahkan acara menjadi tindakan domain aplikasi generik/dapat digunakan kembali. Saya pikir ini menciptakan pemisahan yang lebih baik antara ui dan logika bisnis. Ketika ada beberapa peristiwa yang menghasilkan tindakan yang sama, ini juga membatasi jumlah tindakan.

Saya pikir itu cukup jelas: ada hal-hal yang terjadi (pengamat
pola: pengguna mengklik tombol suka, server mengirim pesan obrolan baru), dan
hal-hal yang Anda inginkan terjadi (pola perintah: dapatkan detail pengguna dari
server, tampilkan pemberitahuan desktop) dan mereka melakukan perjalanan yang sama
pesan bus, panggilan pengiriman.

Namun.

Satu-satunya hal yang masuk akal untuk disimpan dalam keadaan adalah pengamatan,
karena perintah tidak memiliki pengaruh langsung pada keadaan. Perubahan yang diinginkan tidak
terjadi pada saat perintah mencapai reduksi, dan hasil dari
perintah mungkin akan menjadi pengamatan baru.

Paling-paling, perintah dapat menghasilkan pengamatan bahwa permintaan dibuat,
dan saya percaya akan lebih baik untuk membuatnya eksplisit dengan membiarkan
actioncreator atau middleware yang menjadi perantara pengiriman perintah itu
pengamatan.

Oleh karena itu, tindakan apa pun yang mengarah ke reduksi harus ditulis dalam
bentuk lampau. Hal lain yang terbaik adalah jalan pintas dan yang terburuk adalah sumber
kebingungan.

Pada hari Rabu, 19 Agustus 2015 pukul 18.25 Peter Uithoven [email protected]
menulis:

Saya setuju dengan @lapanoid https://github.com/lapanoid bahwa ada sangat
sedikit konsensus di thread ini.
Salah satu hal yang saya lewatkan adalah opini tentang EventSourcing vs WAL
pendekatan, lihat #384 (komentar)
https://github.com/rackt/redux/issues/384#issuecomment -127163050 dan #384
(komentar)
https://github.com/rackt/redux/issues/384#issuecomment -127272825.

Jika komponen pintar mengirimkan CLOSE_BUTTON_CLICKED (EventSourcing,
Pola pengamat) atau tindakan CLOSE_MODAL (Pola perintah)?
(Saya tidak berbicara tentang bentuk lampau / naun / ... formulasi)

Secara pribadi saya suka poin @jedrichards https://github.com/jedrichards
bahwa komponen pintar dapat menerjemahkan peristiwa ke dalam domain aplikasi generik/dapat digunakan kembali
tindakan. Saya pikir ini menciptakan pemisahan yang lebih baik antara ui dan bisnis
logika. Ketika ada beberapa peristiwa yang menghasilkan tindakan yang sama, ini
juga membatasi jumlah tindakan.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/rackt/redux/issues/384#issuecomment -132680145.

Tidak.
(diketik di ponsel, maaf singkat)

Adapun CLOSE_BUTTON_CLICKED vs CLOSE_MODAL, menurut saya tindakan sebenarnya yang
harus dikirim adalah MODAL_GOT_HIDDEN atau hanya MODAL_HIDDEN, dan
actionCreator bisa disebut hideModal().

Pada Rabu, 19 Agustus 2015 pukul 23.32 Wout Mertens wout. [email protected]
menulis:

Saya pikir itu cukup jelas: ada hal-hal yang terjadi (pengamat
pola: pengguna mengklik tombol suka, server mengirim pesan obrolan baru), dan
hal-hal yang Anda inginkan terjadi (pola perintah: dapatkan detail pengguna dari
server, tampilkan pemberitahuan desktop) dan mereka melakukan perjalanan yang sama
pesan bus, panggilan pengiriman.

Namun.

Satu-satunya hal yang masuk akal untuk disimpan dalam keadaan adalah pengamatan,
karena perintah tidak memiliki pengaruh langsung pada keadaan. Perubahan yang diinginkan tidak
terjadi pada saat perintah mencapai reduksi, dan hasil dari
perintah mungkin akan menjadi pengamatan baru.

Paling-paling, perintah dapat menghasilkan pengamatan bahwa permintaan itu
dibuat, dan saya percaya akan lebih baik untuk membuatnya eksplisit dengan membiarkan
actioncreator atau middleware yang menjadi perantara pengiriman perintah itu
pengamatan.

Oleh karena itu, tindakan apa pun yang mengarah ke reduksi harus ditulis dalam
bentuk lampau. Hal lain yang terbaik adalah jalan pintas dan yang terburuk adalah sumber
kebingungan.

Pada hari Rabu, 19 Agustus 2015 pukul 18.25 Peter Uithoven [email protected]
menulis:

Saya setuju dengan @lapanoid https://github.com/lapanoid bahwa ada sangat
sedikit konsensus di thread ini.
Salah satu hal yang saya lewatkan adalah opini tentang EventSourcing vs WAL
pendekatan, lihat #384 (komentar)
https://github.com/rackt/redux/issues/384#issuecomment -127163050 dan #384
(komentar)
https://github.com/rackt/redux/issues/384#issuecomment -127272825.

Jika komponen pintar mengirimkan CLOSE_BUTTON_CLICKED (EventSourcing,
Pola pengamat) atau tindakan CLOSE_MODAL (Pola perintah)?
(Saya tidak berbicara tentang bentuk lampau / naun / ... formulasi)

Secara pribadi saya suka poin @jedrichards https://github.com/jedrichards
bahwa komponen pintar dapat menerjemahkan peristiwa ke dalam domain aplikasi generik/dapat digunakan kembali
tindakan. Saya pikir ini menciptakan pemisahan yang lebih baik antara ui dan bisnis
logika. Ketika ada beberapa peristiwa yang menghasilkan tindakan yang sama, ini
juga membatasi jumlah tindakan.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/rackt/redux/issues/384#issuecomment -132680145.

Tidak.
(diketik di ponsel, maaf singkat)

Tidak.
(diketik di ponsel, maaf singkat)

Bagi saya ide terbaik dari utas ini adalah kata benda tindakan panggilan tanpa tegang seperti ITEM_CREATION Saya benar-benar baik-baik saja ini. Saya pikir tegang itu sendiri adalah sumber kebingungan.

Saya pikir tegang itu sendiri adalah sumber kebingungan.

Saya akan lebih umum dan mengatakan bahwa sumber utama kebingungan adalah penerapan model mental yang saling bertentangan.

Ini benar-benar masalah perspektif; Saya dapat berdebat untuk past tense dengan mudah karena model mental yang paling nyaman bagi saya adalah Event Sourcing, tetapi saya juga telah memahami perspektif dari saran lainnya. Saya pikir kita harus menahan diri untuk tidak memaksakan sikap tegas dalam hal ini karena kita harus memahami bahwa orang-orang dari latar belakang yang berbeda akan mendapat manfaat dari penjelasan berbeda yang sesuai dengan model mental alami mereka. Memilih satu saran di atas yang lain berarti mempersulit beberapa orang bahkan jika lebih mudah bagi yang lain. Untuk membiarkan ini di udara "secara resmi", tetapi untuk menyesuaikan penjelasan tindakan kepada audiens tertentu dari posting blog, tweet, atau podcast akan melayani semua orang secara lebih langsung, saya pikir.