Redux: Seri screencast Redux di Egghead

:+1:

1. Status komponen lokal vs. status global
2. Tindakan ditangani oleh banyak reduksi vs. hubungan reduksi tindakan 1-ke-1
3. Menangani rantai tindakan (terutama yang asinkron), ketika tindakan kedua harus dipicu tepat setelah yang pertama selesai.
4. Teknik optimasi untuk mencegah rerenering yang tidak perlu (aksi batch, pemilihan ulang, dll.).

:+1:

Saya baru saja menonton 16 episode pertama dalam seri dan berpikir mereka adalah sumber yang bagus yang kemungkinan besar akan kami gunakan untuk pelatihan internal di perusahaan tempat saya bekerja. Namun, fakta bahwa Anda hanya pernah menggunakan objek biasa dan deep-freeze untuk state-tree Anda, dan tidak pernah menggunakan atau merujuk ke perpustakaan yang tidak dapat diubah seperti immutable-js membuat saya bertanya-tanya apakah Anda mendorong orang ke jalur ini, atau apakah ini hanya membuat presentasi ide lebih mudah?

Akan sangat bagus untuk mengetahui pemikiran Anda tentang ini.

Melempar Immutable ke dalam campuran akan membingungkan pemula yang perlu belajar membedakan antara Redux dan Immutable API, mungkin menganggap Immutable diperlukan, dll. Namun, ini adalah ide yang bagus untuk beberapa pelajaran lanjutan!

Melempar Immutable ke dalam campuran akan membingungkan pemula yang perlu belajar membedakan antara Redux dan Immutable API, mungkin menganggap Immutable diperlukan, dll. Namun, ini adalah ide yang bagus untuk beberapa pelajaran lanjutan!

Oke, masuk akal. Senang mengetahui pemikiran Anda di balik keputusan ini :-).

Apa yang dikatakan @smashercosmo :+1:

Pengujian satuan. TDD.

Apa yang @cateland katakan :+1:

Saya harus mengatakan saya sangat terkesan dengan keahlian Anda, mampu membuat perpustakaan js yang sangat baik dengan dokumentasi yang luas dan tutorial singkat dengan cara ini.

Setelah melihat semua video, saya memiliki banyak umpan balik tentang video tertentu yang akan saya kirim melalui surat. Kesimpulannya adalah bahwa ini lebih dari sekadar pengenalan Redux. Anda membahas praktik kode dan arsitektur komponen dan banyak lagi. Ini benar-benar luar biasa dan sangat pedagogis. Saya pikir video dapat dibagi menjadi tiga kelompok sekalipun. Redux basic, redux di belakang layar, dan redux dengan reaksi.

Untuk video yang akan datang, saya ingin melihat konsep spesifik yang lebih sedikit bereaksi dan lebih banyak lagi tentang tindakan dan pengujian asinkron.

Luar biasa bagus, pertahankan! :)

Dalam video 21 Anda perhatikan bahwa komponen TodoApp tidak lagi perlu menjadi kelas, itu bisa menjadi fungsi. Akan sangat bagus jika Anda dapat menjelaskan bagaimana Anda sampai pada realisasi ini -- mengapa ini merupakan kandidat yang cocok untuk menjadi komponen fungsional, dan manfaat apa yang diberikannya?

Ini sangat bagus.

Item 3 dalam daftar @smashercosmo adalah sesuatu yang ingin saya ketahui juga.

apa yang @wpannell katakan! Pengujian Unit/TDD!

Juga ingin melihat video tentang topik yang tercakup dalam dokumen Lanjutan.

Apa yang secara khusus Anda minati sehubungan dengan pengujian unit?
Pelajaran 5, 11, 12 memberikan gambaran tentang bagaimana menguji unit reduksi.

...itu pertanyaan yang bagus. Apakah prosesnya akan sangat berubah ketika mereka melakukan tes moka?

Tidak juga. Tapi saya rasa itu topik yang bagus untuk serangkaian pelajaran lanjutan. Pengurang pengujian unit, pembuat tindakan, komponen, dll.

Pertama, video yang bagus. Sudah mengerti redux tapi itu menyegarkan.
Jika Anda membuat video yang lebih canggih, bolehkah saya menyarankan tindakan asinkron / middleware.
Jangan berpikir pengujian unit benar-benar membutuhkan cakupan apa pun. Anda bisa memanggil fungsi peredam Anda dan menegaskannya?

Ya, saya kira itu tidak lebih dari membungkus expect s dalam tes moka. :jempolan:

Syukurlah semuanya sangat sederhana!

Kekekalan dengan hash ID objek (misalnya [post._id]: {...post} ).

Saya mendapati diri saya terlalu bergantung pada fungsi reduce untuk mengambil larik entitas API dan menghasilkan hash ID dengannya. Saya tahu bahwa normalizr akan menangani beberapa hal ini, tetapi saya ingin video yang mirip dengan video EggheadIO di mana Anda membawa kami dari titik A ke B. Ini bukan semata-mata hal berbasis Redux, tetapi sangat terkait.

@raquelxmoss

Dalam video 21 Anda perhatikan bahwa komponen TodoApp tidak lagi perlu menjadi kelas, itu bisa menjadi fungsi. Akan sangat bagus jika Anda dapat menjelaskan bagaimana Anda sampai pada realisasi ini -- mengapa ini merupakan kandidat yang cocok untuk menjadi komponen fungsional, dan manfaat apa yang diberikannya?

Itu sebenarnya adalah perencanaan pelajaran yang ceroboh di pihak saya. Saya tidak menyadari sampai terlambat bahwa saya bisa membuatnya menjadi komponen fungsional dari awal. Manfaat menggunakan fungsi di atas kelas adalah kesederhanaan, jadi lakukan ini kapan saja Anda bisa. Pada dasarnya jika Anda tidak memerlukan kait siklus hidup seperti componentDidMount atau status, gunakan komponen fungsional.

Saya akan menemukan pelajaran tentang bagaimana kita dapat membagi potongan-potongan kode ini menjadi struktur direktori yang sebenarnya untuk membantu. Saya tahu bahwa selama semuanya ada, itu mungkin akan berfungsi tetapi mungkin konvensi penamaan folder yang direkomendasikan (komponen / wadah / toko / peredam dll), jenis file apa yang masuk ke folder mana, dan seterusnya akan menyenangkan.

Saya juga ingin komposisi peredam tingkat lanjut.

Menggunakan kembali komponen kompleks (yang terdiri dari peredam atau beberapa reduksi, serangkaian tindakan, pembuat tindakan, mungkin mengakses beberapa API sisi server, beberapa komponen Bereaksi -- seperti bentuk redux, tetapi lebih spesifik untuk aplikasi nyata). Ini juga termasuk mengatur struktur direktori modular.

Nonton semuanya, bagus banget! Saya menghargai penggunaan sintaks ES6/7 ( Object.assign -like), Bereaksi komponen fungsi 0,14 dan menghindari hal-hal yang tidak dapat diubah.

Mungkin video yang menjelaskan arsitektur kode yang direkomendasikan.

Dan memperbarui dokumen untuk menggunakan sintaks ES6/7? (apakah PR diterima ke arah itu?)

Pengujian unit, membuat API Middleware, melakukan OAuth/beberapa jenis otentikasi pengguna dengan Redux, menggunakan Immutable dengan redux (cara menyiapkannya, praktik terbaik, dll.)

Seri ini berfungsi sebagai pengantar yang bagus untuk Redux, keadaan atom tunggal, dan filosofi terkait. Saya pikir Anda melakukan pekerjaan yang baik dengan menerapkan prinsip-prinsip inti sambil menghindari menginduksi kelebihan kognitif. Lingkungan tempat Anda bekerja juga mudah ditiru, yang membuat bagian langsung menjadi lebih mudah didekati.

@gaearon Apa pendapat Anda tentang tindakan penataan dalam contoh video sebagai standar wannabe { type: string, payload: Object } sejak awal? Saya berbicara tentang contoh daftar penghitung, di mana muatan diletakkan ke objek tindakan itu sendiri; { type: string, index: number } . Ini terlihat seperti anti-pola bagi saya.

Apa pendapat Anda tentang tindakan penataan dalam video contoh sebagai standar wannabe { type: string, payload: Object } sejak awal? Saya berbicara tentang contoh daftar penghitung, di mana muatan diletakkan ke objek tindakan itu sendiri; { jenis: string, indeks: angka }. Ini terlihat seperti anti-pola bagi saya.

Ini bukan anti-pola dengan cara apa pun. Ini adalah objek tindakan normal. FSA baik-baik saja tetapi ini adalah _convention_. Tidak ada di Redux itu sendiri yang bergantung pada atau diuntungkan dari konvensi ini, jadi kami tidak ingin memaksakannya.

Orang-orang dulu memikirkan segala macam hal ajaib tentang payload , source dalam dokumentasi Flux asli. Mereka membabi buta menyalin hal-hal ini tanpa memahami mengapa mereka ada dan dengan hati-hati menilai apakah mereka membutuhkannya. Kemudian mereka mengeluh tentang Flux yang rumit dan bertele-tele, padahal sebenarnya dalam banyak kasus mereka menyalin sendiri bagian verbose (tetapi tidak penting).

Dalam pelajaran ini saya hanya mengajarkan bagian-bagian penting dari Redux. Perhatikan bagaimana saya tidak memperkenalkan konstanta—karena orang terlalu berkonsentrasi pada konstanta, dan lupa bahwa konstanta tidak terlalu penting. Anda akan lebih memahami manfaat konstanta setelah Anda membuat beberapa kesalahan ketik dalam string, daripada jika saya memasukkannya ke dalam video tutorial dari awal. Saya pikir hal yang sama berlaku untuk konvensi lain seperti FSA — tentu saja, gunakan jika Anda merasa nyaman, tetapi saya tidak akan mengkhotbahkannya jika pelajaran tidak menuntutnya.

@gaearon Oke, saya bersama Anda, dengan harapan bahwa mereka yang terbiasa dengan pendekatan sederhana yang tidak terstruktur tidak akan membuat aplikasi yang lebih besar tidak dapat dikelola dengan tidak menerapkan konvensi apa pun.

@sompilasar

Saya pikir contoh menampilkan konvensi lebih baik daripada tutorial video. Contohnya adalah pendapat tentang "inilah cara saya menyusun beberapa kode di sekitar prinsip-prinsip itu", dan video tentang prinsip-prinsip itu sendiri. Inilah sebabnya mengapa Anda akan melihat konvensi yang berbeda dalam contoh yang berbeda, dan sebelum memulai sebuah proyek, kebanyakan orang melihat melalui contoh yang berbeda untuk mengetahui cara yang berbeda untuk melakukannya.

Juga, sama sekali tidak ada yang tidak terstruktur tentang tidak mengikuti FSA. { type: 'STUFF', id: 1 } dasarnya tidak lebih buruk dari { type: 'STUFF', payload: { id: 1 } } . Ini hanya masalah selera dan (terkadang) konvensi perkakas. Menjaga objek tindakan payload lebih sedikit tidak membuatnya lebih sulit untuk dikerjakan.

Kami memiliki beberapa pelajaran pengujian unit redux yang akan segera dirilis

Kami menunda pelajaran Redux APAPUN selama beberapa waktu agar Dan mendapatkan crack pertama. Benar-benar sepadan dengan menunggu, dan kemudian beberapa.

"Membangun Aplikasi dengan Idiomatic Redux" akan menjadi kursus lanjutan yang luar biasa 👍

@joelhooks keduanya terdengar luar biasa!

Saya ingin melihat Anda menyiapkan proyek menggunakan webpack dan memuat ulang panas alih-alih menggunakan jsbin. Bawa ini ke dunia nyata. Saya tahu ini tidak spesifik untuk redux tetapi saya pikir itu akan cocok dan Anda adalah orang yang tepat untuk mengajarkan ini :)

@kevinrenskers itu bukan seri video, tetapi jika Anda merasa seperti membedah sesuatu, ada yang beberapa benar-benar hebat contoh boilerplates Anda dapat referensi!

Mereka yang telah meminta struktur proyek untuk contoh Dan dan konfigurasi Webpack.

Silakan periksa ini https://github.com/urbanvikingr/todo.

Saya telah berkomitmen untuk memperbarui Redux dengan React doc agar selaras dengan kode Dan dari video. Itu akan selesai dalam dua minggu ke depan - proyek Liburan saya :) - tetap disini.

Daftar keinginan saya untuk video Egghead.io:
pengujian aksi / peredam dengan Jasmine
menyelami middleware (thunk / janji)

Screencast adalah pengantar yang sangat berguna untuk Redux. Yang ingin saya dengar adalah cara Redux untuk melakukan perutean dan rendering sisi server

@grigio Anda mungkin tertarik dengan diskusi ini https://github.com/rackt/redux/issues/1145 tentang perutean

@urbanvikingr terima kasih, telah berlangganan. Jajak pendapat tampaknya ditutup, tetapi saya akan memilih #1168

Pelajarannya sebenarnya cukup bagus, tetapi mengganggu bahwa ketika Anda mengatakan "simpan", itu terdengar seperti "tugas".

Semua orang di sini telah memperhatikan dan terganggu olehnya. Mereka terlalu benar secara politis untuk mengangkatnya. Jadi ya, saya memutuskan untuk menjadi pria _itu_, kalau-kalau tidak ada orang lain yang mau :)

Saya akan menjadi lebih baik dalam berbicara bahasa Inggris pada akhirnya. Untuk saat ini ini adalah yang terbaik yang bisa saya lakukan ;-)

@gaearon Anda telah melakukan pekerjaan yang sangat baik dalam menjelaskan Redux. Kudos untuk Anda dan pencapaian open source Anda.

Kumpulan pelajaran yang luar biasa. Saya terutama menyukai bagaimana Anda mengimplementasikan kembali setiap fungsi inti Redux dari awal dengan cara "baca sumbernya". Memperbantukan orang lain yang terkesan dengan betapa jelas tutorial dan semua dokumentasi untuk Redux. Sejauh ini, sebagai seseorang yang mengejar dua tahun kemajuan frontend, konsepnya sulit untuk membungkus pikiran saya, tetapi dokumennya sangat membantu dalam melakukannya. Pertahankan, dan terima kasih!

(Juga jangan dengarkan @jugimaster , tidak semua orang terganggu oleh aksen Anda dan "terlalu benar secara politis untuk mengangkatnya", atau bahkan peduli bahwa Anda memiliki aksen.)

@ianstormtaylor
Omong-omong, itu bukan aksen :)

Saya juga tidak "peduli", tetapi saya benar-benar terganggu!

Tetapi di sisi lain, sebagai seseorang yang mempelajari enam bahasa asing, saya _selalu_ peduli tentang berbicara bahasa dengan benar, dan untuk itu, saya pribadi menghargai seseorang yang menunjukkan kesalahan saya.

Hai @gaearon ,

Benar-benar menyukai kursus Anda. Kerja bagus! Itu sangat membantu.

Saya menambahkan tiga pelajaran video pengujian Redux ke kursus Egghead saya baru-baru ini:
https://egghead.io/series/react-testing-cookbook

Harapan saya adalah mereka akan memuji semua pekerjaan luar biasa yang telah Anda lakukan!

Tentu saja!

Meningkatkan tidak hanya pengetahuan Redux tetapi juga pengetahuan praktik modern secara keseluruhan! Teruslah melakukan hal-hal yang baik :+1: :tada:

hei, baru sadar tidak ada tautan/referensi ke kode di video. Mungkin jelas, dan mungkin, pengguna yang cukup sederhana dapat menyalin video; tapi saya pikir banyak orang bisa mendapatkan keuntungan dari repo dengan kode yang tepat di video- mengapa tidak?

Cuplikan kode untuk setiap pelajaran tersedia bagi pelanggan Egghead. :-)
Videonya gratis tetapi platform harus menghasilkan uang sehingga dapat berinvestasi ke lebih banyak kursus, mengirim peralatan ke instruktur, menghosting video, meningkatkan situs web, dan sebagainya.

Yang mengatakan kami memiliki folder examples/todos yang cukup cocok dengan kursus.

... keren, saya melewatkannya? Mencari link...

@gaearon minta maaf, baru saja mengunjungi kembali videonya. kodenya ada di sana :)... menonton video, membeli keanggotaan, menonton yang lain ... baru saja kembali ke video redux yang benar-benar masuk. bersorak.

Omong-omong, beberapa orang mengeluh bahwa transkrip tidak akurat.
Silakan kirim PR untuk memperbaikinya: https://github.com/eggheadio/egghead-redux-transcripts

@gaearon Saya memutuskan untuk menggunakan redux, dan kemudian menemukan

Jadi saran saya untuk pelatihan video redux ke depan adalah komposisi lanjutan, penyelaman lebih dalam ke refactoring, dan pasti bagaimana menggunakan reselect. Anda tampaknya memiliki intuisi tentang kapan harus melakukan refactor. Jadi, karena pemrograman fungsional sangat terkait erat dengan redux, mendapatkan beberapa tip dari Anda tentang kapan harus refactor dan bagaimana mengidentifikasi fungsi yang melakukan satu hal dengan baik akan sangat berguna.

Dalam aplikasi yang saya buat, saya memiliki beberapa koleksi data besar dan saya perlu memasukkannya ke dalam tabel dan melakukan hal-hal seperti mengurutkan dan membuat paginasi data. Saya mengalami kesulitan memutuskan kapan harus menggunakan penyeleksi dan kapan harus menggunakan tindakan buat. Saat ini saya memiliki tindakan USERS_SORT_TABLE dan tindakan SORT_TABLE karena saya memiliki pengguna yang menyimpan "mewarisi" beberapa status dari tabel. Saya melakukan ini karena saya tidak ingin tindakan SORT_TABLE di toko todo diurutkan berdasarkan toko pengguna.

Saya tahu solusi saya tidak KERING, tetapi saya tidak yakin bagaimana melakukannya dengan benar. Seperti berdiri saya harus membuat tindakan "SOMETHING"_SORT_TABLE untuk setiap toko saya ingin mengisi tabel, yang saya tahu salah, tapi saya tidak tahu cara yang benar. Efek samping lainnya adalah nama tindakan saya semakin besar karena saya harus memisahkan toko yang berbeda dengan mengawali nama mereka ke tindakan. Ini tidak benar.

Berikut beberapa contoh kode:

/* actions.js */
// ...
export const USER_MOVE_COLUMN = 'USER_MOVE_COLUMN'

export function userMoveColumn (columnIndex, moveToIndex) {
  return {
    type: USER_MOVE_COLUMN,
    columnIndex,
    moveToIndex
  }
}

export const DATA_TABLE_MOVE_COLUMN = 'DATA_TABLE_MOVE_COLUMN'
// ...

/* reducers.js */
// ...
export default function user (state=userInitialState, action) {
  switch (action.type) {
    // ...
    case USER_MOVE_COLUMN:
      return dataTable(state, assign(
        action,
        {type: DATA_TABLE_MOVE_COLUMN}
      ))
    // ...
    default:
      return state
  }
}
// ...
export default function dataTable (
  state=dataTableInitialState,
  action,
  key='dataTable')
{
  switch (action.type) {
    // ...
    case DATA_TABLE_MOVE_COLUMN:
      return {
        ...state,
        [key]: {
          ...state[key],
          columns: move(
            state[key].columns, action.columnIndex, action.moveToIndex
          )
        }
      }
    // ...
    default:
      return state
  }
}

Jadi Anda dapat melihat saya membuat ketergantungan antara tabel dan toko "model" yang seharusnya tidak saya miliki (toko model harus menggunakan kunci koleksi untuk array objeknya). Dan dataTable memanipulasi status peredam "induk", yang seharusnya tidak. Terpikir oleh saya bahwa saya perlu menggunakan pemilih di sana, tetapi pada saat saya menulis ini, saya mencoba untuk menghindari duplikasi toko besar hanya untuk mengubah apa yang terlihat di UI.

Jadi saat ini saya sedang berjuang untuk belajar memilih ulang untuk menyelesaikan beberapa masalah ini dan teknik refactoring untuk menyelesaikan beberapa yang lain. Kursus Redux pertama sudah cukup membuatku berbahaya. Sekarang saya ingin belajar bagaimana melakukannya dengan benar. :)

Saya harap itu membantu dan tidak terlalu bertele-tele. Mencoba memberikan umpan balik yang jelas dan jujur.

Untuk semua jenis jiwa yang mungkin membantu saya, saya telah menemukan /examples/real-world/reducers dari komentar Dan yang lain dan saat ini saya sedang mengerjakan ulang beberapa masalah yang telah saya uraikan di atas. Tidak ingin Anda membuang waktu mencoba membantu jika saya menemukan solusi.

Terima kasih atas peringatannya :)

mengintegrasikan redux-devtools dalam proyek saya adalah masalah besar bagi saya .. saya akan (dan masih akan) menghargai seri egghead yang menjelaskan apa yang ada di luar sana dan bagaimana / kapan menggunakannya. Saya membaca PR di mana Anda menjelaskan kapan harus menggunakan apa .. tapi saya jadi bingung ada begitu banyak hal di luar sana hmr, transform 3, redux hot reloader berbeda dari react hot reloader dan sebagainya..

Untuk siapa pun yang berjuang dengan beberapa masalah yang telah saya uraikan di atas, saya membuat sebuah proyek yang memungkinkan Anda untuk menghapus sebagian besar jika tidak semua boilerplate di Redux serta tindakan namespace. Lihat itu di sini

@granteagon Bukankah pasangan ini

Saya telah mencatat bahwa kebanyakan orang yang membuat pembungkus atau abstraksi di atas pembuatan tindakan/peredam cenderung berasumsi bahwa mereka akan selalu digabungkan secara langsung. Diakui, di aplikasi saya, sejauh ini _sebagian besar_ tindakan saya memiliki tepat satu potongan logika penanganan yang sesuai, tetapi pasti ada beberapa di mana beberapa bagian pohon perlu diperbarui.

@gaearon @markerikson Itu

@granteagon @gaearon

Setelah menggunakan abstraksi lokal yang mirip dengan reduxr, saya berpendapat tidak ada sambungan tambahan di sini. Tidak ada yang memaksa pemetaan 1:1 antara tindakan dan reduksi. Anda masih dapat memiliki dua reduksi dalam dua irisan berbeda yang mendengarkan tindakan yang sama:

const counterReducersA = {
  // this counter increments by 1 each time
  increment: (state, action) => state + 1
}

const counterReducersB = {
  // this counter increments by 2 each time
  increment: (state, action) => state + 2
}

const counterA = reduxr(counterReducersA, 0);
const counterB = reduxr(counterReducersB, 0);

const rootReducer = combineReducers({
  counterA: counterA.reducer,
  counterB: counterB.reducer
});

store.dispatch(counterA.action.increment());  // increments both counters

Tentu saja, jika Anda memiliki lebih dari satu fungsi "peredam" bernama hal yang sama (yaitu menanggapi tindakan yang sama), secara implisit mereka berdua perlu "mengharapkan" payload tindakan akan berada dalam bentuk tertentu --- yang sepenuhnya analog untuk memiliki dua reduksi di vanilla redux keduanya menangani konstanta type sama --- keduanya harus mengharapkan bentuk tindakan yang sama.

Mungkin saya salah paham apa yang Anda maksud dengan kopling, @gaearon ?

Saya pikir menunjukkan aliran asinkron tanpa middleware sebelum menunjukkan implementasi thunk dapat membantu.

Agak terkait, tetapi sementara dokumentasinya sangat membantu, pernyataan pada halaman aliran async ini benar-benar membuat saya keluar jalur di belakang: "Tanpa middleware, toko Redux hanya mendukung aliran data sinkron."

@battaile : itu karena itu benar :) Tanpa middleware, asinkronisitas apa pun harus terjadi sepenuhnya di luar Redux (jadi, kemungkinan besar di lapisan UI Anda, seperti komponen React). Setiap kali Anda memanggil store.dispatch , aksinya akan langsung ke fungsi peredam, jangan lewati Go, jangan kumpulkan $200, jangan berhenti di sepanjang jalan untuk panggilan AJAX.

Enhancer toko memungkinkan Anda untuk menyelesaikan fungsi seperti dispatch dengan versi Anda sendiri, sehingga applyMiddleware menyediakan abstraksi "pipa middleware" sebelum sesuatu mencapai fungsi dispatch toko yang sebenarnya . Itu pada dasarnya menyediakan celah di mana Anda dapat melompat keluar dan melakukan hal-hal asinkron apa pun yang Anda inginkan, _inside_ dari aliran Redux standar.

Jadi, tanpa middleware, Anda masih dapat melakukan hal-hal asinkron... semuanya harus terjadi sepenuhnya terpisah dari apa pun yang sebenarnya terkait dengan Redux.

itu karena itu benar :)

Saya tidak mengatakan itu salah, saya mengatakan itu membuat saya keluar jalur :)

Saya hanya ingin melakukan sesuatu seperti berikut, yang sepertinya menyiratkan bahwa saya tidak bisa:

const mapDispatchToProps = (dispatch) => ({
  onclick(searchTerm) {
    dispatch(actions.requestOrders(searchTerm));

    return fetch('http://localhost:49984/Order/Search?search=' + searchTerm)
      .then(response => response.json()).then(response => {
        dispatch(actions.receiveOrders(searchTerm, response));
      })
      .catch((err) => {
        dispatch(actions.receiveOrdersError('An error occurred during search: ' + err.message));
      });
  },
});

Saya menyadari ini bisa dengan mudah menjadi jelek, tetapi secara konseptual saya pikir ini berguna untuk dilihat. Atau setidaknya itu dalam kasus saya.

Saya setuju bahwa "Tanpa middleware, toko Redux hanya mendukung aliran data sinkron." menyesatkan.

Secara teknis jika Anda ingin membedakan antara "dalam" dan "luar", pernyataan itu mungkin benar, tetapi jika itu membuat orang percaya bahwa satu-satunya cara untuk melakukan async adalah dengan menambahkan middleware, mungkin kita dapat menulis ulang atau menguraikannya dia.

Ya, perbedaannya adalah bahwa perilaku async secara teknis lebih banyak terjadi di tingkat komponen, daripada "di dalam" dari dispatch . Perbedaan kecil, tapi yang valid.

Saya tidak berpikir ada orang yang benar-benar berargumen bahwa pernyataan itu secara teknis tidak benar.

@markerikson Hanya ingin tahu apakah Anda memiliki contoh konkret di mana perbedaan antara masalah di dalam dan di luar?

Salah satu contohnya mungkin jika Anda ingin middleware dalam rantai _before_ middleware async Anda dapat melihat thunk yang Anda kirim (atau janji, dll). Saya tidak yakin _apa_ middleware itu akan _lakukan_, tetapi saya kira layak untuk menginginkan hal seperti itu.

Mmm... tidak yakin tentang contoh "konkret" secara khusus. Secara keseluruhan, perbedaan antara "luar" dan "dalam" adalah pertanyaan apakah itu terjadi _sebelum_ Anda memanggil dispatch pertama kali, atau _setelah_. Jika "di luar" dan "sebelum", maka semua asinkronisitas dan logika Anda lebih terikat pada lapisan tampilan, apakah itu Bereaksi, Sudut, atau yang lainnya. Jika "di dalam" dan "setelah", maka asinkronisitas dan logika Anda berada di tingkat toko, dan _not_ terikat ke lapisan tampilan.

Ini sebenarnya adalah poin penting yang baru saja saya coba sampaikan dalam diskusi Reddit hari ini: https://www.reddit.com/r/reactjs/comments/4spbip/has_anyone_inserted_a_controllerpresenter_layer/ .

Pertanyaan "tindakan apa yang saya kirim dan kapan saya harus mengirimnya?" adalah bagian inti dari logika bisnis Anda, dengan separuh lainnya adalah "bagaimana cara memperbarui status saya sebagai tanggapan atas tindakan tersebut?". Jika manajemen tindakan dalam thunks dan saga dan semacamnya, maka tidak masalah apakah kode itu dimulai oleh Komponen Bereaksi, Pengontrol Sudut, penangan klik jQuery, instance komponen Vue, atau yang lainnya. Logika inti Anda berada di luar lapisan UI, dan lapisan UI benar-benar hanya bertanggung jawab untuk menarik data yang dibutuhkan keluar dari penyimpanan, menampilkannya, dan mengubah input pengguna menjadi panggilan fungsi logika aplikasi.

Jadi, dalam pengertian itu, saya akan mengatakan pertanyaan "di dalam" vs "di luar" itu penting, karena ini adalah perbedaan konseptual antara apakah logika Anda hidup di level aplikasi atau level UI.

@markerikson terima kasih telah mendukung saya dalam pertanyaan ini. Dengan risiko tampil sebagai argumentatif, saya _do_ ingin sedikit mendorong kembali gagasan bahwa ini adalah "level aplikasi" vs. "level UI".

Catatan: Untuk kenyamanan saya akan menggunakan thunk untuk mewakili pendekatan middleware singkat untuk async, apakah itu benar-benar redux-thunk atau redux-promise, atau apa pun.

Lapisan UI Anda hanya menghubungkan interaksi pengguna ke penangan. Saat seseorang mengklik tombol, UI Anda dicurangi untuk memanggil _some_ handler. Seringkali, komponen menerima penangan ini sebagai alat peraga --- mungkin pencipta tindakan terikat, misalnya. UI tidak menyadari apa yang terjadi ketika memanggil handler --- itu hanya memanggilnya.

Tidak ada bedanya dengan lapisan UI apakah "penangan" mengirimkan suatu fungsi (untuk ditangani oleh middleware) atau apakah itu menjalankan panggilan async dan _then_ mengirimkan tindakan biasa --- UI sepenuhnya agnostik (atau setidaknya, itu _bisa_ menjadi agnostik)

Sebagian besar "aplikasi" Anda ada di "penangan" ini, baik Anda menggunakan thunks atau tidak. Dalam aplikasi reaksi/redux yang khas, "penangan" ini sering kali merupakan pembuat tindakan. Anda bisa menulis semua barang async Anda sebagai thunks, dan mengirimkannya. Atau, Anda dapat menulis semua hal asinkron Anda sebagai fungsi yang menerima dispatch sebagai argumen. Dari perspektif komponen, itu bisa someHandler(dispatch) OR dispatch(someHandler()) , atau dalam kasus pembuat tindakan terikat diturunkan dari atas, itu hanya someHandler() dalam kedua kasus. Anda dapat membuat versi bindActionCreators yang akan sepenuhnya menutupi perbedaan ini dari lapisan UI.

Jika Anda memberi saya aplikasi reaksi/redux yang ditulis dengan pembuat tindakan menggunakan redux-thunk, saya dapat sepenuhnya menukar redux-thunk dan menggunakan pendekatan non-middleware tanpa _fundamental_ mengubah salah satu lapisan UI. (catatan: Saya mengabaikan di mana/bagaimana Anda menyuntikkan getState , tapi saya _percaya_ itu detail kecil di sini).

Oleh karena itu, saya kesulitan menerima bahwa perbedaan antara "di dalam" dan "di luar" adalah "tingkat aplikasi" atau "tingkat UI".

Saya menghargai diskusi ini, dan saya harap saya tidak menganggapnya negatif.

Kursus ini sangat bagus. Menutup ini sehingga orang dapat mengarahkan komentar mereka ke repo catatan komunitas untuk kursus: https://github.com/tayiorbeii/egghead.io_redux_course_notes

Juga, pastikan untuk melihat seri berikutnya Dan disatukan! https://egghead.io/courses/building-react-applications-with-idiomatic-redux