React: [Payung] Melepaskan Ketegangan

Ekspos unstable_AsyncMode (mungkin?)

Bukankah ini sudah terungkap ?

Maksud saya hapus unstable_

Saya menantikan untuk membuka sumber perpustakaan pemecah

Apa artinya [Payung]?🤔☂️

Ini berarti, ini adalah fitur yang memengaruhi beberapa proyek/paket/alat.

@ghoullier begitu, Terima kasih banyak!

Hai @acdlite , hanya sebuah pertanyaan tentang cara terbaik untuk mempersiapkan ini. Tidak meminta / mengharapkan timeline apa pun, tetapi bertanya-tanya:

Apakah Anda saat ini mengharapkan fitur-fitur ini masuk ke React 16 dan mudah diadopsi secara bertahap, seperti Context API baru yang hadir dengan 16.3?

Atau apakah Anda berpikir itu akan menjadi sesuatu yang mendorong React ke v17 dan membutuhkan lebih banyak pekerjaan untuk diadopsi?

Bertanya karena saya sedang mengerjakan peta jalan yang melintasi secara signifikan dengan hampir semua yang ada di daftar Anda dan saya mencoba mencari cara terbaik untuk mengatasinya.

Apakah Anda juga memiliki tips tentang cara terbaik untuk mempersiapkan (dalam hal kode yang ditulis hari ini, yang ingin agar kompatibel di masa depan dengan peningkatan React ini) - polyfills / teknik / dll?

(maaf jika pertanyaan ini dijawab di tempat lain dan saya melewatkannya)

Menambahkan pertanyaan lain ke pertanyaan @JedWatson :

• Kami juga tidak membutuhkan/mengharapkan untuk mendapatkan timeline untuk rilis stabil, tetapi apakah mungkin/berguna untuk mendapatkan prarilis baru? (AFAIK rilis terbaru adalah 16.4.0-alpha.0911da3 mulai Februari.)

Terima kasih! ❤️

IMO, mereka akan memberikan posting blog seperti sebelumnya sebelum mendarat.

Dan saya pikir Anda tidak perlu mempersiapkan terlalu banyak karena tidak ada perubahan yang melanggar (itu memang memiliki banyak fitur yang mungkin tampak berbeda/bertentangan dengan praktik saat ini, seperti redux fetch dengan ketegangan, tetapi akan ada codemod atau enkapsulasi yang mudah untuk melakukan ini, Anda tahu, fb memiliki komponen 3W+). Dan jika Anda menonton pembicaraan @acdlite (tentang ssr suspense di ZEIT) dan @gaearon (tentang client suspense di islandia), Anda akan tahu bahwa Anda tidak perlu terlalu khawatir dan tidak invasif.

Omong-omong, Anda bisa mencari kunci 'Umbrella' di repo dan Anda akan menemukan info lebih lanjut seperti #8830 dan #12152

AFAIK rilis terbaru adalah 16.4.0-alpha.0911da3 mulai Februari.

IIRC, ini salah operasi?

@JedWatson Komentar ini membantu saya memahami apa yang harus dilakukan pengembang untuk membantu memastikan bahwa aplikasi mereka aman async .

Saya sedang berupaya meluncurkan modul ketegangan dan API baru di facebook. Jika @acdlite sibuk dengan hal lain, saya ingin berbagi beberapa pemikiran saya tentang pengalaman kami di facebook dan menjawab beberapa pertanyaan dari @JedWatson.

Apakah Anda saat ini mengharapkan fitur-fitur ini masuk ke React 16 dan mudah diadopsi secara bertahap, seperti Context API baru yang hadir dengan 16.3?

Saya tidak yakin apakah itu akan datang dengan React 16 atau 17. Menurut tim React, kemungkinan akan dirilis sebelum akhir tahun ini, yang tergantung pada seberapa baik itu berjalan di facebook dan bagaimana API terkait siap atau bukan. Tapi dari segi kode, saya senang mengatakan bahwa itu akan mudah diadopsi, karena kami telah bereksperimen cukup lama di facebook. Fitur suspense akan tetap berfungsi untuk basis kode yang ada. Tetapi dengan perubahan tambahan (seperti rendering async), Anda akan memiliki lebih banyak bonus yang akan diberikan fitur baru kepada Anda.

Apakah Anda memiliki tips tentang cara terbaik untuk mempersiapkan (dalam hal kode yang ditulis hari ini, yang ingin agar kompatibel di masa depan dengan peningkatan React ini) - polyfills / teknik / dll?

Saya akan mengatakan migrasi agak bertahap dan progresif. Seperti yang dikatakan @NE-SmallTown, kami tidak ingin memperkenalkan perubahan yang melanggar. Itu juga akan menyakitkan untuk diluncurkan ke facebook karena kami memiliki basis kode yang sangat besar. Namun sejauh ini, peluncurannya lancar dan tidak mengharuskan Anda melakukan perubahan tambahan.

@JedWatson

Apakah Anda saat ini mengharapkan fitur-fitur ini masuk ke React 16 dan mudah diadopsi secara bertahap, seperti Context API baru yang hadir dengan 16.3?

Secara bertahap. Selalu secara bertahap :) Jika tidak, kami tidak dapat mengirimkan ini di Facebook.

Inilah yang saya harapkan:

| | Klien | Render sisi server |
|-----------------|----------------------------|-- -------------------------------------------------------|
| Ketegangan | Bekerja di mana saja* | Batasan yang sama dengan perender server yang ada |
| Render asinkron | Ikut serta menggunakan <AsyncMode> | Batasan yang sama dengan perender server yang ada |

*Dalam mode sinkronisasi, delayMs selalu 0 . Placeholder segera muncul.

Ketegangan akan bekerja tanpa perubahan apa pun pada komponen Anda yang ada. Pada satu titik kami pikir kami mungkin memerlukan kompatibilitas <StrictMode> , tetapi selama pengujian internal kami, kami menemukan salah satu cara terbaik untuk meningkatkan ke mode ketat adalah dengan menggunakan Suspense. Dilema telur ayam. Jadi kami menemukan cara untuk membuatnya bekerja bahkan di luar mode ketat.

Jadi idenya adalah bahwa pengguna akan mulai bermigrasi ke Suspense bahkan sebelum mereka siap untuk bermigrasi ke rendering asinkron. Kemudian setelah subpohon siap, mereka dapat ikut serta dengan membungkus <AsyncMode> .

Namun, untuk aplikasi baru, ceritanya berbeda: asinkron secara default. Kami akan memperkenalkan API root baru (pengganti ReactDOM.render ) yang hanya asinkron.

Akan ada periode canggung setelah rilis awal di mana banyak kerangka kerja pihak ketiga (Redux, Apollo, React Router...) mungkin tidak berfungsi dengan baik dalam mode asinkron. Itu mungkin menyakiti adopsi untuk sementara waktu. Tetapi idenya adalah bahwa fitur-fitur baru akan sangat menarik sehingga tidak akan lama bagi perpustakaan untuk beradaptasi atau digantikan oleh alternatif yang kompatibel dengan async.

Apakah Anda juga memiliki tips tentang cara terbaik untuk mempersiapkan (dalam hal kode yang ditulis hari ini, yang ingin agar kompatibel di masa depan dengan peningkatan React ini) - polyfills / teknik / dll?

Bungkus semuanya dalam <StrictMode> dan pastikan tidak ada peringatan. Kami akan memiliki panduan migrasi yang lebih mendetail saat kami semakin dekat dengan rilis.

Akan ada periode canggung setelah rilis awal di mana banyak kerangka kerja pihak ketiga (Redux, Apollo, React Router...) mungkin tidak berfungsi dengan baik dalam mode asinkron.

Apollo tidak canggung - kami akan siap! 🕺😳

Serius, kami :heart: semua hal Bereaksi, jadi memastikan kami sejalan dengan perubahan ini untuk rilis awal bukan hanya prioritas tinggi, tetapi juga sesuatu yang sangat kami sukai! Terima kasih atas semua pekerjaan luar biasa Anda di @acdlite ini!

Saya akan berpadu dan mengatakan bahwa tim Redux sedang mengerjakan async compat untuk React-Redux.

Saya menyusun peta jalan potensial di https://github.com/reduxjs/react-redux/issues/950 . TL; DR:

• React-Redux 5.1 semoga akan bekerja dengan <StrictMode> tanpa peringatan (PR saat ini: https://github.com/reduxjs/react-redux/pull/980 )
• 6.0 akan menjadi penulisan ulang internal untuk menggunakan API konteks baru, menambahkan penerusan referensi, dan mungkin perubahan lain, tetapi cobalah untuk menyimpan sebanyak mungkin API publik saat ini (yaitu, <Provider> dan connect() ). Kita akan melihat seberapa baik itu bekerja dengan rendering async, dan mencari tahu jalur terbaik ke depan. (PR proof-of-concept saya sebelumnya ada di https://github.com/reactjs/react-redux/pull/898 , tetapi kami mungkin akan mengulanginya berdasarkan pelajaran lain yang dipetik dari pekerjaan 5.1.) Kemungkinan rilis ini akan membutuhkan React 16.5 sebagai minimum, karena kebutuhan untuk konteks baru dan mungkin juga PR "baca konteks dari metode siklus hidup" yang belum dirilis yang baru saja digabungkan.
• Setelah itu, kami terbuka untuk ide untuk React-Redux API yang berbeda (ya, ya, itu mungkin termasuk render props, orang).

Kami akan menghargai lebih banyak perhatian pada WIP kami, dan mudah-mudahan orang dapat memberi kami lebih banyak umpan balik dan diskusi tentang bagaimana mereka melihat penggunaan Redux dengan React Suspense dan rendering async sehingga kami dapat memastikan kasus penggunaan tercakup dengan benar. Kami juga berharap untuk berdiskusi lebih lanjut dengan tim React tentang kendala apa yang perlu kami tangani, dan akan sangat membantu jika kami bisa mendapatkan beberapa contoh aplikasi yang memungkinkan kami melihat masalah apa yang perlu kami selesaikan untuk semua ini untuk bekerja dengan benar.

menantikan rilis rendering dan Ketegangan Async

@acdlite Juga pertanyaan tentang ketegangan dan rendering async.
Pertanyaan saya adalah begitu mereka diperkenalkan dan seseorang mulai menulis aplikasi dengan versi reaksi yang baru: apakah itu berarti bahwa API reaksi dan cara kode orang bereaksi akan berubah juga? (bahkan jika mereka tidak berencana untuk menggunakan fitur suspense dan rendering async?)

Saya berasumsi akan lebih sulit untuk menulis kode reaksi dengan ketegangan dan rendering async (mungkin karena beberapa API baru atau kendala lain), dan bagi mereka yang tidak membutuhkannya, mengapa memaksa mereka untuk menggunakan reaksi dengan cara baru? Dan tidak mengizinkan mereka membuat kode dalam reaksi seperti yang mereka lakukan sekarang?

Saya berasumsi akan lebih sulit untuk menulis kode reaksi dengan ketegangan

Apakah Anda memiliki kesempatan untuk menonton paruh kedua ceramah saya? Saya akan mengatakan sebaliknya - jauh lebih sulit untuk menggunakan ketegangan untuk pengambilan data daripada apa pun (termasuk Redux, negara bagian lokal, atau perpustakaan lain).

@gaearon saya belum. Saya berbicara lebih banyak dalam teori. Bayangkan sudah ada sekumpulan orang yang tahu bereaksi. Jika orang tidak membutuhkan fitur rendering dan ketegangan async, mengapa memaksa mereka belajar reaksi "baru"? Terutama jika reaksi "baru" lebih sulit digunakan? Tetapi: Saya tidak mendapat informasi yang baik jadi saya mungkin salah mengatakan tentang bagian yang "lebih rumit" - saya hanya membagikan beberapa pemikiran saya :).

Di satu sisi saya mengatakan jika 10% aplikasi memerlukan fitur Suspense dan rendering async, mengapa dalam 90% kasus lainnya memaksa orang untuk belajar reaksi "baru"? Tapi sekali lagi saya mungkin salah, karena saya belum mengumpulkan banyak info tentang suspence dan rendering async.

Saya pikir sulit untuk melakukan percakapan jika Anda belum melihat demo saya .

Untuk lebih jelasnya: tidak ada "React baru", fitur-fitur ini tidak merusak pola yang ada . Mereka adalah aditif. Anda juga tidak perlu menulis kode dengan cara yang sama sekali berbeda untuk menggunakan fitur tersebut — meskipun beberapa di antaranya hanya berfungsi jika Anda menggunakan metode siklus hidup modern .

Meskipun ini tidak terkait langsung dengan kekhawatiran Anda, saya tidak setuju bahwa mereka "lebih sulit untuk digunakan". Saya pikir ketegangan jauh lebih sederhana untuk digunakan daripada mekanisme pemuatan lain yang ada saat ini. Itulah alasan saya sangat bersemangat tentang hal itu. Tetapi sekali lagi, Anda tidak perlu menggunakan fitur baru apa pun jika tidak mau. Pola lama akan terus bekerja.

Saya sangat merekomendasikan menonton ceramah saya . Saya yakin ini akan jauh lebih masuk akal setelah Anda melihat fitur-fitur ini beraksi.

@gaearon

Semua pola lama tetap bekerja.

Terima kasih atas umpan baliknya Dan. Ya begitulah yang saya pikirkan, saya kira jika orang tidak membutuhkan fitur-fitur itu, mereka harus bisa menulis seperti dulu sebelum fitur-fitur itu ditambahkan.

semoga berhasil.

Hei Dan(@gaearon), saya tidak rewel tapi ingin mencari tahu. Di atas Anda berkata:

Tetapi sekali lagi, Anda tidak perlu menggunakan fitur baru apa pun jika tidak mau. Pola lama akan terus bekerja.

Manakah yang menunjukkan bahwa saya dapat membuat kode di React baru dengan cara yang sama seperti yang saya lakukan di React "lama", misalnya saya dapat menggunakan metode siklus hidup dengan cara yang sama, dll. kan?

Namun, di sini , bvaughn mengatakan bahwa getDerivedStateFromProps (atau componentWillReceiveProps) dapat dipanggil berkali- kali untuk satu pembaruan, oleh karena itu solusinya tidak mengambil data di dalamnya.

Jadi pertanyaan saya adalah, bagaimanapun juga, sepertinya kita tidak dapat menggunakan React baru dengan cara yang persis sama seperti sebelumnya kan? Karena AFAIK di react componentWillReceiveProps saat ini tidak dipanggil berkali- kali untuk satu pembaruan, bukan?

@giorgi-m : ya, metode siklus hidup berubah, tetapi intinya adalah bahwa Suspense itu sendiri adalah fitur keikutsertaan. Semua metode render React Anda yang ada dan perilaku rendering React akan berfungsi apa adanya. Namun, _jika_ Anda ikut serta dengan menambahkan tag <AsyncMode> ke bagian aplikasi Anda, _dan_ Anda mulai menggunakan pendekatan Suspense untuk menunjukkan kebutuhan data asinkron, _kemudian_ Anda dapat memanfaatkannya. Semua itu tidak terjadi jika Anda tidak menambahkannya ke basis kode Anda.

@giorgi-m componentDidUpdate harus digunakan sebagai ganti componentWillReceiveProps atau getDerivedStateFromProps .

@markerikson Jadi Anda mengatakan bahwa apa yang bvaughn katakan di sini , bahwa _getDerivedStateFromProps_ dapat dipanggil berkali-kali untuk satu pembaruan, belum tentu demikian, jika saya belum mengaktifkan <AsyncMode/> ?
(maaf untuk mengajukan pertanyaan seperti itu hanya mereka muncul kepada saya dari waktu ke waktu, dan tidak menemukan sumber daya yang akan mencakup semua).

hal. bvaughn juga tidak menyebutkan opsionalitas itu di utas yang ditautkan, oleh karena itu meningkatkan kecurigaan saya.

Haruskah metode untuk mengantrekan pembaruan asinkron (misalnya deferSetState() untuk komponen kelas sebagai lawan dari perender khusus unstable_deferredUpdates() ) ditambahkan ke daftar periksa inti?

Dari pemahaman saya, setiap pembaruan untuk serat di async mode akan menjadi asinkron, yang secara teori berarti bahwa deferSetState() tidak diperlukan. Namun, demo unstable-async/suspense menggabungkan pembaruan sinkron dan pembaruan asinkron dan saya tidak yakin bagaimana hal itu dapat dicapai dalam mode async (untuk komponen "universal").

Ada dalam daftar periksa untuk payung pengiris waktu.

Dukungan janji sebagai tipe komponen

Terkait dengan ini, ketika Anda memiliki:

const PromiseType = new Promise(() => {})
class A extends Component {
    componentDidMount() {}
    componentDidUpdate() {}
    render() {
        return <div><PromiseType></PromiseType></div>
    }
}

Apakah ada heuristik kapan siklus hidup componentDidMount dan componentDidUpdate akan dipanggil.

1. Ketika semua anak telah diselesaikan (termasuk janji), yang dalam hal ini berarti mereka tidak akan dipanggil mengingat janji tidak pernah diselesaikan?
2. Kapan semua anak angkat Segera telah dirender?

@thysultan : componentDidMount dan componentDidUpdate dipanggil dalam fase komit, ketika pohon UI telah sepenuhnya dirender dan diterapkan ke DOM.

Jadi, berdasarkan pemahaman saya tentang Ketegangan, saya pikir jawabannya adalah bahwa instance A tidak akan pernah benar-benar dipasang. Jika PromiseType _did_ diselesaikan, tetapi salah satu turunan selanjutnya juga berusaha menunggu janji yang tidak pernah diselesaikan, itu tidak akan pernah dipasang lagi. Jadi, cDM dan cDU tidak akan pernah dieksekusi dalam contoh tersebut.

(Seseorang merasa bebas untuk mengoreksi saya jika asumsi saya salah di sini :))

Ya, componentDidMount atau componentDidUpdate hanya dieksekusi dalam fase komit yang hanya dijalankan setelah seluruh pohon diselesaikan. Pohon ini mungkin menyertakan beberapa tempat penampung yang telah Anda tempatkan secara eksplisit di sana (bergantung pada apakah sesuatu di dalamnya masih ditangguhkan setelah kami menunggu cukup lama) — tetapi jika Anda secara eksplisit membuat anak tanpa tempat penampung di sekitarnya, Anda tidak akan pernah bisa berakhir di situasi di mana itu "belum siap".

Saya sangat menantikan untuk dapat bermain dengan ini (bahkan menelusuri banyak kode sumber hanya untuk mengetahui bahwa Anda belum menempatkan versi kerja ini di world wide web).

Adakah yang bisa kami lakukan untuk membantu merilis ini? :D

Anda dapat mengkompilasi dari master jika Anda ingin bermain. Lihat petunjuk di fixtures/unstable-async/suspense

@gaearon Apakah saya benar bahwa ini hanya dalam keadaan klien saat ini (jadi lebih banyak pekerjaan yang harus dilakukan untuk mendukung rendering sisi server)?

EDIT, temukan jawabannya: Bagi siapa pun yang ingin menggunakan Suspense di SSR untuk aplikasi universal. Saya menemukan komentar ini oleh Dan yang memberi tahu kami bahwa ini adalah sisi klien hanya untuk saat ini. Namun, komentar itu juga merujuk ke https://www.youtube.com/watch?v=z-6JC0_cOns yang membahas tentang kemungkinan implikasinya terhadap RSK.

Kami sebenarnya akan segera memulai beberapa pekerjaan terkait kasus RSK.

Bayangkan skenario ini dalam aplikasi React async yang berjalan di perangkat seluler kelas bawah:

1. Ada pemuatan iklan eksternal, menggunakan semua CPU (😓)
2. Pengguna mengklik tautan dan router memicu render baru
3. React dalam mode async, jadi menunggu hingga Chrome/Safari mengizinkannya untuk menggunakan CPU, tetapi iklan terus dimuat selama 3 detik lagi
4. Pengguna menganggap aplikasi tidak berfungsi

Masalah ini dapat dihindari dengan menggunakan teknik <Placeholder> yang sama seperti yang dibahas untuk Suspense, misalnya, menampilkan pemintal setelah 1 detik.

Apakah skenario ini sudah dipertimbangkan? Akankah <Placeholder> berfungsi untuk perenderan asinkron yang lambat?

@luisherranz Ada dua mekanisme untuk mencegah hal ini:

1. Bereaksi memiliki tenggat waktu yang terkait dengan setiap pembaruan. Pembaruan dari klik dan interaksi lain seperti ini akan mengalir dalam ~150 md, kecuali jika Anda secara eksplisit memilih tenggat waktu yang lebih lama (mis. untuk pembaruan yang tidak penting). Jadi React secara serempak akan memaksa flush jika ada sesuatu yang memonopoli utas.

2. React sebenarnya tidak menggunakan requestIdleCallback lagi karena memang browser tidak cukup agresif untuk menjadwalkannya. Pendekatan penjadwalan yang tepat mungkin juga berubah seiring waktu, tetapi ini jelas merupakan sesuatu yang kami pedulikan.

Banyak terima kasih atas jawaban cepat Dan.

1. Bereaksi memiliki tenggat waktu yang terkait dengan setiap pembaruan

Luar biasa. Apakah sudah ada API yang bisa kami uji?

1. React sebenarnya tidak menggunakan requestIdleCallback lagi karena memang browser tidak cukup agresif untuk menjadwalkannya.

Itu juga yang kami coba. Terkadang dalam aplikasi yang penuh sesak dengan iklan eksternal dan penyematan dari twitter atau youtube, mungkin diperlukan beberapa detik hingga requestIdleCallback dipanggil dan perenderan selesai. Jadi 👍 untuk itu.

BTW, bagi kami ada kasus penggunaan lain yang terkait dengan jawaban pertama Anda: kami mencoba menggunakan lazyloads dengan dua offset. Yang pertama memicu render async, yang kedua memicu render sinkronisasi jika async belum selesai. Sesuatu seperti ini:

1. Pengguna menggulir ke bawah dan berada pada 1200px dari elemen berat: misalnya posting blog berikutnya.
2. Offet pertama memicu render async dari posting berikutnya.
3. Pengguna terus menggulir ke bawah dan berada di 600px dari posting berikutnya.
4. Pemicu offset kedua: Jika posting async telah selesai (componentDidMount disebut) tidak ada yang terjadi tetapi jika belum, itu memicu render sinkronisasi dari seluruh posting.

Jadi, alih-alih waktu, kami ingin mengontrol flush dengan pemicu kedua. Apakah masuk akal? Mungkinkah?

Apakah sudah ada API yang bisa kami uji?

Saya tidak yakin apakah yang Anda maksud pada master atau tidak (mode async tidak tersedia secara resmi dalam rilis npm), tetapi waktu kedaluwarsa ditetapkan secara otomatis untuk setiap pembaruan. Untuk acara seperti klik itu ~150ms dalam mode prod. Anda tidak dapat menyetelnya, meskipun Anda dapat memilih pembaruan yang ditangguhkan (lebih lama) jika Anda mau dengan API khusus yang tidak stabil.

Jadi, alih-alih waktu, kami ingin mengontrol flush dengan pemicu kedua. Apakah masuk akal? Mungkinkah?

Ya itu mungkin. Saya menjelaskan mekanisme seperti ini di sini: https://github.com/oliviertassinari/react-swipeable-views/issues/453#issuecomment -417939459.

Saya tidak yakin apakah maksud Anda pada master atau tidak (mode async tidak tersedia secara resmi dalam rilis npm)

Ya, kami menggunakan paket npm dengan <unstable_AsyncMode> , flushSync dan unstable_deferredUpdates .

Tolong, mulailah merilis versi alfa/beta dengan perubahan ini ke npm! 🙏

Ya itu mungkin. Saya menjelaskan mekanisme seperti ini di sini: oliviertasinari/react-swipeable-views#453 (komentar).

Cemerlang. Jauh lebih baik daripada implementasi kami saat ini menggunakan unstable_deferredUpdates :)

Tidak sabar untuk mulai menggunakan <div hidden> . Kalian melakukan pekerjaan yang luar biasa.

@luisherranz Hati-hati, hal-hal itu _are_ tidak stabil. Mungkin memiliki bug atau sangat tidak efisien (misalnya pengoptimalan penting — "melanjutkan" — belum diterapkan). Kami juga menghapus unstable_deferredUpdates demi modul schedule baru ( schedule.unstable_scheduleWork ).

Ya, kami menggunakannya hanya untuk sebagian kecil aplikasi dan menguji secara intensif tetapi sejauh ini bagus :)

MUNGKIN OFFTOPIC:
requestIdleCallback dipanggil hanya 20 kali per detik - Chrome di mesin Linux inti 6x2 saya, itu tidak terlalu berguna untuk pekerjaan UI.
requestAnimationFrame dipanggil lebih sering, tetapi spesifik untuk tugas yang disarankan oleh namanya.

Kami telah berhenti menggunakan requestIdleCallback karena alasan ini.

Apa yang kalian gunakan daripada requestIdleCallback ?

@TejasQ https://github.com/facebook/react/tree/master/packages/scheduler

Tentu saja. Saya konyol. Saya bertanya-tanya API browser apa yang digunakan modul penjadwal di bawah tenda alih-alih requestIdleCallback . Saya seharusnya menyajikan pertanyaan itu dengan lebih jelas. 😅

Wah, ketemu.
https://github.com/facebook/react/blob/eeb817785c771362416fd87ea7d2a1a32dde9842/packages/scheduler/src/Scheduler.js#L212 -L222

Itu keren tingkat berikutnya.

Hai,

ketika mencoba memahami Suspense, saya menyadari bahwa saya tidak tahu bagian mana dari aplikasi yang sebenarnya "ditangguhkan" saat menggunakan komponen Suspend .

Dalam contoh berikut, saya berharap Title akan segera terlihat, Spinner setelah 1000 md dan UserData setelah ~2000 md (karena "memuat" data untuk komponen tersebut memerlukan 2000 md).
Tapi yang saya lihat adalah Title pertama kali muncul bersamaan dengan Spinner setelah 1000 ms.

// longRunningOperation returns a promise that resolves after 2000ms
const UserResource = createResource(longRunningOperation);

function UserData() {
  const userData = UserResource.read(cache, "Lorem Ipsum");
  return <p>User Data: {userData}</p>;
}

function Spinner() {
  return <h1>Fallback Loading Spinner</h1>;
}

function Title() {
  return <h1>Hello World</h1>;
}

function App() {
  return (
    <React.Fragment>
      <Title />
      <Suspense maxDuration={1000} fallback={<Spinner />}>
        <UserData />
      </Suspense>
    </React.Fragment>
  );
}

unstable_createRoot(document.getElementById("mount")).render(<App />);

(Anda dapat menemukan contoh lengkap yang menggunakan React 16.6.0-alpha.8af6728 di sini di codesandbox )

Apakah ada cara untuk membuat Title segera terlihat dan "menangguhkan" hanya bagian lain dari aplikasi? Atau apakah saya salah paham mungkin Suspense sepenuhnya? (Jika ada cara yang lebih baik untuk mengajukan pertanyaan semacam ini, beri tahu saya)

Terima kasih!

Hai @nilshartmann! Pertanyaan bagus!

Apakah ada cara untuk membuat Judul segera terlihat dan "menangguhkan" hanya bagian lain dari aplikasi?

Jika saya mengerti dengan benar, Anda harus secara eksplisit memberi tahu Bereaksi untuk _tidak menunggu_ sebelum mem-flush Title ke DOM seperti dalam contoh ini untuk membuat Title segera terlihat dan "menangguhkan" hanya yang lain bagian dari aplikasi dengan membungkus bagian-bagian yang Anda harapkan untuk segera dirender dalam <Suspense maxDuration={0}> .

Saya membayangkan ini terjadi karena beberapa mekanik penjadwal tingkat bawah yang mendasarinya? Saya juga ingin memahami ini dengan lebih baik, tetapi itu akan menyelesaikan masalah Anda untuk saat ini.

Saya senang mendengar apa yang sebenarnya terjadi di sana.

(Jika ada cara yang lebih baik untuk mengajukan pertanyaan semacam ini, beri tahu saya)

Saya tidak yakin ada. Tampaknya cukup jelas bagi saya. Terima kasih untuk bertanya!

@TejasQ Di browser saya, memuat contoh Anda membuat pemintal mundur segera. Bukankah seharusnya dimuat setelah 1000ms?

@TejasQ terima kasih atas jawaban Anda, tetapi @karlhorky benar: sekarang pemintal segera muncul.

Astaga! Saya melewatkan itu. Saya mencoba. Biarkan saya melihatnya lagi dan kembali kepada Anda. Aku pasti melewatkan sesuatu. ️

~Pembaruan: Saya mencoba mencari tahu di sini dan kami dapat berkolaborasi jika ada yang tertarik untuk melakukannya bersama secara realtime.~

Pembaruan kedua: @philipp-spiess dan saya telah melihatnya dan saya benar-benar bingung. Aku masih tidak mengerti. Pada titik ini, saya tidak yakin apakah itu bug karena ini sebenarnya adalah fitur unstable_ dan alfa, atau apakah itu sesuatu yang tidak saya lihat.

Dalam kedua kasus tersebut, saya merasa tim inti akan memiliki jawaban yang membantu, atau dapat menggunakan pertanyaan Anda untuk membuat React menjadi lebih baik/lebih mudah didekati.

Mari kita lihat apa yang mereka katakan. Terima kasih telah menunjukkan hal ini, @nilshartmann!

Apakah ini dirilis sebagai bagian dari React v16.6? Posting blog menunjukkan contoh kode menggunakan Suspense:

import React, {lazy, Suspense} from 'react';
const OtherComponent = lazy(() => import('./OtherComponent'));

function MyComponent() (
  <Suspense fallback={<div>Loading...</div>}>
    <OtherComponent />
  </Suspense>
);

Apakah ini dirilis sebagai bagian dari React v16.6?

Hanya kasus penggunaan pemuatan lambat, dan hanya dalam mode sinkronisasi. Mode bersamaan masih WIP.

@nilshartmann

Dalam contoh berikut, saya berharap Judul akan segera terlihat, Spinner setelah 1000ms dan UserData setelah ~2000ms (karena "memuat" data untuk komponen itu membutuhkan 2000ms).

Saya pikir Anda agak bingung tentang apa yang dilakukan maxDuration . Ini adalah model mental baru tetapi kami belum punya waktu untuk mendokumentasikannya. Jadi itu akan tetap membingungkan untuk sementara waktu sampai mode bersamaan dalam rilis stabil.

Selamat telah mengumumkan proposal hooks. Saya ingin berbagi sesuatu dengan tim. Beberapa waktu lalu saya merilis sebuah komponen bernama React Async , yang memiliki fitur mirip dengan Suspense. Pada dasarnya ini menangani resolusi Promise, dan menyediakan metadata seperti isLoading, startAt dan metode seperti memuat ulang dan membatalkan, semuanya dengan API deklaratif (dan kait useAsync sedang dalam perjalanan).

Sekarang perhatian utama saya adalah bagaimana ini akan terintegrasi dengan Suspense. Untuk sebagian besar, saya mungkin dapat menggunakan Suspense API dari React Async dan memberi pengguna React Async API yang familiar dan sederhana, sambil menawarkan fitur penjadwalan Suspense secara gratis. Untuk apa yang saya lihat, saya benar-benar berpikir React Async API lebih masuk akal dan mudah didekati dibandingkan dengan Suspense API yang lebih abstrak. Pada dasarnya React Async mencoba menawarkan API yang lebih konkret yang berfungsi untuk subset kasus penggunaan yang sedikit lebih kecil.

Saya terkejut mengetahui perpustakaan React Cache. Untuk React Async saya sengaja tidak menyertakan mekanisme cache tetapi memilih untuk berurusan dengan Vanilla Promises. Menambahkan caching di atasnya cukup mudah.

Akhirnya saya khawatir tentang mengakses fitur Suspense dari kait khusus. Ketegangan tampaknya sangat bergantung pada beberapa komponen bawaan, yang membuatnya tidak mungkin (saya pikir?) untuk menggunakannya dari sebuah kait. Apakah akan ada Suspense hook? Atau adakah cara lain untuk mengintegrasikan keduanya?

Halo. Bagaimana saya bisa menguji kode dengan Suspense/Lazy?
sekarang renderer.create(...)toTree() melempar
"toTree() belum tahu cara menangani node dengan tag=13"

Mengapa props maxDuration di Suspense hanya digunakan di Concurrent Mode daripada mode sinkronisasi dan bersamaan. Adakah yang bisa membantu menjelaskan?

(Sekarang) itu berarti berapa lama Concurrent Mode diperbolehkan meninggalkan pohon ini menunggu sebelum memaksanya untuk melakukan -- secara efektif mengontrol batas waktu pemotongan waktu, dan pemotongan waktu tidak ada dalam mode Sinkronisasi. Menunggu sebelum melakukan pohon akan membuat komit... bukan Sinkronisasi.

Saya telah menggunakan Suspense dalam aplikasi internal untuk pengambilan data dan dengan sangat cepat menemukan alasan mengapa itu tidak dimaksudkan untuk digunakan untuk pengambilan data.

Namun, pada akhirnya, ini dimaksudkan untuk digunakan untuk mengambil data. Mengingat bahwa tampaknya tidak mungkin API akan berubah secara signifikan kecuali mungkin penyedia cache, bagaimana Suspense dimaksudkan untuk bekerja jika Anda perlu mengubah data setelah Anda mengambilnya?

Sebagai contoh, ini adalah kait yang sangat buruk dari aplikasi saya.

function useComponentList(id) {
  const incomingComponents = useSuspenseFetch(
    React.useCallback(() => getComponentAPI().listComponents(id), [id])
  )

  const map = React.useMemo(
    () =>
      Map(
        (incomingComponents || []).map(component => [component.id, component])
      ),
    [incomingComponents]
  )

  return useCacheValue(map)
}

kait ini:

1. Mengambil data menggunakan panggilan balik yang diberikan dari titik akhir yang diberikan
2. Mengubah data itu menjadi Peta ImmutableJS - Karena ini berpotensi mahal, saya memoize operasinya.
3. Mengembalikan peta yang dibungkus useCacheValue , yang merupakan bagian yang sangat canggung.

useCacheValue terlihat seperti ini:

export default function useCacheValue(value) {
  const [state, setState] = React.useState(value)
  React.useEffect(() => {
    setState(value)
  }, [value])

  return [state, setState]
}

dengan gagasan bahwa itu adalah pengait yang akan merespons perubahan value (yang menunjukkan bahwa data diambil ulang) tetapi memungkinkan pengguna untuk mengubah representasi aplikasi reaksi dari keadaan itu. Di satu sisi, ini bertindak seperti cache yang sangat buruk (karenanya namanya).

Saya berjuang untuk melihat bagaimana pola ini bekerja dengan baik dengan Redux dalam kondisi saat ini. Apakah ada penemuan tentang bagaimana ini mungkin terlihat ketika ditulis oleh seorang programmer yang bukan saya dan ketika ketegangan 'siap' untuk pengambilan data? Seperti yang terjadi, ini jauh lebih melelahkan daripada menggunakan Redux sendiri dengan flag pengambilan imperatif.

Ini mungkin menjadi jauh lebih sederhana setelah Redux memiliki kaitnya sendiri karena kesulitan utama dalam membuat keduanya bermain bersama adalah bahwa Redux menggunakan HOC dengan konteks yang tidak dimaksudkan untuk diekspos, tetapi saya masih ingin melihat apa yang resmi jawabannya adalah :)

Suspense dimaksudkan untuk bekerja dengan cache eksternal ( bukan Hook yang didorong oleh status). Kami akan memberikan implementasi referensi dari cache yang berfungsi untuk kasus penggunaan sederhana. Relay akan mengimplementasikan mekanisme cachingnya sendiri. Alat lain (seperti Apollo) juga dapat mengimplementasikan cache mereka sendiri yang kompatibel, mungkin terinspirasi oleh dua implementasi ini.

Mutasi/pembatalan bukanlah satu-satunya pertanyaan yang membutuhkan jawaban. Kita juga perlu memikirkan: kapan harus menampilkan pemintal, pola umum seperti "indikator sebaris" yang mungkin berada di luar pohon yang ditangguhkan, mengoordinasikan status pemuatan (untuk hal-hal yang perlu dibuka dalam urutan top-down atau masuk sebagaimana adanya siap), streaming rendering daftar, bagaimana ini memengaruhi hidrasi parsial, dan sebagainya. Kami sedang mengerjakan hal-hal ini tetapi belum ada "rekomendasi resmi" untuk semua itu. Jika ada, Anda akan mengetahuinya dari blog tempat kami mengumumkan pembaruan.

Sebagai catatan tambahan, Ketegangan untuk pengambilan data adalah model mental yang cukup berbeda dari yang biasa dilakukan orang. Saya tidak berpikir itu adil untuk mengharapkan itu akan sama kuatnya ketika diintegrasikan dengan mekanisme yang sangat tidak dibatasi seperti Redux. Tapi kita lihat saja. Sulit untuk mengatakan apa pun sekarang.

@gaearon Ketika Anda mengatakan "kami sedang mengerjakan hal-hal ini", apakah ada masalah yang dapat saya

Terima kasih, @gaearon :)

@ntucker Seperti biasa, Anda dapat menonton aktivitas yang sedang berlangsung sebagai PR. Misalnya: https://github.com/facebook/react/pull/14717 , https://github.com/facebook/react/pull/14884 , https://github.com/facebook/react/pull/15061 , https://github.com/facebook/react/pull/15151 , https://github.com/facebook/react/pull/15272 , https://github.com/facebook/react/pull/15358 , https ://github.com/facebook/react/pull/15367 , dan seterusnya. Kami mencoba memasukkan beberapa informasi deskriptif ke dalam setiap PR, dan Anda dapat melihat perubahan perilaku dari tes. Bilah dokumentasi untuk eksperimen rendah karena beberapa alasan.

Kami akan memposting penjelasan lebih lengkap tentang model yang dipilih setelah kami lebih yakin bahwa itu benar-benar berfungsi. Saya tidak berpikir itu akan menjadi produktif baik bagi kami atau komunitas jika kami dengan susah payah menjelaskan setiap eksperimen secara rinci saat itu terjadi. Sebagian besar eksperimen pertama kami gagal, dan mendokumentasikan serta menjelaskan setiap eksperimen akan memperlambat pekerjaan kami.

Lebih buruk lagi bahwa ini sering mengakibatkan orang membangun model mental di sekitar sesuatu yang kemudian kita sadari tidak bekerja dengan cara yang dirancang semula. (Seperti yang terjadi dengan maxDuration yang baru saja kami hapus.) Jadi, kami lebih suka menunda berbagi ide yang setengah matang sampai waktu Anda dan waktu kami digunakan dengan baik. Ini konsisten dengan bagaimana kami mengembangkan React di masa lalu juga. Ketika sesuatu benar-benar siap (bahkan untuk penulisan teoretis dari model mental), kami akan memusatkan semua perhatian kami untuk mendokumentasikan dan menjelaskannya.

Sebagai catatan tambahan, Ketegangan untuk pengambilan data adalah model mental yang cukup berbeda dari yang biasa dilakukan orang. Saya tidak berpikir itu adil untuk mengharapkan itu akan sama kuatnya ketika diintegrasikan dengan mekanisme yang sangat tidak dibatasi seperti Redux. Tapi kita lihat saja. Sulit untuk mengatakan apa pun sekarang.

@gaearon , untungnya, model mental Suspense sangat cocok dengan milik saya. Sangat bersemangat untuk potongan teka-teki itu jatuh ke tempatnya. Terima kasih atas semua kerja keras Anda!

Peta jalan yang diumumkan November lalu (https://reactjs.org/blog/2018/11/27/react-16-roadmap.html) menunjukkan bahwa versi "bersamaan" dari Suspense dijadwalkan untuk Q2 2019. Kami sekarang baik-baik saja. Q3 2019. Apakah ada update yang bisa kita dapatkan dari segi pasti bukan Q3, atau mungkin Q3, dll?

Ini adalah pembaruan peta jalan terbaru yang dapat saya temukan: https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#an -update-to-the-roadmap

Kami menyediakan rilis eksperimental pada bulan Oktober: https://reactjs.org/docs/concurrent-mode-intro.html. Ini adalah build yang sama yang kami jalankan dalam produksi. Masih ada banyak pekerjaan yang harus dilakukan (baik dalam hal mengutak-atik API dan membangun API tingkat yang lebih tinggi) tetapi Anda dapat mulai memainkannya jika Anda mau.

Ketegangan membunuhku

@gaearon Saya mengerti bahwa Anda menggunakannya dalam produksi. Tapi saya sangat enggan menggunakan kode "eksperimental" dalam produksi. Kalian tidak jelas tentang peta jalan, status, kemajuan, pengaturan waktu, dll. Apakah ini kualitas alfa, beta, RC? Istilah "eksperimental" ini mengatakan "jangan sentuh ini" kepada saya.

Kita semua menyimpan bisnis kita dengan kode ini dan saya yakin kita semua sama sibuknya dengan kalian. Sedikit kejelasan, blog, SESUATU akan sangat membantu. Hampir terasa seperti "Ini dalam produksi di Facebook, jadi kami sudah selesai".

@mschipperheyn

Ini adalah proyek multi-tahun. Jawaban jujurnya adalah bahwa itu menghasilkan lebih banyak pekerjaan daripada yang kami kira ketika kami memulainya dua tahun lalu.

Tetapi kabar baiknya adalah karena kami sekarang banyak menggunakannya dalam produksi, bagian yang hilang menjadi jelas dan kami melihat ujung terowongan. Ini tidak teoretis — ada serangkaian hal terbatas yang perlu kita selesaikan sebelum kita dapat dengan nyaman mengatakan bahwa itu siap untuk diadopsi secara luas.

Berikut keadaan kasar dari berbagai alur kerja hari ini:

• <Suspense> API untuk pemecahan kode dengan lazy . ( dikirim dalam React 16.6)
  
  
  
  • Seperti yang Anda ketahui, Anda sudah dapat menggunakan yang ini.
  
  
• API Mode Bersamaan, misalnya createRoot dan useTransition . ( tersedia dalam rilis experimental )
  
  
  
  • Solusi kompatibilitas untuk perpustakaan seperti Flux. ( sedang berlangsung @bvaughn , https://github.com/reactjs/rfcs/pull/147)
  
  
  • Mengubah model prioritas menjadi model yang lebih masuk akal. ( sedang berlangsung @acdlite , https://github.com/facebook/react/pull/18612)
  
  
  • Hanya izinkan transisi tertunda terakhir selesai. ( sedang berlangsung @acdlite)
  
  
  • Offscreen API ( sedang berlangsung @lunaruan)
  
  
  • Efek api saat menyembunyikan/menampilkan konten untuk Suspense
  
  
  • Efek api saat menyembunyikan/menampilkan konten untuk Offscreen
  
  
  • Tampilkan dan sembunyikan anak-anak Portal saat dibutuhkan
  
  
  • Sejajarkan dengan pekerjaan standardisasi yang sedang berlangsung untuk Penjadwalan ( tidak dimulai )
  
  
  • Perbaiki bug utama yang diketahui ( sedang berlangsung @gaearon dan @acdlite)
  
  
  • Ubah semantik acara. ( sedang berlangsung @sebmarkbage @trueadm)
  
  
  • Delegasikan ke root alih-alih dokumen untuk memungkinkan adopsi yang lebih bertahap ( sedang berlangsung , @trueadm)
  
  
  • Siram peristiwa diskrit dalam fase penangkapan.
  
  
  • Pertimbangkan untuk mendapatkan prioritas default dari event untuk bermain lebih baik dengan kode imperatif.
  
  
  • Selesaikan semantik dan default API lainnya. ( tidak dimulai )
  
  
  • Perbarui pengetikan dan dokumentasi.
  
  
• Ketegangan untuk Pengambilan Data
  
  
  
  • Dukungan tingkat rendah untuk menandakan suatu komponen belum siap untuk dirender (secara teknis tersedia di React yang stabil juga, tetapi API ini tidak dianggap stabil).
  
  
  • Penyaji server segera menghapus fallback Suspense ( tersedia dalam rilis eksperimental)
  
  
  • Solusi untuk kasus penggunaan GraphQL (Relay Hooks, dikirim ).
  
  
  • Solusi untuk kasus penggunaan non-GraphQL ( sedang berlangsung @sebmarkbage bekerja sama dengan Next.js).
  
  
  • Integrasi bundler untuk dependensi berbasis data. ( sedang berlangsung )
  
  
  • Selesaikan Blocks API, termasuk konteksnya.
  
  
  • Solusi caching generik. ( tidak dimulai )
  
  
  • Beberapa jenis integrasi router.
  
  

Hampir terasa seperti "Ini dalam produksi di Facebook, jadi kami sudah selesai".

Saya bisa melihat bagaimana hal itu bisa terlihat seperti ini, meskipun bacaan ini sedikit menurunkan moral. :-) Kami telah mengerjakan ini tanpa henti selama beberapa bulan terakhir, dan banyak aspek teknis telah selesai atau hampir selesai. Sebagian besar karya yang tersisa terbagi dalam dua kategori:

• Memperbaiki kekurangan yang kami temukan di desain awal sebelum kami memperkuatnya dalam rilis yang stabil. Jika kami ingin merilis apa yang kami miliki sekarang, kami harus menindaklanjuti dengan perubahan besar yang signifikan dalam beberapa bulan. Itu hanya akan membingungkan.

• Kompatibilitas ekosistem dan default yang baik. Tidak ada gunanya jika kami merilis sesuatu yang tidak dapat digunakan siapa pun saat ini karena tidak berfungsi dengan perpustakaan mereka atau pendekatan yang ada. Jadi sebagian besar pekerjaan (misalnya kompatibilitas dengan perpustakaan mirip Flux melalui useMutableSource , memilih semantik acara yang lebih baik, mengirimkan strategi caching yang disarankan) adalah untuk memastikan Anda benar-benar dapat menggunakan apa yang kami rilis. Ini adalah ekor yang panjang.

Dalam hal "dapatkah Anda menggunakan hari ini"... Secara teknis, Anda dapat menggunakan semua ini hari ini. Kami melakukannya. Secara khusus, kami menggunakan Relay Hooks dan Concurrent Mode. Kami masih memiliki perubahan terencana yang signifikan dan masalah yang diketahui, sehingga kondisi saat ini tidak memenuhi standar yang kami anggap siap untuk diadopsi secara luas. Tentu saja, jika Anda tidak keberatan jika ada bug atau API yang berubah di tangan Anda, Anda dapat menggunakan rilis @experimental seperti yang kami lakukan.

Saya tidak akan mengatakan Facebook berada dalam posisi khusus di sini dalam hal kita "sedang selesai". Sebaliknya, kami belum selesai — tetapi secara internal, kami bersedia menoleransi churn dan membangun di atas kereta yang bergerak karena itulah cara kami mengetahui bahwa apa yang kami bangun itu kokoh. Tanpa dogfooding yang berat ini, kekurangan yang kami temukan dalam enam bulan akan memakan waktu beberapa tahun untuk ditemukan dan didesain ulang.

Singkatnya: ada lebih banyak pekerjaan yang harus dilakukan.

@gaearon Terima kasih atas pembaruan ini! Dan saya minta maaf jika nada saya salah. Saya akui saya agak frustrasi menjelajahi Twitter selama berbulan-bulan dan tidak menemukan apa pun. Aspek ini Server renderer immediately flushes Suspense fallbacks (available in experimental releases) tampak seperti sesuatu yang saya dapat alokasikan waktu dalam menguji ini dengan Apollo Graphql untuk implementasi kami.

Ya, itu harus siap untuk penulis perpustakaan dan orang-orang yang penasaran untuk mulai bermain. Bagian yang hilang sebagian besar tentang menyediakan "jalur bahagia" tetapi sebagian besar pipa ledeng harus ada di sana.

Perender server segera menghapus fallback Suspense (tersedia dalam rilis eksperimental)

Di mana saya bisa membaca tentang ini? Saya berharap Referensi API Mode Bersamaan (Eksperimental) tetapi tidak berhasil.

Jika ada yang memiliki demo jahitan Next.js, Relay Hooks dan Concurrent Mode bersama-sama (dengan SSR) itu akan luar biasa. Kalau tidak, saya mungkin akan mencoba keberuntungan saya jika saya dapat menemukan dokumentasi yang memadai.

@CrocoDillon

Tidak ada dokumen tambahan tentang SSR tetapi sebagian besar karena itu hanya perilaku default baru.

Jika Anda memiliki rilis eksperimental daripada saat komponen ditangguhkan di server, kami menghapus fallback Suspense terdekat sebagai gantinya. Kemudian pada klien Anda akan menggunakan createRoot(node, { hydrate: true }).render(<App />) .

Perhatikan ini sudah mengaktifkan semua fitur hidrasi baru. Jadi misalnya batas Suspense Anda akan "melampirkan" ke HTML fallback yang dihasilkan server dan kemudian mencoba untuk membuat klien.

Perhatikan juga bahwa Anda dapat mulai menghidrasi sebelum seluruh aplikasi dimuat. Ketika <App> telah dimuat, Anda dapat menghidrasi. Selama komponen di bawah ditangguhkan ketika kodenya belum siap (mirip dengan malas). Apa yang akan dilakukan React dalam kasus ini adalah menjaga konten HTML server tetapi "melampirkan" batas Suspense padanya. Saat komponen anak dimuat, ia akan terus menghidrasi. Bagian terhidrasi akan menjadi acara interaktif dan replay.

Anda mungkin dapat meminta @devknoll untuk upaya/contoh integrasi berikutnya. Dia mungkin memiliki beberapa.

Anda dapat mengaktifkan mode bersamaan di Next.js dengan menginstal react@experimental dan react-dom@experimental dan menambahkan yang berikut ke next.config.js

// next.config.js
module.exports = {
  experimental: {
    reactMode: 'concurrent'
  }
}

Inilah diskusi Next.js tentang ini: https://github.com/zeit/next.js/discussions/10645

Apakah mungkin untuk menunggu ketegangan apa pun dalam rendering server (untuk kasus seperti gen situs statis misalnya)? Saya setuju bahwa menggunakan panggilan balik adalah default yang baik, hanya ingin tahu apakah itu dapat ditimpa?

Perhatikan juga bahwa Anda dapat mulai menghidrasi sebelum seluruh aplikasi dimuat. Kapantelah dimuat, Anda dapat menghidrasi. Selama komponen di bawah ditangguhkan ketika kodenya belum siap (mirip dengan malas). Apa yang akan dilakukan React dalam kasus ini adalah menjaga konten HTML server tetapi "melampirkan" batas Suspense padanya. Saat komponen anak dimuat, ia akan terus menghidrasi. Bagian terhidrasi akan menjadi acara interaktif dan replay.

@gaearon maksud Anda Anda dapat merender komponen secara normal di server, tetapi menggunakan React.lazy di klien? Memungkinkan Anda mengembalikan mark up penuh dari server, tetapi menunda penguraian dan rendering kode komponen pada klien. Markup yang diberikan server bertindak sebagai pengganti ketegangan di sini?

@robrichard Saya belum benar-benar mencobanya dengan React.lazy secara khusus (kami menggunakan pembungkus yang berbeda di FB dan Berikutnya juga memiliki versinya sendiri) tetapi saya berharap ini adalah cara kerjanya. Layak diverifikasi :-) Dengan batasan tertentu — misalnya jika Anda memperbarui props dan tidak ada bailout memo di atas, atau jika Anda memperbarui konteks di atasnya, kami harus menghapusnya dan menampilkan fallback karena kami tidak tahu apa yang harus dilakukan dengan itu.

@gaearon apa status Hidrasi Parsial saat ini? Saya tahu #14717 digabungkan tetapi saya ragu itu dibuat menjadi rilis apa pun?

Sudah lama ada di setiap rilis @experimental sekarang, selama Anda menggunakan unstable_createRoot API.

Berikut demonya: https://codesandbox.io/s/floral-worker-xwbwv?file=/src/index.js

@gaearon, bisakah Anda menjelaskan apa yang Anda maksud dengan "ketergantungan berbasis data"?

@gaearon, bisakah Anda menjelaskan apa yang Anda maksud dengan "ketergantungan berbasis data"?

Ya, tentu saja. Saya harus minta maaf atas singkatnya daftar di atas — daftar ini sangat padat dan banyak di antaranya adalah subproyek terpisah yang signifikan (itulah sebabnya mereka membutuhkan waktu).

Biarkan saya mengambil langkah mundur dan memberikan beberapa konteks yang lebih luas sebelum menjawab pertanyaan spesifik Anda. Konteks yang lebih luas adalah bahwa membangun solusi pengambilan data yang sangat baik sangatlah sulit. Tidak hanya dalam arti implementasi tetapi dalam arti desain. Biasanya, seseorang harus membuat kompromi antara colocation (menjaga persyaratan data dekat dengan tempat data digunakan) dan efisiensi (seberapa awal kita mulai memuat data, dan dapatkah kita menghindari air terjun jaringan). Ini tidak terlalu terlihat pada skala kecil, tetapi seiring bertambahnya jumlah komponen, Anda benar-benar harus memilih antara kinerja hebat dan kode yang mudah ditulis. Sayangnya, dalam banyak kasus, Anda tidak mendapatkan keduanya — itulah sebabnya pengambilan data secara umum menjadi topik yang hangat.

Kami memiliki standar yang sangat tinggi untuk apa yang masuk ke React "resmi". Untuk menjadi "Reacty", ia harus menulis seperti halnya komponen React biasa. Ini berarti kami tidak dapat dengan itikad baik merekomendasikan solusi yang kami yakini tidak akan berskala hingga ribuan komponen. Kami juga tidak dapat merekomendasikan solusi yang memaksa Anda untuk menulis kode dengan cara yang dioptimalkan dan berbelit-belit agar tetap berkinerja. Di FB, kami telah belajar banyak pelajaran dalam hal ini dari tim Relay. Kami tahu tidak semua orang dapat menggunakan GraphQL, atau ingin menggunakan Relay (itu tidak dengan sendirinya sangat populer dan tim belum mengoptimalkannya untuk adopsi eksternal). Tetapi kami ingin memastikan bahwa solusi pengambilan data kami untuk React umum menggabungkan pelajaran yang diperoleh dengan susah payah dari Relay dan tidak harus memilih antara kinerja dan colocation.

Saya ingin menekankan ini bukan hanya tentang aplikasi besar. Masalahnya paling terlihat di aplikasi besar, tetapi aplikasi kecil yang mengimpor banyak komponen dari npm juga mengalami sebagian dari inefisiensi ini. Seperti pengiriman terlalu banyak kode sisi klien dan memuatnya di air terjun. Atau memuat terlalu banyak di muka. Selain itu, aplikasi kecil tidak selamanya menjadi aplikasi kecil. Kami menginginkan solusi yang bekerja dengan baik untuk aplikasi dengan ukuran berapa pun, sama seperti model komponen React yang bekerja dengan cara yang sama terlepas dari kompleksitas aplikasi Anda.

Sekarang, untuk menjawab pertanyaan spesifik Anda. Relay memiliki fitur yang disebut "ketergantungan berbasis data". Salah satu cara untuk memikirkannya adalah evolusi dari dynamic import . Dinamis import tidak selalu efisien. Jika Anda ingin memuat beberapa kode hanya ketika kondisinya benar (misalnya "apakah pengguna masuk" atau "apakah pengguna memiliki pesan yang belum dibaca"), satu-satunya pilihan Anda adalah memicunya dengan malas. Tapi ini berarti Anda "memulai" mengambil (seperti dengan React.lazy ) hanya ketika sesuatu digunakan. Itu sebenarnya sudah terlambat. Misalnya, jika Anda memiliki beberapa level komponen code-split (atau komponen yang menunggu data), yang paling dalam hanya akan mulai memuat setelah yang di atasnya dimuat. Ini tidak efisien dan merupakan "air terjun" jaringan. Relai "dependensi berbasis data" memungkinkan Anda menentukan modul yang ingin Anda ambil sebagai bagian dari kueri. Yaitu "jika beberapa kondisi benar, sertakan potongan kode ini dengan respons data". Ini memungkinkan Anda memuat semua potongan kode yang Anda perlukan sedini mungkin. Anda tidak perlu menukar colocation untuk kinerja. Ini mungkin tampak seperti bukan masalah besar tetapi mencukur detik literal dalam kode produk.

Sekarang, sekali lagi, kami tidak memasukkan Relay ke dalam React, dan kami tidak ingin memaksa orang untuk menggunakan GraphQL. Tetapi secara konseptual fitur itu sendiri adalah generik, dan memiliki solusi open source yang baik untuk itu akan membuat orang melakukan lebih banyak pemecahan kode daripada yang dilakukan hari ini (dan dengan demikian mengirimkan lebih sedikit kode JS klien!) Fitur generik itu tidak akan dipanggil "ketergantungan berbasis data" — itu hanya nama Relay yang saya maksud. Fitur ini akan menjadi bagian dari solusi yang direkomendasikan lebih besar yang tidak memerlukan GraphQL. Saya hanya menyebutnya dengan nama itu dalam daftar karena ini banyak menjelaskan untuk satu poin daftar peluru.

Saya harap ini menjelaskannya.