Redux: Proposal: Ganti nama "toko" menjadi "pereduksi"

Dibuat pada 18 Jun 2015  ·  54Komentar  ·  Sumber: reduxjs/redux

Jika saya ingat dengan benar, @gaearon , Anda mengatakan kami akan membuat perubahan ini setelah Redux mencapai 500 bintang. :)

Akan menyenangkan juga untuk memiliki bagian "Terminologi" pada dokumen sehingga kami dapat membuat semua orang tetap pada jalurnya. Saya terutama memperhatikan bahwa saat ini kita menggunakan kata "dispatcher" untuk merujuk pada _setidaknya_ tiga hal yang berbeda.

discussion docs

Semua 54 komentar

-1 kurva belajar pada repo ini sudah terasa curam. Mari kita tidak membuatnya lebih curam dengan memperkenalkan terminologi baru untuk pengguna fluks baru.

Secara internal mereka bisa disebut reduksi, simpan secara publik sebagai toko sehingga lebih mudah untuk grok.

Sejujurnya saya pikir itu lebih membingungkan seperti sekarang. Benar-benar anekdot, tetapi saya memiliki beberapa orang yang membuat IRL bingung memikirkan bagaimana "toko" bisa tidak memiliki kewarganegaraan.

Karakteristik utama "toko" di Flux tradisional adalah bahwa mereka 1) menahan status, dan 2) memancarkan peristiwa perubahan. Tak satu pun dari yang benar di Redux.

Saya setuju kita perlu mengklarifikasi terminologi, dan dalam beberapa kasus menemukan penamaan yang lebih baik.
Saya pikir sebagai langkah pertama harus ada beberapa JSDoc, maka bagian terminologi juga akan membantu.
Secara umum kami harus mempertahankan tingkat konsistensi tertentu.

Saya ingin tahu apakah ada istilah yang tidak terdengar seperti FP tapi juga bukan "toko".
Domain?

OTOH itu sudah disebut Redux jadi setidaknya "peredam" terdengar terkait.

Bagaimana dengan "pembaruan langkah", atau "langkah", yang membuat status Anda selangkah lebih maju. Saya telah melihat ini digunakan dalam literatur Elm, memiliki fungsi yang disebut step , update , atau next

Domain berisi bagasi node.js.

Mereka tidak menyimpan bagaimana fungsinya tetapi Anda masih menempatkan logika status Anda di sana seperti halnya toko fluks. Mereka adalah manajer negara bagian, seperti toko fluks yang seharusnya.

Reducer baik-baik saja jika Anda ingin mengubah namanya.

Terutama karena "peredam" adalah deskripsi yang tepat tentang apa sebenarnya mereka :)

Pembaru? Kedengarannya deskriptif + kurang sombong daripada reduksi.

Saya suka reducer juga

Saya kira saya tidak mengerti mengapa "peredam" itu sombong. Bukankah lebih baik menggunakan istilah yang sebenarnya daripada menciptakan istilah baru yang kurang deskriptif?

Saya kira keduanya mungkin valid, dan itu tergantung dari sudut pandang mana Anda melihatnya: _reducer_ tindakan (menjadi state), atau _updater_ state.

"Pembaru" menyiratkan bahwa itu mutatif. "Reducer" memperjelas bahwa Anda mengembalikan status baru, bukan mengubah yang lama.

Itu poin yang kuat menurut saya, dapat membantu dengan masalah tentang redux yang tidak berfungsi dengan benar dengan mutasi

Saya menghargai kebutuhan untuk menjaga Redux tetap ramah kepada orang-orang yang tidak terbiasa dengan FP, tetapi kami dapat menyelesaikannya dengan dokumentasi yang lebih baik. Saya suka dokumen saat ini, tetapi pada pandangan pertama mereka agak berlebihan. Situs dokumen bagus yang mengedepankan hal-hal yang sudah dikenal (pembuat tindakan, logika peredam) di atas hal-hal canggih (middleware, hot reload) akan sangat membantu.

Namun, dilihat dari pesatnya pertumbuhan berikut di sini, kita harus melakukan sesuatu yang benar :)

Saya terbuka untuk mengubah "Toko" menjadi "Pengurang" jika ini terjadi bersamaan dengan dokumen yang lebih baik.

Elemen penting adalah untuk mempertahankan getaran "itu seperti Flux tapi lebih baik, jangan khawatir". Saya tidak ingin orang berpikir itu mirip dengan Reflux atau semacamnya, yang terdengar seperti Flux tetapi merusak beberapa properti bagusnya. Saya juga tidak ingin mereka berpikir bahwa mereka perlu belajar FP. Selama kita bisa mempertahankannya, aku baik-baik saja dengan perubahan ini.

Saran Saya kurang yakin tentang: Jika kita mengganti nama kelas Redux menjadi Store (pikirkan: dua tujuannya adalah untuk menahan status dan memancarkan peristiwa perubahan) maka API tingkat atas menjadi:

const store = createStore(reducers);

<Provider store={store} />

Ini mengkomunikasikan ide dengan cukup baik, saya pikir. Pereduksi adalah tempat logika toko Anda berjalan, tetapi mereka tidak menyimpannya sendiri.

Saya suka ini meskipun store.dispatch terasa salah.

Ya itu satu hal yang saya tidak terlalu suka, tetapi metode lainnya masuk akal: store.getState() , store.setState() , store.subscribe()

Sekarang saya memikirkannya, kami tidak benar-benar "mengirim" apa pun.
Ugh, penamaan adalah lubang kelinci.

Ok, jadi apa yang kita miliki sejauh ini adalah:

  • tindakan (pencipta)
  • (toko) peredam
  • fungsi middleware
  • fungsi panggilan balik (pendengar)
  • sesuatu yang memicu rantai panggilan fungsi (disebut operator)
  • sesuatu yang memegang status yang bisa berubah (dengan setter dan getter)

Mungkin kita bisa mengambil langkah mundur dan memikirkan kembali penamaannya?

Mungkin store.dispatch tidak terlalu buruk. Kami hanya dapat menjelaskan bahwa alih-alih banyak Toko, kami memiliki satu Toko, dan Anda menyusunnya dari Reducers. Tidak Ada Toko = Tidak perlu Dispatcher terpisah, jadi dispatch tersedia langsung di Toko.

@gaearon saya setuju.

@emmenko Ringkasan yang bagus. Setiap perincian terminologi harus membedakan antara _pembuat tindakan_ dan _tindakan_. Ini juga harus membedakan antara _dispatcher_ atau _strategi pengiriman_, yang mencakup middleware + reduksi, serta metode _dispatch_ yang memicu _siklus pengiriman_.

Mari kita lakukan:

Adakah yang ingin memimpin upaya dokumen baru? Ini akan membutuhkan beberapa penataan: glosarium, README, tutorial sederhana “menjalankan”, dan mungkin panduan “keputusan desain” yang lebih mendalam.

@gaearon Saya akan menjadi sukarelawan untuk memimpin ini :) Saya sudah memiliki garis besar yang sudah dimulai.

Terima kasih :+1:

Saya akan menjadi sukarelawan untuk memimpin ini

Terima kasih! :+1: :+1: :+1:

Secara pribadi, sebagai hasil akhir, saya sangat ingin memiliki situs web yang dibuat secara otomatis dengan:

  • mulai
  • tutorial
  • contoh hidup

...dan sebagai fitur yang bagus untuk dimiliki:

  • dokumentasi yang dihasilkan a-la docco (misalnya: seperti jasmine ) sehingga kode sumber dijelaskan dengan jelas

Tetapi memulai dengan penurunan harga dan jsdoc tentu saja merupakan langkah pertama;)

Benar, saya pikir langkah pertama adalah mendapatkan dokumen yang ditulis dalam bentuk penurunan harga, kemudian kita dapat memindahkannya ke situs dokumen yang sangat bagus. :+1: untuk JSDoc juga. Saya akan mengambil satu tikaman terakhir di https://github.com/gaearon/redux/pull/87 malam ini tapi saya tidak yakin anotasi Flow sepadan pada saat ini kecuali kita menghilangkan basis kode dari fungsi yang berlebihan. (Atau kecuali seseorang mengajari saya cara mengetiknya dengan benar tanpa Flow mengeluh.)

Saya kira Flow bukan atm prioritas.

+1 untuk toko yang disebut reduksi.

Saya tidak suka menyebut toko barang-barang yang lebih deklaratif dan tanpa kewarganegaraan ini.

Saya suka ide nama baru. Saya juga mengusulkan penggantian nama Connector menjadi sesuatu seperti Subscription . Connector sangat umum, dan sementara saya mengerti bahwa itu menghubungkan status redux dan operator ke anak-anaknya, saya pikir berlangganan adalah deskripsi yang lebih baik tentang apa yang terjadi. Agak sulit Anda mendapatkan petugas operator bersama dengan langganan Anda, tapi saya pikir tidak apa-apa.

-1 untuk toko yang disebut reduksi, sebagai nama itu tidak terlalu intuitif untuk pengguna baru (setidaknya mereka yang tidak memiliki latar belakang pemrograman fungsional). Mungkin Updater atau Transformer akan lebih baik, atau Store Updater jika kita ingin lebih eksplisit tentang hal itu.

"Transformer" telah disarankan beberapa kali. Itu tidak menyarankan sifat yang bisa berubah seperti Pembaru, lebih mudah didekati daripada Pereduksi, dan tidak membawa konotasi "penyimpanan" dari Toko.

Bagaimana Anda menyukai Transformer?

+1 untuk Reducer

Seperti yang dicatat oleh @faassen di Twitter, argumen yang bagus untuk "pengurang" adalah memanggil kembali nama proyek. Kami memiliki kesempatan untuk mengatakan “Ini seperti Flux, tetapi ada satu Toko. Sama seperti Anda dapat menyusun aplikasi Anda ke dalam komponen React, di Redux, Anda membuat Store dari Reducers. Mereka disebut Reducer karena fungsi pencocokan tanda tangannya diteruskan ke [].reduce() : (state, action) => state . bla bla bla”

penyebaran sudut seperti api dan menggunakan kata-kata seperti

  • pengarahan
  • memisahkan
  • transklusi

Mengabaikan pemrograman, mengubah dan mengurangi adalah hal yang berbeda. Saya akan memilih nama yang paling akurat.

Jika mereka tidak menyimpan data, jangan sebut mereka toko.

Apakah Anda mengubah dari satu bentuk ke bentuk lain atau Anda mengurangi dari banyak nilai menjadi satu?

Transformator => peta
Peredam => kurangi

Kedengarannya seperti mengurangi bagi saya.

Saya untuk reducers juga! :+1:

Ambil inspirasi dari Elm. https://github.com/evancz/elm-architecture-tutorial#the -basic-pattern

Kata terbaiknya adalah update . Toko adalah omong kosong, selalu "Model". Tidak perlu menemukan kembali roda atau membingungkan orang.

Daging sapi saya dengan menyebut mereka pembaru adalah orang mungkin berpikir mereka seharusnya mutatif. Jika penamaan dapat membantu memperjelas sifat non-mutatif itu akan menjadi bonus besar.

Apakah Anda mengubah dari satu bentuk ke bentuk lain atau Anda mengurangi dari banyak nilai menjadi satu?

Aku mengumpulkan. “Bagaimana suatu tindakan mengubah suatu keadaan menjadi keadaan berikutnya.” Secara konseptual mereka mengurangi banyak tindakan dari keadaan awal (tidak terdefinisi), dan memoisasi hanyalah pengoptimalan.

Transformator Negara

Cobalah untuk menghindari penemuan kembali/penemuan kembali sebanyak mungkin. Orang-orang menyebutnya reduce , scan , fold , dan update .

reducer tampaknya akurat dari perspektif javascript...
Jangan melihat nilai untuk menamakannya dari konsep bahasa lain, bahkan jika itu lebih akurat.

Tidak memiliki pendirian yang kuat tentang apa yang seharusnya tetapi IMO itu harus menjadi sesuatu yang paling akurat mewakili jenis perhitungan. Jika itu adalah kata umum bagi sebagian besar programmer maka itu dapat diimbangi dengan dokumentasi.

@vramana ini bukan map , ini adalah reduce , karena dibutuhkan akumulasi sebelumnya state dan action dan mengembalikan state .

Jika Anda memiliki larik semua tindakan aplikasi, Anda akan menggunakan fungsi ini untuk menguranginya ke status aplikasi akhir:

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

Sekarang, yang sebenarnya Anda miliki adalah stream dari actions dalam waktu, yang secara konseptual sama dengan array, tetapi pada waktunya (Anda dapat menguranginya menjadi stream dari state s).

Saya suka menganggapnya sebagai proyeksi (dari log peristiwa ke struktur data).
Orang-orang DB biasa menyebut ini "pandangan terwujud".

Saya suka mengurangi atau melipat, itu dipahami dengan baik oleh komunitas yang berbeda

Saya lebih suka Transformers daripada Reducers: jelas apa artinya dari penggunaan kata bahasa Inggris yang normal.

Pereduksi.
Pertama, perpustakaan javascript dan javascript memiliki [].reduce(reducer, initialState) .
Kedua, Redu(cer)x sudah dalam nama perpustakaan.
Ketiga, https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ , orang lain dan perpustakaan akan menggunakan istilah 'pereduksi'.

Reducer akurat dan memiliki preseden di Vanilla JS. Tidak yakin bagaimana itu bisa diperbaiki.

Pengurang itu akan kemudian.

(Ikuti kemajuan di #140)

Kadang-kadang saya menemukan diskusi lama yang menyebut mereka "toko" dan mengagumi betapa membingungkannya hal itu di belakang.

"wadah negara"?

Ya ini adalah perubahan yang baik :)

Apakah halaman ini membantu?
0 / 5 - 0 peringkat