@Knaee Apakah Anda mencoba kemungkinan? Saya juga bertanya-tanya apakah seseorang telah membuatnya bekerja dengan versi RR apa pun?

Selanjutnya punya router sendiri, kenapa pakai RR?

@sergiodxa Menimbang opsi saat saya

@oyeanuj 🤔 Anda dapat bermigrasi secara bertahap ke Next, cukup setel Next.js untuk menangani 1 rute dan gunakan proxy untuk memiliki aplikasi Anda saat ini dan Next.js, lalu pindahkan rute kedua dari RR ke Next.js, dan itu cara Anda dapat menyimpan aplikasi Anda saat ini saat bermigrasi, pada akhirnya Anda akan memiliki semuanya di Next.js

Dari melihat contoh, tampaknya next memiliki tabel rute tunggal seperti RRv2-3 dan tidak mendukung "rute bersarang" seperti RRv4. Ini bagus.

Saya akan mencoba menggunakan RR atau apakah ada peringatan besar yang tidak saya ketahui?

@igl Sudahkah Anda menemukan solusi untuk itu?

Paradigma react-router 4 baru dari rute bersarang adalah pengubah permainan, dan merupakan sesuatu yang harus dimiliki dalam proyek kami saat ini. Saya ingin tahu apakah ada yang berhasil mendapatkan rr4 untuk bekerja dengan next.js?

MemoryRouter berfungsi, jika tidak sesuai keinginan ...
Jika tidak, komponen dinamis hanya dapat menjadi sisi klien, di mana HashRouter berfungsi dengan baik ...

const AdminPage = dynamic(
  import('..../AdminPage'),
  { ssr: false }
);

Saya juga mengikuti pendekatan @malixsys dan menangani perutean sisi klien dengan react-router dan semua server memberikan konten dengan next router.

@malixsys @pegiadise dapatkah Anda memberikan beberapa detail lebih lanjut tentang cara menggunakan router berikutnya dan react-router bersama-sama?

Anda dapat menyetel sebuah flag di componentDidMount dan secara bersyarat membuat <Router /> ketika flag tersebut benar. ( componentDidMount tidak berjalan di server 😉)

Faktanya, kami akan segera memasukkan React Router di dalam Next.js :)
- https://twitter.com/rauchg/status/948318111828099072

Apakah ini masih terjadi? Saya dapat melihat catatan rilis untuk burung kenari V6 dan tidak ada yang menyebutkannya.

Akhirnya. Itu pasti ada di pikiran kita. Kami memiliki prioritas lain saat ini (komponen tata letak, pengembangan yang andal, dan beberapa masalah terbuka lama lainnya).

Sayang sekali, ini mungkin prioritas rendah untuk tim tetapi pada dasarnya itu satu-satunya hal yang menghentikan orang seperti saya untuk mulai menggunakannya. Saya membaca tutorial Anda sampai saya sampai di bagian di mana dikatakan bahwa rute harus diatur dua kali kemudian menyerah.

@timneutkens menambahkan integrasi react router akan membantu meningkatkan adopsi nextjs dan membuat pengembangan lebih baik. Pengembang seperti saya ingin melihat ini terjadi, harap pertimbangkan untuk meningkatkan prioritas.

Sayang sekali, ini mungkin prioritas rendah untuk tim tetapi pada dasarnya itu satu-satunya hal yang menghentikan orang seperti saya untuk mulai menggunakannya.

Sama.

Bisakah kita setidaknya membuka kembali masalah ini sehingga bisa dilacak?

Saya akan membuka kembali ini, tetapi perhatikan bahwa ini adalah proyek open source dan kami tidak memiliki alasan yang kuat untuk itu saat ini untuk zeit.co, karena kami menggunakan Next.js untuk semuanya.

Inilah mengapa saya mengatakan ini adalah bagian dari tujuan jangka panjang dan tidak dapat diterapkan dengan segera, tetapi kami sedang mengupayakannya.

Fitur-fitur yang saya perkenalkan di Next 6 sebenarnya berfungsi untuk mendukung React Router.

Kami memiliki prioritas lain untuk Next 6, yang sangat meningkatkan keandalan dan skalabilitas Next.js, misalnya penyelesaian halaman 100x lebih cepat, Komponen Aplikasi, membuat pekerjaan ekspor berikutnya dalam pengembangan, babel 7, dll.

Saya harap ini menjelaskan komentar saya sebelumnya.

Jadi TLDR-nya adalah:

• Kami akan melakukannya, tetapi tidak segera
• 6 berikutnya memiliki banyak perbaikan pada berbagai bagian Next.js

Untuk lebih memperluas komentar @timneutkens : kami pasti menginginkan RR, tetapi kami tidak memiliki batasan mendesak di Router saat ini yang menjadikannya prioritas. Semua kasus penggunaan perutean yang dapat Anda bayangkan telah berhasil diterapkan dengan API Next.js saat ini

Ada dua alasan mengapa kami sangat menginginkan dukungan React Router :

• Sederhanakan basis kode Next.js kita sendiri, tidak perlu memelihara router kita sendiri, membuatnya lebih kecil dan modular
• Sederhanakan jalur migrasi aplikasi besar yang sudah menggunakan RR

Karena itu, saya setuju kita harus tetap membuka masalah ini!

Sebagai tandingan, tidak memiliki react-router berarti selanjutnya berfungsi dengan baik dengan relay-modern dan merupakan salah satu alasan kami beralih ke berikutnya dari aplikasi react-router lama kami.

@merrywhether saya mengerjakan aplikasi RRv4 dengan relay-modern tahun lalu. Mau lebih spesifik?
Saya tidak ingat kami mengalami masalah serius karena keduanya.

@igl Ini sesuai dengan dokumentasi relai: https://facebook.github.io/relay/docs/en/routing.html#react -router-https-reacttrainingcom-react-router

Masalahnya adalah bahwa pendekatan komponen RRv4 tidak mengizinkan determinisme selama langkah pra-kompilasi, yang dapat mengakibatkan air terjun permintaan di klien.

@rauchg Karena minat, pemahaman saya tentang router Next adalah bahwa ia tidak mendukung konsep perutean bersarang, sehingga Anda dapat menyimpan markup luar saat menavigasi dalam halaman. Tahukah Anda jika ada cara untuk membuatnya mungkin dengan router saat ini?

@dbbk periksa aplikasi contoh nextgram kami (https://github.com/now-examples/nextgram), persis seperti itu

Di 5 berikutnya, kami menyelesaikan "markup luar" dengan memiliki komponen tata letak tingkat atas yang diperluas oleh semua laman kami: tata letak dasar memiliki navigasi atas, lalu beberapa sub-tata letak yang memperluas basis untuk daftar / detail / dll, lalu komponen halaman kami memperluas sub-tata letak ini dengan konten spesifik mereka sendiri. Dalam 6 berikutnya, Anda juga bisa mencapai dasar "markup luar" menggunakan _app.js Saya percaya.

Akankah versi berikutnya dapat dikonfigurasi untuk memilih solusi perutean yang bukan React Router?

Hai, saya hanya perlu react router untuk meneruskan props ke halaman (menggunakan <Route render ={} /> alih-alih <Route component ={} /> ), dapatkah saya melakukannya dengan Next?

Lihat https://github.com/zachrbrown/next-react-router. Ada atm dokumen langka, tetapi beberapa penjelasan singkat di https://github.com/zachrbrown/next-react-router/blob/master/src/IsomorphicRouter.js.

Dari melihat contoh, tampaknya next memiliki tabel rute tunggal seperti RRv2-3 dan tidak mendukung "rute bersarang" seperti RRv4. Ini bagus.

Hai,

Apakah ini berarti saya harus membuat satu halaman untuk satu rute?

Katakanlah jika saya memiliki 2 rute sign up , log in . Saya akan memiliki 1 halaman yang memiliki tata letak yang sama, satu-satunya perbedaan adalah area formulir. Artinya saya hanya perlu membuat 1 file di folder pages . Tetapi dengan rute berikutnya saya harus membuat 2 file di folder pages . Apakah itu?

Jika ya, maka tata letaknya disesuaikan dengan setiap navigasi, bukan hanya area formulir, bukan?

https://github.com/zeit/next.js/issues/75

@ 7c78 Satu hal yang dapat Anda lakukan adalah memanfaatkan _app.js untuk tata letak halaman tetap untuk semua halaman. Hal lain yang harus dilakukan adalah membuat komponen tata letak bersama yang dapat Anda gunakan kembali di berbagai halaman untuk mencapai apa yang Anda cari:

// pages/login.js

class LoginPage extends React.Component {
  render() {
    return (
      <AuthForm>    // same component can be reused in signup
        <form>
          ...implementation of login
        </form>
      </AuthForm>
    );
  }
}

Selain itu, Anda dapat melakukan apa yang telah kami lakukan baru-baru ini dan menentukan komponen tata letak dasar yang diperluas semua komponen halaman Anda:

//layouts/baseAuth.js

class BaseAuth extends React.Component {
  abstract formContent();  // we use typescript, but you can have the same concepts
  abstract formSubmit():

  render() {
    return (
      <SomeStyledDiv>
        <form>
          {this.formContent()}
          {this.formSubmit()}
        </form>
      </SomeStyledDiv>
    );
  }
}

Dan kemudian Anda hanya perlu memperpanjang BaseAuth di halaman login dan pendaftaran Anda dan menentukan formContent dan formSubmit di masing-masingnya (ini adalah contoh mainan, karena saya tidak tahu persis persyaratan Anda).

@tokopedia
Saat ini saya menggunakan pendekatan Anda, dan contoh berikutnya juga menggunakannya.

Tetapi kekhawatiran saya adalah saya perlu membuat halaman terpisah untuk formulir terpisah. Itu tata letak digunakan kembali tetapi bukan halaman. Dan tata letaknya disesuaikan dengan setiap navigasi.

Dengan RRv4, kami memiliki satu halaman dan formulir dirender / dipasang ulang berdasarkan rute (bukan seluruh halaman). Rute hanyalah komponen.

Terima kasih untuk respon yang cepat!

@ 7c78 Itu benar tentang remounting, meskipun menurut saya simpul DOM digunakan kembali saat vDOM menyelesaikan ke keadaan yang sama.

Ini bukan sesuatu yang sangat kami khawatirkan karena kami juga tidak dapat menggunakan react-router dengan relay-modern, jadi kami harus menggunakan pola ini.

@merrywhether Saya tidak yakin tentang vDOM karena server mengembalikan dokumen / html baru untuk setiap rute. Maaf abaikan anggapan ini, saya hanya pemula.

Saya setuju bahwa kita harus menggunakan pola ini. Terima kasih!

Anda dapat menggunakan RR dengan next.js dengan membuat seluruh aplikasi Anda berada di halaman / index.js tetapi Anda kehilangan beberapa barang berikutnya seperti pemisahan kode di luar kotak dan harus mengaturnya sendiri.

Saya akan senang jika Reach Router dipertimbangkan. Ini sangat mirip dengan react-router dan membawa beberapa manfaat penting:

• Ini memecahkan beberapa masalah a11y penting seputar pembuatan tautan dan manajemen fokus (https://reach.tech/router/accessibility).
• Beratnya lebih ringan (pada saat penulisan)
  
  
  
  • @ reach / [email protected] : 18.7 kB / 6kB ( link )
  
  
  • [email protected] : 44.1Kb / 10.4kB ( link )
  
  

Reach Router juga bagus 🥇

Rute dinamis gaya RR adalah API yang bagus, tetapi perutean statis (dan dapat dianalisis secara statis) juga membawa banyak manfaat. Tidak ada pendekatan yang merupakan pemenang slam-dunk.

@sorokinvj Itu hanya didukung melalui plugin (saat ini) .. https://github.com/fridays/next-routes

tautan statis sangat mendasar sehingga bahkan tidak mendukung parameter dalam tautan ...

saya menggunakan paket pihak ketiga rute berikutnya untuk saat ini https://github.com/fridays/next-routes untuk menyiasatinya

dikirim dari iPhone saya

Pada 24 Okt 2018, pukul 23:01, Andy Ingram [email protected] menulis:

Rute dinamis gaya RR adalah API yang bagus, tetapi perutean statis (dan dapat dianalisis secara statis) juga membawa banyak manfaat. Tidak ada pendekatan yang merupakan pemenang slam-dunk.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Kami menggunakan next-routes juga untuk saat ini, tetapi saya yakin tim berikutnya sedang bekerja untuk menambahkan parameter jalur ke perutean sistem file mereka melalui nama file regex (terinspirasi oleh Sapper).

@merrywhether Saya juga menggunakan next-routes tetapi saya lebih suka ini menjadi bagian dari inti Next.js.

Anda menyebutkan

Saya yakin tim berikutnya sedang bekerja untuk menambahkan parameter jalur ...

Saya ingin tahu apakah Anda punya referensi untuk ini? Mungkin masalah terbuka untuk parameter rute? Saya tidak dapat menemukannya ... Mungkin plugin menyelesaikan kebutuhan dan itu akan menjadi solusi yang disarankan di masa mendatang.

@curran Sumbernya adalah tweet dari salah satu sapper.js devs, mengatakan bahwa next mengambil inspirasi dari sapper.js dan mengimplementasikan regex-filename-routing di versi yang akan datang. Tentu saja, Twitter apa adanya, saya tidak bisa seumur hidup saya menemukan tweet asli.

Masalah ini diangkat pada 5 Apr 2017 dan sekarang menjadi 27 Feb 2019. Hampir 2 tahun dan tidak ada solusi
Mungkin sudah waktunya untuk mengganti router built-in setengah-setengah dengan sesuatu yang baik?

Aduh. Itu cukup menghina pengembang NextJS yang menghabiskan banyak waktu dalam solusi perutean.

Saya merindukan ReactRouter pada awalnya. Sekarang saya bahkan tidak ingat NextJS memiliki Router yang berbeda sampai seseorang mengingatkan saya. Verbose Link API itu mudah untuk digabungkan dengan proxy (tergantung pada data / arsitektur API Anda), misalnya. Berbagi rahasia teratas ini: 😆

import _Link from "next/link"
export function Link({as, children, href}) {
  as = as || QS.parse(U.parse(href).query || "").url || null // QS, U are parsing libs
  return <_Link as={as} href={href}>
    {children}
  </_Link>
}

<Link as="/about" href="/page?url=/about"/> verbose
→
<Link href="/page?url=/about"/> ok

Saya pikir kita semua harus menghabiskan lebih sedikit waktu untuk mengeluh tentang hal-hal sekunder 😉

@ ivan-kleshnin Bagus saya menambahkan bungkus serupa

Sesuai komentar sebelumnya, saya ingin merujuk ke https://www.contributor-covenant.org/version/1/4/code-of-conduct

Saya telah menyembunyikan komentar tersebut.

Saya tidak punya masalah dengan next/router untuk sebagian besar kasus penggunaan.
Tetapi itu harus sedikit meningkat pada bagian universal routing .
Dalam kasus penerapan Now 2, saya ingin mengambil now.json dan menggunakannya untuk merutekan dalam aplikasi saya.

Jika Anda ingin mengimplementasikan RR4 ke dalam proyek nextJs, Anda perlu melakukan 2 hal:

1. Cegah NextJS SSR, Dengan menggunakan next/dynamic Anda dapat melakukannya.
2. Menggunakan HashRouter daripada BrowserRouter -> jika pengguna memuat ulang halaman, browser dapat memuat halaman sebelumnya (bukan halaman 404)

Jika Anda ingin mengimplementasikan RR4 ke dalam proyek nextJs, Anda perlu melakukan 2 hal:

1. Cegah NextJS SSR, Dengan menggunakan next/dynamic Anda dapat melakukannya.
2. Menggunakan HashRouter daripada BrowserRouter -> jika pengguna memuat ulang halaman, browser dapat memuat halaman sebelumnya (bukan halaman 404)

Terima kasih atas balasan ini, banyak membantu saya.

@ reach / router dan react-router 5 bergabung: https://reacttraining.com/blog/reach-react-router-future/

Bagaimana ini mempengaruhi next.js?

@ alp82 Karena Next.js masih tidak menggunakan React Router atau Reach Router, hal itu tidak akan mempengaruhi Next.js sama sekali.

saya perlu beralih fungsi rute di nextjs untuk membuat beberapa komponen halaman di halaman indeks.
jadi bagaimana saya bisa menerapkan ini di nextjs ....... ???

Jika Anda ingin mengimplementasikan RR4 ke dalam proyek nextJs, Anda perlu melakukan 2 hal:

1. Cegah NextJS SSR, Dengan menggunakan next/dynamic Anda dapat melakukannya.
2. Menggunakan HashRouter daripada BrowserRouter -> jika pengguna memuat ulang halaman, browser dapat memuat halaman sebelumnya (bukan halaman 404)

jika Anda ingin merender ulang halaman Anda sebelumnya tanpa membuang kesalahan 404 jadi gunakan saja rute get ini di file server ekspres Anda.

server.get ('params Anda', (req, res) => {
const actualPage = '/ your_page'
const queryParams = {id: req.params.id}
app.render (req, res, actualPage, queryParams)
})

Saya mendokumentasikan pendekatan untuk menggunakan next.js dengan react-router , menyediakan file titik entri tunggal alih-alih perutean berbasis sistem file asli dan sepenuhnya mempertahankan fitur

Saya akan dengan senang hati menerima umpan balik dan meningkatkan apa yang saya lakukan.

Dokumentasi tersedia sebagai:

• Repositori GitHub
• dev. untuk memposting

Bersulang!

Saya akan sangat tidak menyarankan memasukkan react-router seperti itu saat Anda berakhir dengan satu entrypoint, yang berarti (sangat) pengembangan pengembangan lebih lambat, peluang lebih tinggi untuk mengirimkan terlalu banyak kode ke sisi klien dan visibilitas yang lebih sedikit ke dalam pengoptimalan seperti ekspor statis otomatis.

@timneutens Mungkin aku salah. Tetapi dengan lazy loading, konfigurasi perutean hanyalah satu file konfigurasi. Saya tidak melihat itu akan mempengaruhi skalabilitas atau kinerja di sini. Saya ingin mempelajari lebih lanjut tentang ini.
Manfaat react-router adalah para pengembang memiliki kendali penuh pada kode.

@timneutkens , saya tidak akan memulai argumen di sini tetapi saya dengan hormat meminta Anda untuk tidak menyembunyikan komentar saya. Saya menghabiskan waktu untuk membuat pekerjaan saya tersedia dan memberikannya kembali kepada komunitas dan saya tidak melihat bagaimana membungkam orang dapat membantu pengembangan open source.

@timneutkens untuk poin-poin yang Anda sebutkan itu masalah trade-off. Milik saya adalah eksperimen untuk menyuarakan bagaimana Next.js dapat digunakan dengan pengaturan yang berbeda.

Terlalu banyak kode di sisi klien

Bundel modern apa pun dapat membagi aset klien dalam beberapa bagian dan rute react-router sebenarnya adalah titik pemisahan yang sangat nyaman.

Waktu build dev lebih tinggi

Ini adalah harga yang harus dibayar untuk proyek besar, tetapi tidak ada yang tidak dapat ditangani dengan penyetelan webpack yang tepat.

Tidak ada ekspor statis

Saya setuju ekspor statis adalah lapisan pengoptimalan yang penting. Sebagian besar halaman yang disajikan oleh aplikasi Next.js rata-rata harus mengambil data dinamis dan tidak dapat memanfaatkan ekspor statis.

Tidak ada solusi yang kurang tentang masalah ini. Misalnya. mungkin masih mungkin untuk mendeklarasikan daftar rute yang akan diekspor secara statis

Alasan saya menyembunyikan komentar ini adalah karena ini adalah masalah lalu lintas tinggi dan tidak mencerminkan rekomendasi kami untuk membuat aplikasi Next.js. Jika seseorang berakhir di sini mencari untuk menggunakan react-router, mereka akan berakhir secara membabi buta menggunakan contoh Anda dan tidak menyelidiki cara mengatur perutean dengan benar menggunakan Next.js.

Ini adalah harga yang harus dibayar untuk proyek besar, tetapi tidak ada yang tidak dapat ditangani dengan penyetelan webpack yang tepat.

Anda tidak dapat mempercepat boot waktu pengembang berdasarkan pendekatan Anda, tidak ada penyesuaian khusus dari konfigurasi webpack karena webpack hanya akan mengkompilasi dan mengawasi setiap rute yang Anda impor yang secara besar-besaran memperlambat pengeditan ke komponen umum. Oleh karena itu mengapa Next.js memiliki entri sesuai permintaan: https://nextjs.org/blog/next-8#improved -on-demand-entries

Selain itu ada (otomatis) prefetching rute dll. Ada banyak hal spesifik yang bisa saya bahas di sini, tetapi tldrnya adalah Anda akan berakhir dengan pengalaman dan aplikasi pengembang yang lebih buruk.

Saya tidak keberatan menyembunyikan komentar jika benar-benar mencerminkan bahwa satu-satunya saat Anda ingin menggunakannya adalah dengan memigrasi aplikasi yang sudah menggunakan react-router dan kemudian secara bertahap pindah ke beberapa halaman.

Hai @timutens
Apakah Anda akan menghitung beberapa kelebihan yang dapat dianalisis secara statis dan tidak dimungkinkan dengan solusi perutean dinamis?

Beberapa hal seperti ini https://github.com/jaredpalmer/after.js ?

Saya telah membaca semua komentar dan masih belum jelas apakah RR4 + akan disertakan atau opsional di iterasi next.js. Apakah peta jalan router atau yang serupa?

@laurencefass tampaknya tidak ada rencana untuk mendukung react-router (mulai hari ini).

Bagi saya, sistem perutean Next.js sudah cukup matang jadi kita mungkin tidak membutuhkannya (lagi) :)

"Bagi saya, sistem perutean Next.js sudah cukup matang jadi kami mungkin tidak membutuhkannya (lagi) :)"

Kecuali bagi mereka yang ingin mengadopsi Next.js secara bertahap dalam basis kode yang ada. Saya pikir diskusi yang lebih berguna mungkin bukan "Next.js routing vs react-router routing". Saya pikir diskusi yang lebih berguna adalah "bagaimana saya bisa memigrasi aplikasi besar menggunakan react-router ke Next.js, secara bertahap?"

Router Next tidak memiliki kemampuan untuk menumpuk tampilan rute, bukan? Setiap navigasi ke suatu rute menghilangkan DOM dan menyegarkannya. Tampilan bersarang adalah persyaratan yang cukup umum.

@dbbk https://github.com/jaredpalmer/after.js

@dbbk Saya mendengar bahwa tim nextjs sedang mengerjakannya.

js berikutnya cukup fleksibel dengan router. https://dev.to/toomuchdesign/next-js-react-router-2kl8

Saya memindahkan situs web dari kode JS dan jQuery normal ke React. Tidak seperti kode lama, saya perlu mencegah musik berhenti saat mengubah halaman, jadi saya menggunakan React Router untuk itu.

Sekarang untuk tujuan SEO, karena saya memiliki trafik yang bagus dari Google Penelusuran, saya perlu mempertahankannya. Jadi saya lebih suka SSR dengan Next.js untuk kinerja yang lebih baik.

Apakah Next.js mampu merender halaman di sisi server dan kemudian setelah halaman dimuat di sisi Klien, Next.js akan membiarkan navigasi di bawah kendali React Router, sehingga jika Pengguna mendengarkan musik, Tautan Next.js menang ' t harus keluar dari halaman ini untuk menghentikan musik?

O bisakah Next.js membuat perutean Sisi-Klien saja?

Jika mengintegrasikan React Router akan dapat menyelesaikan masalah ini, maka saya masuk. Karena Pemutaran Musik Berkelanjutan adalah suatu keharusan bagi saya setelah Aplikasi mencapai Sisi Klien.

js berikutnya cukup fleksibel dengan router. https://dev.to/toomuchdesign/next-js-react-router-2kl8

@laurencefass , itu pendekatan yang sangat bagus, saya membacanya sebelumnya. Dan artikel mengatakan bahwa tim Next.js tidak merekomendasikannya, tidak tahu kenapa. Tapi menurutku itu bagus

@KeitelDOG Anda tidak memerlukan react-router untuk itu, perutean Next.js akan memberi Anda manfaat yang sama, ditambah aplikasi Anda akan lebih ringan berkat pemisahan kode otomatis (yang tidak akan Anda miliki dengan mudah dengan react-router)

_edit: Saya hanya akan menambahkan ini: mungkin satu-satunya keuntungan dari react-router adalah rute bersarang yang mudah dalam fitur tampilan yang sama, router Next.js harus menyelesaikan 95% dari usecases Anda_

@martpie Terima kasih atas tanggapannya, itulah yang saya lihat kemarin malam dengan komponen Link . Kemudian Next.js adalah campuran Server-Client yang saya inginkan.

Dan untuk komponen yang mengontrol secara terperinci rute bersarangnya sendiri secara dinamis, saya sangat menyukainya dengan React Router. Tapi saya cukup yakin saya bisa menyelesaikannya, karena saya tidak mengubah situs web React menjadi Next.js, melainkan merencanakan dan menguji untuk mengubah situs web JS - jQuery menjadi aplikasi multi halaman React tanpa kehilangan keunggulan SEO saya. di Google. Jadi saya pikir saya harus menggunakan Next.js

@timneutkens ada rencana untuk mendukung ini di Next.js 10?

@TrejGun terima kasih, itu pasti tidak keluar topik.

Punya rencana?
next/router bagus, memberikan banyak bantuan. Tetapi kami membutuhkan router yang lebih profesional untuk menangani aplikasi yang kompleks. React-router adalah pemimpin dalam router.
Mungkin bisa merujuk ke after.js .

Ya, sistem berbasis halaman ini tidak cukup canggih untuk menangani aplikasi berbasis data kompleks yang dapat memanfaatkan rute bersarang.

React-router akan meluncurkan versi v6 , yang akan menjadi router terbaik saat ini. Saya menantikan next.js mendukungnya.

Pendekatan yang lebih baik adalah dengan memisahkan next.js dan router , sehingga memungkinkan orang untuk memilih router favorit mereka dengan bebas.

1 untuk komentar sebelumnya. next.js luar biasa satu-satunya alasan saya tidak menggunakannya adalah kurangnya fleksibilitas pada Router. Harap dukung React Router 6 di rilis mendatang atau buat router dapat ditukar.

Orang-orang yang sangat tertarik dengan React Router mungkin tertarik untuk mengikuti proyek baru "Remix", ini adalah alternatif Next.js yang menggunakan React Router, oleh pembuat yang sama:

• https://twitter.com/remix_run/status/1253043162714525696
• https://remix.run

Saya pikir masalahnya adalah kerangka kerja sangat terkait dengan router itu karena SSR, Server Side Props dll ....

Selanjutnya dibangun dengan mempertimbangkan kinerja, dan react-router sisi server memiliki implikasi kinerja yang besar di mana Anda harus berjalan di pohon DOM sebelum Anda tahu apa yang akan Anda coba render, dan dengan demikian data apa yang Anda perlukan. Seluruh tujuan dari getInitialProps adalah agar Anda tidak perlu melakukan render sekali pakai untuk bereaksi sebelum mengambil data, kesalahan umum yang dialami banyak kerangka kerja di server (dan di klien, di mana ia bermanifestasi sebagai meminta air terjun). Selanjutnya berpotensi menyiasati hal ini dengan meminta setiap halaman tingkat atas mendeklarasikan _all_ dari berbagai pola data yang mungkin dibutuhkan oleh berbagai sub-komponen dan bercabang di jalur permintaan lengkap (atau melakukan pengambilan berlebihan tunggal yang besar), tetapi ini akan menjadi berat dengan cepat dan sebenarnya tidak akan jauh berbeda dengan mendeklarasikan setiap halaman satu per satu.

Ini adalah alasan yang sama bahwa Relay juga tidak kompatibel dengan react-router, dan Anda tidak dapat menuduh facebook.com sebagai situs web yang kompleks.

Strategi sukses utama untuk bekerja dengan router Berikutnya adalah condong ke komposabilitas (yang merupakan tren pendorong dalam React modern), memungkinkan Anda untuk menggunakan kembali komponen tanpa duplikasi besar sementara juga memiliki SSR efisien yang dapat mengambil semua datanya (melalui getInitialProps ) sebelum berbicara dengan pembuat React.

Saya merasa seolah-olah hukuman kinerja berjalan di pohon terlalu dilebih-lebihkan. Banyak aplikasi produksi saat ini melakukan ini dengan mis. Apollo dan tampaknya baik-baik saja.

Selain itu, Anda juga dapat menyimpan respons Anda dalam cache CDN jika Anda benar-benar ingin meringankan server dari melakukan terlalu banyak pekerjaan.

Tentu, saya hanya menunjukkan alasan utama di balik mengapa react-router (AFAICT) pada dasarnya tidak kompatibel dengan Next dalam implementasinya saat ini. Banyak situs tidak benar-benar membutuhkan kinerja sama sekali, sebagaimana dibuktikan oleh orang-orang dengan senang hati menggunakan Heroku dynos gratis dengan waktu mulai dingin yang lambat (dan saya ingin menekankan bahwa saya tidak mengatakan ini dengan merendahkan karena saya melakukan ini untuk beberapa situs juga dan itu bisa menjadi pasangan yang sempurna). Tetapi Next tidak akan populer dengan beberapa perusahaan besar yang menggunakannya jika kinerjanya kurang agresif karena perusahaan tersebut akan peduli tentang waktu respons server mereka yang jauh lebih lambat. Jika ini bukan masalah untuk beberapa situs, orang tidak akan menggunakan (dan dengan penuh semangat menunggu peningkatan) perender streaming React untuk mulai merespons bahkan sebelum satu render selesai, apalagi dua.

Anda pasti dapat CDN menyimpan tanggapan Anda, tetapi itu menghilangkan banyak pilihan personalisasi / masuk (karena ini adalah trade-off dengan seberapa rendah Anda ingin mendorong tingkat klik atau menunda rendering halaman parsial ke klien). Jika Anda dapat menyimpan CDN ke seluruh aplikasi Anda, Anda mungkin lebih baik menggunakan CRA dan react-snapshot dan menghindari server sepenuhnya. Ini belum tentu pertanyaan tentang seberapa banyak pekerjaan yang dilakukan server Anda, melainkan berapa lama waktu yang dibutuhkan untuk menanggapi permintaan.

Dan Apollo adalah contoh bagus dari kerangka kerja yang menekankan kemudahan penggunaan daripada kinerja, dibandingkan dengan kerangka kerja yang lebih beropini / berorientasi kinerja seperti Relay. Itu semua spektrum.

Ya, saya rasa itu cukup adil. Tapi saya penasaran untuk melihat bagaimana remix.run ternyata, mungkin mereka akan datang dengan pendekatan baru untuk membuatnya bekerja dengan react-router . Ya, memang benar bahwa rute bersarang tidak wajib, tetapi tentunya Anda harus setuju bahwa lebih intuitif memiliki bit UI bagian dalam yang berubah dengan rute, daripada memiliki halaman yang berbeda dan membungkus setiap halaman tersebut dengan tata letak yang berbeda.

Mulai 9.3 berikutnya, ada getStaticPaths selain getServerSideProps untuk membantu kerangka kerja menemukan jalur untuk melakukan pra-render ketika jalur tersebut memiliki parameter rute. Mungkin pendekatan serupa dapat diambil dengan react-router.

@merryweather : "Next dibangun dengan mempertimbangkan kinerja, dan react-router sisi server memiliki implikasi kinerja yang besar di mana Anda harus berjalan di pohon DOM sebelum Anda tahu apa yang akan Anda coba render"

Pertanyaan naif: Bisakah Anda merender tautan tingkat atas dan mengambil / prefetch / cache setelah kode berjalan di klien. Jika Anda tidak tahu ke mana klien akan menavigasi, apakah masuk akal untuk melintasi pohon DOM di server?

Skenario kerja naif: ketika klien meminta URL, cukup render tautan tingkat atas dan konten tautan aktif default dan ajax / ambil semua yang lain berdasarkan permintaan (atau sangga di latar belakang setelah halaman dimuat) ... yang lainnya mencakup semua tingkat yang lebih rendah rute ... bilas dan ulangi ...?

@ laurencefass tetapi bahkan tautan tingkat atas ada dalam kode dan harus ditemukan bukan? Atau apakah Anda bermaksud menggunakan perutean sistem file bersama react-router sehingga tautan tingkat atas dapat ditemukan?

@ avin-kavish Saya bukan orang terbaik untuk menjawab rincian tentang implementasi tetapi pada klien hanya perlu membuat konten layar awal: tautan tingkat atas + konten default. Ada lagi yang mubazir pada pemuatan pertama saya pikir. Jadi mengapa menjalankan DOM di server?

Masalah utama dengan Next.js bukanlah router, itu pola pengambilan data dengan getInitialProps , getServerProps atau getStaticProps . Kenapa? Karena itu merusak isolasi data untuk komponen yang membutuhkannya. Misalnya, Anda ingin mendapatkan data untuk menu, dari mana Anda akan mengambilnya? Saya tidak tahu. Komponen teratas seperti pages seharusnya tidak tahu apa-apa tentang itu, bukan?

Masalah utama dengan Next.js bukanlah router, itu pola pengambilan data dengan getInitialProps , getServerProps atau getStaticProps . Kenapa? Karena itu merusak isolasi data untuk komponen yang membutuhkannya. Misalnya, Anda ingin mendapatkan data untuk menu, dari mana Anda akan mengambilnya? Saya tidak tahu. Komponen teratas seperti pages seharusnya tidak tahu apa-apa tentang itu, bukan?

Tolong jelaskan. Dan apa solusi alternatifnya?

@lishine Saya minta maaf karena sedikit keluar dari topik di sini, tetapi dalam banyak kasus saya tidak melihat Router adalah masalah utama di sini. Router next.js bagus, deklaratif, konvensi atas konfigurasi bagus. Satu-satunya hal yang tidak dapat saya gunakan di Next.js adalah metode pengambilan data seperti getInitialProps , ...
Di aplikasi saya, setiap komponen perlu mendeklarasikan datanya sendiri tepat di tempat yang sama, di file yang sama, apa pun itu graphql atau rest.
Komponen halaman atas hanya untuk menyusun komponen anak, dan mengambil data bukanlah tugasnya. Komponen anak harus mendapatkan datanya sendiri, bukan orang tuanya.

Berikut contoh kode yang saya gunakan untuk aplikasi saya agar lebih jelas:

const query = `
{
  result:users(
    where:{
      _and:[{
        active:{
          _eq:true
        }
      }, {
        is_exam_manager:{
          _eq:true
        }
      }]
    },
    order_by:{
      created_at:desc_nulls_last
    }
  ){
    id
    key:id
    user_code
    first_name
    last_name
    password
    active
  }
}
`
const Main = (props: any) => {
  const {
    data: { result }
  } = props
  return (
    <div>
      <Add title={'Add user'} role={'exam_manager'} />
      <Table
        columns={columns}
        dataSource={result}
        bordered={true}
        size={'small'}
      />
    </div>
  )
}
const MainWithData = graphql(query)(Main)
export default MainWithData

Seperti yang Anda lihat, Anda memiliki satu komponen dengan datanya sendiri. Anda bisa meletakkannya di mana pun Anda mau.

Tentu saja, Anda dapat menggunakan pola Next.js tanpa masalah, tetapi dalam kasus saya, saya lebih suka isolasi data dan komponen sebanyak mungkin untuk memudahkan pemeliharaan dan pemfaktoran ulang nanti.

Di aplikasi saya, setiap komponen perlu mendeklarasikan datanya sendiri tepat di tempat yang sama, di file yang sama, apa pun itu graphql atau rest.
Komponen halaman atas hanya untuk menyusun komponen anak, dan mengambil data bukanlah tugasnya. Komponen anak harus mendapatkan datanya sendiri, bukan orang tuanya.

Saya menggunakannya dengan cara yang sama.
Jadi Anda tidak menggunakan pengambilan SSR ...
Lalu bagaimana sebenarnya orang-orang melakukan pengambilan SSR dengan Next.js?!

@linshine kita harus mengunduh apa pun yang kita butuhkan di tingkat halaman teratas.

@lishine Saya minta maaf karena sedikit keluar dari topik di sini, tetapi dalam banyak kasus saya tidak melihat Router adalah masalah utama di sini. Router next.js bagus, deklaratif, konvensi atas konfigurasi bagus. Satu-satunya hal yang tidak dapat saya gunakan di Next.js adalah metode pengambilan data seperti getInitialProps , ...
Di aplikasi saya, setiap komponen perlu mendeklarasikan datanya sendiri tepat di tempat yang sama, di file yang sama, apa pun itu graphql atau rest.
Komponen halaman atas hanya untuk menyusun komponen anak, dan mengambil data bukanlah tugasnya. Komponen anak harus mendapatkan datanya sendiri, bukan orang tuanya.

Berikut contoh kode yang saya gunakan untuk aplikasi saya agar lebih jelas:

...

Seperti yang Anda lihat, Anda memiliki satu komponen dengan datanya sendiri. Anda bisa meletakkannya di mana pun Anda mau.

Tentu saja, Anda dapat menggunakan pola Next.js tanpa masalah, tetapi dalam kasus saya, saya lebih suka isolasi data dan komponen sebanyak mungkin untuk memudahkan pemeliharaan dan pemfaktoran ulang nanti.

@ revskill10 Mengapa Anda tidak dapat meminta anak mendeklarasikan fragmen datanya dan kemudian meminta induknya menyertakan fragmen tersebut dalam kueri tingkat atas? Terutama saat Anda membuat lebih banyak fragmen terkait anak, Anda memiliki isolasi data yang sempurna. Memiliki kueri induk dengan fragmen turunan tidak berbeda dengan deklarasi turunan tersebut di JSX, jadi Anda memiliki tingkat penggandengan yang sama tetapi menghindari air terjun permintaan (sayangnya, jauh lebih sulit di REST).

Kami memiliki aplikasi Relay-Next dan pola ini bekerja dengan sempurna, dengan enkapsulasi data dan komposisi yang dapat digunakan kembali, dan kami memanfaatkan getInitialProps dengan mudah.

@merrywhether Belum lagi tentang much harder in REST , pendekatan Anda memiliki masalah yaitu, Anda tidak dapat memutuskan fragments akan menjadi SSG / SSR atau yang akan menjadi CSR.
Dalam pendekatan saya, semudah mengimpor komponen itu dengan { noSSR: true/false} .

Saya menemukan lock-in ke pustaka perutean khusus vendor yang tidak berbagi implementasi yang mendasari dengan pustaka perutean utama mana pun menjadi sangat memprihatinkan.

Saya baru-baru ini melakukan peninjauan terhadap Next.js untuk mengevaluasi apakah itu harus digunakan sebagai basis untuk inti bersama yang dibagi antara sejumlah aplikasi frontend yang sedang dibangun untuk klien kami saat ini. Sedangkan Next.js memiliki potensi; router ini adalah salah satu alasan utama saya akhirnya menolak Next.js dan malah menyimpan CRA sebagai basis untuk aplikasi ini.

Saya memahami kesulitan menggunakan API tingkat atas berbasis komponen react-router / @reach/router sebagai dasar untuk SSR. Tetapi itu bukan alasan yang baik untuk penerapan yang mendasarinya sepenuhnya sesuai kebiasaan. SSG Gatsby memiliki masalah yang sama dengan Next.js dan struktur perutean berbasis file yang semi-serupa; tetapi menurut pemahaman saya, Gatsby menggunakan @reach/router untuk menjalankan implementasi peruteannya alih-alih menciptakan kembali roda atau mengekspos API Tautan yang tidak sesuai dengan API Tautan yang digunakan oleh perpustakaan lain.

@dantman bolehkah saya bertanya apa yang Anda pilih untuk alternatif Next.js. Dengan asumsi Anda membutuhkan rendering sisi server .... Saya telah mencoba After.js mungkin dapat memberikan beberapa inspirasi / ide bagaimana menerapkan di Next.js jika tidak didukung oleh zeit.

@dantman bolehkah saya bertanya apa yang Anda pilih untuk alternatif Next.js. Dengan asumsi Anda membutuhkan rendering sisi server .... Saya telah mencoba After.js mungkin dapat memberikan beberapa inspirasi / ide bagaimana menerapkan di Next.js jika tidak didukung oleh zeit.

Maaf, saya tidak punya jawaban yang berguna untuk Anda. SSR bukanlah persyaratan yang sulit jadi kami terus menggunakan CRA, yang menjadi dasar pembuatan prototipe tersebut.

Saya pikir Next.js memiliki janji sebagai kerangka universal karena baru-baru ini memperoleh kemampuan untuk memiliki campuran halaman SSR / SSG / khusus klien dan dapat dijalankan sebagai aplikasi isomorfik atau sebagai aplikasi statis / PWA. Kustomisasi WebPack menggoda karena CRA telah menggunakan kompilator globalisasi yang sulit. Server Next.js adalah netral / positif karena kami membutuhkan server API untuk jembatan GraphQL / REST. Dan opsi SSR / SSG adalah hal yang positif karena saya sedang membangun inti yang akan menjadi dasar bagi setengah lusin aplikasi dan bukan tidak mungkin itu akan berguna di masa depan. Namun saya juga memiliki beberapa masalah dengan cara kerja SSR Next.js dan hal-hal positif ini tidak sebanding dengan masalah yang disebabkan oleh router.

@santrikece

Saya menemukan lock-in ke pustaka perutean khusus vendor yang tidak berbagi implementasi yang mendasari dengan pustaka perutean utama mana pun menjadi sangat memprihatinkan.

Cukup aneh untuk mengkualifikasikan komponen open source dengan API yang tidak berubah dalam 3 tahun karena stabilitasnya yang hebat dan "kesesuaian produk / pasar" sebagai "lock-in"

Next.js telah berhasil dan terus menunjukkan pertumbuhan yang dilakukannya karena routernya dan bukan terlepas dari itu.

Seperti banyak yang telah melihat saya berkomentar di Twitter, suatu ketika kami dengan serius menghibur penggabungan di beberapa router (meskipun saya bingung mana yang standar dalam pikiran Anda, Reach atau React Router, dan versi utama apa). Tapi dunia menarik kita ke arah lain yang menarik. Pada kenyataannya, kami bahkan tidak tahu apa gunanya menambahkannya, karena semua orang terus berhasil dengan Next.js dan membuat produk yang luar biasa.

Ketika saya benar-benar akan bertanya kepada orang-orang mengapa mereka menginginkan API router yang berbeda, alasan yang paling sering muncul adalah karena orang-orang terjebak dan frustrasi dengan solusi kerangka kerja yang dikembangkan di rumah yang dibangun di atas router, dan mereka tidak sabar untuk bermigrasi ke Next . Itu bukanlah alasan yang berakar pada desain produk.

Ketika saya mengatakan bahwa Next berhasil karena itu router, itu karena itu menghilangkan dua masalah:
1️⃣ Ide harus memilih router . Kami menghapus ini adalah mengingat kembali keputusan yang sangat baik. Selama Next.js dengan router stabilnya ada, dunia router telah terpecah dan meluncurkan semua jenis perubahan API

2️⃣ Kurva pembelajaran router . Banyak lokakarya dan tutorial telah diberikan tentang perutean, tetapi perutean sistem berkas Next.js membutuhkan 2 detik penjelasan dan memberi Anda platform untuk membangun hal-hal luar biasa, dan Anda langsung beralih ke pengembangan produk

Saya ingin menekankan poin terakhir ini. Pertimbangkan salah satu situs web terbaru dan paling cepat berkembang di dunia, TikTok.com, dibangun di Next.js. Seluruh topologi perutean situs web itu dapat dijelaskan dengan kurva pembelajaran dua detik itu. https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 adalah pages/[user]/video/[id].js dan https://www.tiktok.com/trending pages/trending.js

Banyak dari inovasi Next.js terbaru yang Anda sebutkan Anda sukai, seperti hybrid static / SSG / SSR, juga diaktifkan oleh desain router kami. Faktanya, router juga akan mengaktifkan banyak pengoptimalan serupa lainnya yang akan datang di masa mendatang untuk mengirimkan lebih sedikit JS ke klien.

Namun saya juga memiliki beberapa masalah dengan cara kerja SSR Next.js dan hal-hal positif ini tidak sebanding dengan masalah yang disebabkan oleh router.

Akan sangat senang mendengar tentang ini. Contoh di atas didukung oleh Next.js hybrid static / SSR dan kami melihat banyak kesuksesan dengannya!

Ini adalah utas yang lucu. Berikutnya memiliki alasan konkret untuk menghindari perutean air terjun (alias react-router dan teman-teman) karena getInitialProps memungkinkan banyak pengoptimalan kinerja, dan pendekatan Next ternyata cukup populer, terutama karena beberapa orang secara khusus menginginkan pengoptimalan tersebut. Performa datang dengan pengorbanan desain, dan terkadang Anda mungkin lebih suka memilih desain daripada performa, tetapi itu tidak membuat alat salah, hanya salah untuk proyek tertentu.

Pada akhirnya, react-router bukanlah solusi perutean yang serba bisa. Ini memiliki pro dan kontra, seperti halnya Next. FWIW, Facebook tidak menggunakan react-router, dan mereka mungkin tahu satu atau dua hal tentang penggunaan React. Jadi tidak masalah untuk memiliki alternatif, dan sebenarnya salah satu hal hebat tentang ekosistem JS: biarkan berbagai hal bersaing dalam arena ide dan pada akhirnya kita semua bergerak maju.

Karena saya menutup masalah ini, saya ingin menjelaskan bahwa kami selalu terbuka untuk komentar, permintaan fitur, dan laporan bug pada kemampuan perutean.

Idealnya, hal itu akan didorong oleh produk ("Saya perlu melakukan X tetapi tidak mungkin" atau "Y mungkin tetapi tidak ergonomis"). Kami selalu mencari peningkatan yang membantu Anda membuat situs web dan aplikasi lean dengan pengalaman pengguna yang luar biasa 🤗

@rauchg Dapatkah Anda menjelaskan alasan di balik memiliki dua properti, href dan as ke sebuah tautan? Mengapa tidak dapat menyimpulkan halaman yang dimaksud berdasarkan nilai dari as prop?

Misalnya dalam ekspres jika saya memiliki rute sebagai /blog/:slug , saya hanya dapat mengirim permintaan http ke /blog/hello-world dan mengharapkan router untuk mengarahkan ke sana. Saya tidak perlu mengirim /blog/:slug dan blog/hello-world ke server.

@ avin-kavish itu pertanyaan yang bagus. Ada perbedaan penting yang harus dibuat antara apa yang ditampilkan URL dan halaman mana yang akan dimuat. Faktanya TikTok menggunakannya untuk merender hal-hal tertentu dalam bentuk modals, yang ketika Anda me-refresh halaman menjadi halaman lain. Namun, satu area perbaikan besar di sini adalah bahwa kami mungkin harus memaksakan secara statis bahwa Anda mereferensikan halaman valid yang ada di sistem file. Kami akan menindaklanjuti dengan membuat Diskusi tentang ini dan menandai Anda!

Saya pikir masalah sudah ada untuk https://github.com/zeit/next.js/issues/8207 itu

Jika seseorang melihat masalah ini untuk fitur react-router seperti "rute bersarang" yang memungkinkan menavigasi ke halaman baru tanpa merender ulang semua seperti saya, sebenarnya ada masalah khusus yang dapat Anda perhatikan dan pilih. Saya baru tahu tentang itu: https://github.com/zeit/next.js/issues/8193

@rachmawati

Untuk menjadi jelas dalam hal ini masalah utama saya bukanlah kurangnya komponen API RR / jangkauan gaya, aku baik-baik dengan file yang mampu SSR / config berdasarkan API. Meskipun saya sedikit optimis bahwa di masa mendatang Suspense dapat membuat API SSR / perutean alternatif dapat digunakan. Masalah utama saya adalah router sepenuhnya disesuaikan dengan masalah umum dalam implementasi yang diimplementasikan kembali alih-alih dibagikan dengan bagian mana pun dari komunitas React yang lebih luas.

Saya menemukan pendekatan Gatsby dapat diterima. Mereka memiliki file yang mampu SSG + API perutean berbasis konfigurasi dan mengekspor komponen Tautan mereka yang ditingkatkan; tetapi mereka menggunakan @reach/router untuk menjalankan implementasi yang mendasarinya.

Saya menemukan lock-in ke pustaka perutean khusus vendor yang tidak berbagi implementasi yang mendasari dengan pustaka perutean utama mana pun menjadi sangat memprihatinkan.

Cukup aneh untuk mengkualifikasikan komponen open source dengan API yang tidak berubah dalam 3 tahun karena stabilitasnya yang hebat dan "kesesuaian produk / pasar" sebagai "lock-in"

Router secara intrinsik terikat ke Next.js. Mengadopsi Next.js karena satu alasan berarti terikat ke router. Jika kita mengadopsi Next.js dan kemudian menemukan bahwa next / router memiliki batasan yang ternyata melumpuhkan sesuatu yang kita coba lakukan, sama sekali tidak ada jalan keluar yang masuk akal. "Lock-in" adalah keterangan yang sangat bagus untuk itu.

Terkunci saja tidak akan menjadi masalah besar. Penggunaan Gatsby atas @reach/router juga akan terkunci. Tapi @reach/router digunakan di luar hanya Gatsby. Saya tidak harus mempercayai komunitas Gatsby sendiri untuk memelihara seluruh tumpukan router; Saya dapat percaya bahwa komunitas yang lebih besar bergantung padanya dan ada lebih banyak pemangku kepentingan yang terlibat (khusus untuk tumpukan perutean) untuk memastikannya dipertahankan, mengikuti masalah perutean yang sulit (misalnya aksesibilitas), dan bergantung pada komunitas yang lebih bervariasi dan lebih luas yang kemungkinan besar akan berbagi masalah yang berpotensi melumpuhkan yang dapat kami temui di masa mendatang.

meskipun saya bingung mana yang standar dalam pikiran Anda, Reach atau React Router, dan versi utama apa

Dalam hal standar de-facto seperti apa seharusnya <Link> . Baik Reach dan React Router (RR) berbagi API yang sangat mirip. misalnya <Link to='/about'>About</Link> berlaku baik di RR dan Jangkauan (dan tentu saja dengan ekstensi Gatsby). Yang membuat istimewa Next.js <Link href='/about'><a>About</a></Link> jauh lebih menggelegar.

Dalam hal apa yang menurut saya harus digunakan Next.js. Saya tidak terikat ke pustaka tertentu, jika Next.js sudah menggunakan satu, saya tidak akan menyarankan beralih ke pustaka lain. Perhatian utama saya adalah bahwa implementasi perutean dibagikan dengan perpustakaan dengan komunitas yang lebih luas di luar Next.js.

Namun dalam praktiknya itu relatif bisa diperdebatkan. Sejauh ini saya belum melihat router React selain RR dan Reach dengan basis pengguna yang besar. Dan RR dan Jangkauan akan menjadi satu perpustakaan, jadi mana pun yang Anda mulai dengan hasil akhirnya akan sama.

Saya mencoba Next beberapa waktu yang lalu tetapi kurangnya fleksibilitas pada router membuat saya menemukan implementasi Razzle yang disebut After.js https://github.com/jaredpalmer/after.js?utm_source=hashnode.com.

Karena React Router hanyalah sebuah paket, bisakah kita tidak mengimpornya dan membatasi rendering ke sisi klien saja sehingga berfungsi seperti SPA di mana diperlukan dan memberi kita rute komponen bersarang? Bukankah router React hanyalah seperangkat komponen yang akan (berpotensi) disematkan di halaman dan dimuat dengan router halaman Next.js seperti komponen lainnya?

Saya membaca di utas sebelumnya bahwa zeit berencana untuk mengintegrasikan RR, apakah itu masih berlaku hari ini?

Mengapa kita tidak mengizinkan rute bersarang di router next.js sebagai upaya terakhir dan memperjelas bahwa area ini tidak akan dirender sebelumnya. Paling tidak, ini akan menghemat usaha kita untuk menghindari penulisan kondisi if yang harus kita tulis ketika kita ingin sub-sumber daya di halaman berubah berdasarkan rute.

Saya menambahkan suara saya tentang masalah ini.

Pro lain, tidak disebutkan, adalah bahwa RR lebih dapat diuji, (AFAIK tidak ada API nextjs resmi untuk pengujian router), ia memiliki MemoryRouter untuk membungkus tes dan cerita.

Next.js memiliki banyak fitur bagus (WebPack otomatis, file statis, dan TypeScript seperti CRA tetapi lebih dari sekadar PWA; rute API; dukungan tanpa server, Penyegaran Cepat, dan bahkan dukungan Eksperimental Eksperimental untuk aplikasi web + asli) dan inti untuk SSR dan SSG meskipun API-nya tidak bagus. Tetapi sementara sistem perutean bawaan dan SSR / SSG berfungsi untuk beberapa; bagi yang lain, mereka membuat pengembangan terpincang-pincang karena batasan dari kedua API menawarkan trade-off yang salah untuk proyek tersebut.

Bagaimana dengan kompromi. Next.js sudah memiliki plugin. Alih-alih mengganti router secara internal bagaimana jika kita memisahkan router dan SSR API (yaitu getStaticProps / getServerSideProps dalam file rute) dari inti Next.js. misalnya kita dapat meletakkan bagian inti yang paling mendasar di @next/core dan memindahkan router yang sekarang ini dan get*Props API ke @next/router . Untuk kesederhanaan dan kompatibilitas mundur next bisa menjadi kerangka kerja yang mengekspor ulang @next/core dan telah dikonfigurasi sebelumnya dengan router pilihan Vercel. Tapi kemudian akan mungkin bagi komunitas mengembangkan router dan SSR / SSG API dengan trade-off berbeda yang lebih cocok untuk proyek yang jika tidak akan terjebak membuang bagian baik Next.js dengan air mandi.

Beberapa pemikiran tentang apa inti Next.js akan membutuhkan plugin router untuk menyediakan:

• Dengan adanya permintaan {url, body, etc}, inti akan mengharapkan plugin router untuk merender permintaan ini ke dokumen (string atau streaming) atau melontarkan respon (yaitu 404 atau redirect).
• Saat mengekspor, inti mengharapkan plugin router menyediakan daftar halaman yang perlu dirender.

@next/router mungkin akan menerapkan pola yang sama melalui api dengan melakukan hal-hal seperti:

• Diberikan permintaan, mengidentifikasi file rute yang bertanggung jawab dan rendering seperti biasa
• Pada klien yang melakukan sesuatu yang mirip dengan apa pun yang dilakukannya saat ini untuk mengetahui kapan harus memanggil API SSR dan merender rute yang dibutuhkannya (mungkin memindahkan API SSR berbasis API ke rute API yang tampak normal)
• Saat mengekspor menggunakan pohon file halaman dan getStaticPaths untuk menyediakan daftar halaman statis

Saya mungkin bisa melihat diri saya bereksperimen dengan plugin router menggunakan React Router v6 dengan @apollo/react-ssr dan Suspense dengan react-ssr-prepass atau react@experimental . Yang melupakan rute khusus SSR untuk rute SSR isomorfik dan mengimplementasikan SSR / SSG tanpa batasan API gaya get*Props .

Apa yang saya sadari adalah, perutean bersarang + SSG dapat dicapai tanpa merusak API saat ini. Jadi kami memiliki getStaticPaths saat ini, kami dapat menggunakannya untuk memberi petunjuk pada rute bersarang untuk pra-rendering. Sebagai contoh,

Diberikan rute /foo/[...slug] ,

function FooPage() {

  return (
      <Switch>
          <Route path="/foo/bar">
              <SomeResource />
              <Route path={`${parenthPath}/baz`} component={SomeSubResource} />
          </Route>
          .... more routes
      </Switch>
  )
}

dapat di-render dengan,

export async function getStaticPaths() {

  return {
    paths: [
      { slug: [ 'bar' ] },
      { slug: [ 'bar', 'baz' ] },
    ],
  }
}

Dengan cara yang saat ini next.js seperti framework sisi server dengan kemudahan membuat halaman secara bereaksi. Rasanya tidak sekuat react-router . Perutean berbasis direktori mungkin memiliki tempatnya dalam membangun situs yang dihadapi konsumen seperti tiktok seperti yang disebutkan sebelumnya, tetapi untuk portal aplikasi berbasis data yang kompleks, perutean bersarang masih menjadi raja. Itulah mengapa aplikasi satu halaman dibuat di tempat pertama, memungkinkan untuk mengubah bit UI tanpa harus mengganti seluruh halaman. Ini dapat dimanfaatkan untuk memodelkan hubungan sumber daya-sub-sumber dengan cukup mudah. Seperti berdiri, saya dapat menggunakan next.js jika saya membangun halaman publik dari situs konsumen seperti situs e-commerce tetapi ketika saya perlu membangun area pribadi seperti admin, portal pembeli & penjual, saya akan beralih ke CRA.

@ avin-kavish masalah utamanya bukanlah membuatnya berfungsi, tetapi membuatnya dioptimalkan: setiap halaman di default Next.js memiliki bundelnya sendiri dan dioptimalkan untuk kecepatan.

Jika Anda mulai menambahkan banyak konten / sub-konten dalam satu halaman seperti yang Anda lakukan, Anda bisa mendapatkan bundel yang cukup besar pada akhirnya (yang sebenarnya tidak "buruk", tetapi Anda hanya perlu menyadari trade-off). Anda mungkin dapat melakukan beberapa pengoptimalan manual dengan next/dynamic pemikiran :)

@rauchg satu-satunya dimensi bukanlah apakah router berikutnya baik atau buruk. Hal lain yang sangat penting adalah migrasi ke dan dari next.js serta dukungan komunitas, dan https://github.com/vercel/next.js/issues/1632#issuecomment -633310614 menjelaskannya dengan baik. Next.js adalah solusi yang bagus untuk mengabstraksi banyak boilerplate yang dibutuhkan oleh aplikasi SSR berkualitas tinggi, dan karena itu, ini merupakan target migrasi yang sangat mengundang untuk banyak aplikasi web. Masalahnya sekarang adalah bahwa itu akan membutuhkan penulisan ulang perutean lengkap baik untuk bermigrasi ke next.js, dan keluar darinya jika diperlukan.

Perutean yang dapat dicolokkan yang disarankan oleh

Masalah dengan react-router (dan solusi perutean bersarang) adalah membuat analisis statis jauh lebih sulit karena jalur kode yang relevan untuk URL tertentu tidak tersedia tanpa menjalankan (atau mensimulasikan) kode itu sendiri. Berikutnya lebih dari sekadar kerangka kerja "letakkan UI di halaman web", itulah sebabnya, misalnya, mereka bekerja dengan tim Chrome untuk membuat strategi bundling yang lebih dioptimalkan.

Pengguna react-router terbiasa menggunakan react-loadable secara langsung karena ia mendelegasikan tanggung jawab itu sepenuhnya kepada pengguna akhir, tetapi Next mencoba untuk mengabstraksi dan mengotomatiskan ini yang tidak mudah. Pendekatan router yang dapat dicolok yang diusulkan mungkin harus melibatkan plugin router yang menyediakan informasi waktu build yang luas ke kerangka kerja untuk mencapai jenis output yang sama, karena setiap router harus mengetahui cara menghasilkan informasi tersebut berdasarkan polanya sendiri.

Murni spekulasi, tapi saya membayangkan banyak hal dalam ketidakpastian sementara React menyelesaikan Suspense, karena membuat pola kelas pertama di perpustakaan akan sangat mempengaruhi semua perpustakaan router dan juga memberikan dasar konkret untuk membangun async / loadable pola bundel.

Singkat cerita / ringkasan yang bagus di bawah ini: Tidak ada yang namanya "solusi satu ukuran untuk semua". Semuanya ada trade-off. Setiap "keuntungan" dari cara Next.js saat ini melakukan segala sesuatunya memiliki kerugian. Apa kelebihan / kekurangan yang terpenting adalah sesuatu yang berbeda untuk setiap proyek. Oleh karena itu, rekomendasi untuk arsitektur router / ssg / ssr yang dapat dicolokkan. Proyek yang berbeda memerlukan hal yang berbeda dan saat ini Next.js hanya bekerja untuk proyek yang prioritasnya pada trade-off sejalan dengan cara hal-hal di-hardcode di Next.js.

Masalah dengan react-router (dan solusi perutean bersarang) adalah membuat analisis statis jauh lebih sulit karena jalur kode yang relevan untuk URL tertentu tidak tersedia tanpa menjalankan (atau mensimulasikan) kode itu sendiri.

Sejujurnya itu hanya penting jika Anda menggunakan SSG dan memiliki banyak rute non-dinamis. Jika semua rute Anda SSG atau khusus klien, itu tidak berguna. Dan jika sebagian besar rute Anda dinamis maka Anda harus secara eksplisit menyatakannya menggunakan getStaticPaths . Yang akan sama dengan jumlah pekerjaan yang secara eksplisit mendefinisikan rute dalam plugin Next.js hipotetis yang hanya menggunakan react-router mentah tanpa modifikasi dan meminta Anda untuk secara eksplisit menentukan rute statis.

Ini adalah keuntungan pasti, dan beberapa tim akan menginginkan itu. Namun itu hanya satu subkelompok pengguna Next.js potensial. Ada grup lain yang mungkin menginginkan beberapa keuntungan yang disediakan RR atau pustaka perutean lain dan kebutuhan untuk secara eksplisit menyatakan rute statis adalah tradeoff yang dapat diterima atau bukan masalah. Misalnya, beberapa proyek terakhir saya adalah jenis aplikasi B2B / B2C di mana 100% hal berada di belakang halaman login dan tidak ada gunanya merender semua itu secara statis. Next.js memiliki beberapa keunggulan dibandingkan CRA yang akan membuat Next.js lebih disukai; Tetapi hal-hal seperti router adalah tanda bahaya besar dan kami terus menggunakan CRA. Proyek-proyek itu akan sangat cocok untuk Next.js dengan react-router mentah.

Ini juga mengasumsikan bahwa setiap orang yang tidak menginginkan next/router ingin menggunakan bentuk react-router JSX. Itu bukan satu-satunya jenis alternatif next/router .

Salah satu jenis router lainnya adalah gaya Gatsby.js. Di mana proyek masih menggunakan struktur halaman berbasis sistem file, tetapi internal diimplementasikan dengan pustaka perutean lain seperti react-router (Gatsby menggunakan @reach/router internal). Jenis plugin router ini akan memberi Anda keuntungan analisis statis yang sama. Tetapi itu juga akan memberi Anda keuntungan apa pun yang tidak dimiliki router alternatif terkait dengan perutean bersarang. misalnya Mengakomodasi preferensi potensial untuk API rute, penanganan aksesibilitas yang lebih baik, integrasi yang lebih baik ke dalam ekosistem di sekitar router itu.

Dan tentu saja bahkan dalam ekosistem react-router, bentuk JSX bukanlah satu-satunya cara untuk menggunakan react-router. Ada juga react-router-config . Yang mudah untuk melakukan analisis statis dan juga mendukung perutean bersarang.

Pengguna react-router terbiasa menggunakan react-loadable secara langsung karena ia mendelegasikan tanggung jawab itu sepenuhnya kepada pengguna akhir, tetapi Next mencoba untuk mengabstraksi dan mengotomatiskan ini yang tidak mudah.

Dan beberapa dari kita baik-baik saja dalam menangani pemecahan kode sendiri. Perutean bersarang bisa lebih penting untuk sebuah proyek daripada pemisahan kode otomatis. Ini semua tentang pertukaran mana yang paling cocok untuk sebuah proyek.

Ini lebih merupakan catatan tambahan, tetapi saya sebenarnya ingin tahu tentang potensi plugin babel / webpack yang akan melakukan ini secara otomatis untuk rute.

Juga react-loadable adalah pustaka yang tidak berfungsi secara efektif (2 tahun sejak dipublikasikan, tidak menerima laporan bug). Secara pribadi saya lebih suka melakukan pemisahan kode secara manual dengan @loadable/components daripada menggunakan sesuatu yang otomatis built-in ke Next.js berdasarkan garpu internal react-loadable.

Pendekatan router yang dapat dicolok yang diusulkan mungkin harus melibatkan plugin router yang menyediakan informasi waktu build yang luas ke kerangka kerja untuk mencapai jenis output yang sama, karena setiap router harus mengetahui cara menghasilkan informasi tersebut berdasarkan polanya sendiri.

Ya. Biasanya begitulah cara kerja sistem plugin. Sejujurnya, fakta bahwa informasi semacam ini dapat disediakan oleh plugin adalah keuntungan, bukan masalah. Memiliki ini di plugin berarti bahwa cara Next.js mengumpulkan informasi ini tidak sesuai untuk beberapa jenis kebutuhan proyek, itu dapat diganti dengan yang sesuai dengan kebutuhan proyek tersebut. Tetapi tanpa perlu bercabang dan menulis ulang semua Next.js untuk melakukannya.

Murni spekulasi, tapi saya membayangkan banyak hal dalam ketidakpastian sementara React menyelesaikan Suspense, karena membuat pola kelas pertama di perpustakaan akan sangat mempengaruhi semua perpustakaan router dan juga memberikan dasar konkret untuk membangun async / loadable pola bundel.

Ini sendiri sebenarnya bisa menjadi argumen yang cukup bagus untuk bekerja pada sistem router yang dapat dicolokkan. Saat ini karena semua hal perutean dan SSR di-hardcode ke Next.js, tidak mungkin untuk dengan mudah melakukan eksperimen ke semua jenis sistem perutean masa depan dalam Next.js. Bagaimana Suspense memengaruhi perutean Next.js dan pustaka perutean lainnya? Bukan sesuatu yang dapat Anda coba (setidaknya dalam hal SSR dan bundling Next.js) tanpa bercabang dan menulis ulang potongan Next.js.

Plugin router akan menjadi tempat yang tepat untuk melakukan eksperimen semacam ini. Selama API plugin berada pada level yang cukup rendah, maka dimungkinkan untuk hanya membayar plugin next/router dan mencoba menulis versi react @ eksperimental + berbasis Suspense dari router itu. Dan karena ini adalah plugin (bukan cabang dari semua Next.js), akan mudah untuk ikut serta dalam eksperimen dan menguji router berbasis Suspense yang baru. Hal ini penting sekarang daripada nanti karena jenis eksperimen ini adalah alasan mengapa react @ eksperimental ada, untuk mengumpulkan umpan balik dari proyek nyata.

@dantman Saya tidak setuju dengan apa pun yang Anda katakan. Ini semua tentang pertukaran. Pengorbanan terbesar adalah apa yang tim Berikutnya menghabiskan waktu mereka. Sejauh ini, SSR berperforma tinggi dengan konfigurasi rendah tampaknya telah menjadi fokus utama mereka. Saya mengerti bahwa ini tidak selalu relevan untuk semua pengguna, tetapi ini adalah sudut yang awalnya digunakan Next untuk menonjol (itulah sebabnya kami memilih mereka di tempat kerja). Mereka baru-baru ini menggali lebih banyak tentang SSG, tampaknya karena popularitas Gatsby dan Jamstack, tetapi mereka masih yang terbaik untuk SSR imo.

Sejujurnya itu hanya penting jika Anda menggunakan SSG dan memiliki banyak rute non-dinamis

Saya tidak yakin apa yang Anda maksud dengan ini, karena SSG vs SSR tidak terlalu penting untuk mencoba mengirimkan muatan JS sekecil mungkin untuk halaman pertama (JS "jalur kritis"), begitu juga dengan rute dinamis. Meminimalkan aset jalur kritis _is_ umumnya cukup penting untuk aplikasi SSR (dengan demikian semua upaya) jadi ini sangat dihargai. Dan sejujurnya, jika semua yang Anda buat adalah aplikasi CSR-berdinding login, maka Next _does_ memiliki banyak kelemahan dibandingkan dengan CRA (SSR tidak akan pernah senyaman CSR). Sepertinya Anda mendiskon aplikasi yang benar-benar melakukan runtime SSR (dengan penanganan login / personalisasi sisi server) khusus untuk kemenangan kinerja. Tidak semuanya cocok dengan dikotomi SSG vs CSR.

beberapa dari kita baik-baik saja dalam menangani pemecahan kode sendiri

Beberapa dari kita cukup mampu menangani sendiri webpack, react-dom / server, dll. Tujuan selanjutnya sejauh ini tampaknya membuat pengeluaran seperti itu semakin jarang dan langka seperti CRA. Dan Anda benar, saya seharusnya mengatakan react-loadable-alike, karena ada banyak solusi di ruang itu, dan mereka semakin eksotis dengan pola data-plus-code yang muncul dari perpustakaan seperti Relay.

Pada akhirnya, saya tidak setuju bahwa sistem router yang dapat dicolokkan mungkin bagus. Saya baru saja menunjukkan bahwa akan banyak pekerjaan bagi tim Berikutnya untuk menghapus hal-hal yang merupakan prinsip utama kerangka kerja (seperti logika pemecah-bundel) dan mengekstraknya menjadi arsitektur yang dapat dipasang. Dan spekulasi saya menyoroti fakta bahwa saya tidak ingin mulai merancang perubahan mendasar pada perpustakaan saya yang dapat dengan mudah diubah oleh perubahan mendatang pada ketergantungan inti saya. Saya tentu setuju bahwa beberapa aspek dari desain _are_ membatasi Next, tetapi untuk sebagian besar batasan tersebut masuk akal mengingat batasan desain mereka sejauh ini.

Sejujurnya itu hanya penting jika Anda menggunakan SSG dan memiliki banyak rute non-dinamis

Saya tidak yakin apa yang Anda maksud dengan ini, karena SSG vs SSR tidak terlalu penting untuk mencoba mengirimkan muatan JS sekecil mungkin untuk halaman pertama (JS "jalur kritis"), begitu juga dengan rute dinamis.

Kami mungkin memikirkan alasan berbeda mengapa kemampuan untuk menganalisis secara statis rute apa yang ada diperlukan. Dengan asumsi kita berdua berbicara tentang "analisis statis" sebagai "kemampuan untuk mengidentifikasi daftar rute (misalnya ['/about', '/', '/profile'] ) pada waktu pembuatan hanya dengan membaca kode".

Sepertinya Anda sedang berbicara tentang beberapa jenis pengoptimalan bundel JS? Yang saya belum menemukan informasi apa pun di dokumentasi, jadi saya tidak tahu persis jenis pengoptimalan apa yang didasarkan pada analisis rute statis yang Anda pikirkan.

Pikiran saya adalah bahwa analisis statis rute ini terutama berguna untuk SSG. yaitu Karena file pages/about.js ada saat Anda membangun situs Anda Next.js mengetahui bahwa rute /about ada dan perlu untuk melakukan pra-render html untuk rute ini, meskipun Anda tidak pernah secara eksplisit memberitahukannya ada rute /about ke pra-render.

SSR tidak memerlukan html yang sudah dibuat sebelumnya karena hanya melakukan itu ketika permintaan masuk (pada titik mana ia menjalankan kode dan memiliki satu jalur untuk dirender). Halaman yang dirender klien sama sekali tidak memiliki html yang telah dirender sebelumnya. Dan jika halaman SSG Anda dinamis maka Anda harus mendeklarasikan semua jalur. Karena itu pikiranku.

Dan sejujurnya, jika semua yang Anda buat adalah aplikasi CSR-berdinding login, maka Next _does_ memiliki banyak kelemahan dibandingkan dengan CRA (SSR tidak akan pernah senyaman CSR).

Apa kerugian yang Anda pikirkan di Next.js sehubungan dengan aplikasi CSR? Selain dari masalah router yang disebutkan di atas.

Sepengetahuan saya, Next.js mendukung keseluruhan rute SSR / SSG / CSR. Jadi seharusnya masih cocok untuk menulis aplikasi CSR berdinding login saja.

Secara pribadi, perspektif saya pasti dari seseorang yang menulis banyak aplikasi CSR, dengan kebutuhan SSR dan SSG sesekali, ingin memiliki satu perangkat yang kuat untuk semua proyek saya, apa pun campuran SSR / SSG / CSR yang mereka butuhkan.

Dari pengalaman saya CRA memiliki cukup banyak kekurangan bahkan dalam aplikasi CSR-saja yang dapat membuat halaman CSR Next.js menguntungkan. Kustomisasi konfigurasi WebPack tanpa mengeluarkan adalah hal yang besar. Ini membuat saya sangat kesakitan ketika saya tidak bisa begitu saja menggunakan plugin globalize-compiler WebPack ketika saya menambahkan i18n ke aplikasi. Kemampuan untuk ikut serta ke SSR / SSG untuk halaman tertentu meskipun sebagian besar halaman adalah CSR juga merupakan keuntungan (mis. 99,9% halaman Anda adalah CSR dan berada di belakang halaman login; tetapi Anda memiliki halaman arahan dan mungkin istilah / kontak halaman tempat Anda ingin SSG atau SSR aktif). Tidak dapat melakukan semua hal itu secara wajar dengan hal-hal seperti CRA.

beberapa dari kita baik-baik saja dalam menangani pemecahan kode sendiri

Beberapa dari kita cukup mampu menangani sendiri webpack, react-dom / server, dll. Tujuan selanjutnya sejauh ini tampaknya membuat pengeluaran seperti itu semakin jarang dan langka seperti CRA

Sejujurnya, melakukan pemisahan kode berbasis rute secara manual (pastikan Anda memodifikasinya untuk menggunakan komponen rute Anda melalui React.lazy atau pustaka alternatif alih-alih impor langsung) adalah cara yang sangat jauh dari mengelola konfigurasi atau penulisan WebPack secara manual. penangan SSR Anda sendiri dengan react-dom/server .

Sangat masuk akal untuk tidak ingin secara manual menulis seluruh konfigurasi WebPack atau server SSR khusus (yaitu ingin menggunakan kerangka kerja yang banyak digunakan seperti Next.js), tetapi tetap baik-baik saja dengan menggunakan react-router dan secara manual melakukan kode berbasis rute- pemisahan. Terutama jika memilih untuk membagi kode basis rute otomatis berarti kehilangan pustaka router yang banyak digunakan yang Anda gunakan dan menggunakan router kehilangan sejumlah fitur yang mungkin Anda perlukan dengan API yang sangat berbeda dari router mana pun dalam penggunaan yang lebih luas.

Saya selalu mendapatkan masalah ini ketika mencari cara untuk mengintegrasikan react-router dengan NextJS yang tidak perlu membuat server khusus, jadi saya memutuskan untuk mencobanya sendiri.

Dengan react-router v6 (beta), buat kustom _app :

// _app.js || _app.tsx
import * as React from 'react'
import App from 'next/app'
import NextRouter from 'next/router'

export default class CustomApp extends App {
    render() {
        const { Component, pageProps } = this.props

        if (process.browser) {
            const { Router } = require('react-router-dom')
            const { createMemoryHistory } = require('history')
            const history = createMemoryHistory({
                initialEntries: [this.props.router.asPath],
            })

            history.listen(function ({ action, location }) {
                const url = {
                    hash: location.hash,
                    pathname: location.pathname,
                    search: location.search,
                }
                switch (action) {
                    case 'PUSH':
                        return NextRouter.push(url)
                    case 'REPLACE':
                        return NextRouter.replace(url)
                    default:
                        return void 0
                }
            })

            return (
                <Router location={history.location} navigator={history} action={history.action}>
                    <Component {...pageProps} />
                </Router>
            )
        } else {
            const { StaticRouter } = require('react-router-dom/server')
            return (
                <StaticRouter location={this.props.router.asPath}>
                    <Component {...pageProps} />
                </StaticRouter>
            )
        }
    }
}

Mengapa

Tidak mudah untuk mengelola _opsional tangkap semua rute_ di NextJS (misal: /foo/[[...bar]].js ), jadi saya sedang mencari cara untuk dapat menggunakan react-router untuk jenis halaman ini. Mungkin yang lain memiliki alasan yang berbeda tetapi itu adalah perhatian utama saya dan react-router menyediakan API yang bagus, khususnya di v6 yang saat ini dalam versi beta.

Bagaimana itu bekerja

Itu hanya membuat kustom MemoryRouter daripada BrowserRouter jadi kami tidak mengacaukan riwayat browser dengan memiliki router NextJS & router NextJS. Itu mendengarkan perubahan riwayat memori untuk PUSH dan REPLACE sehingga Anda dapat menggunakan react-router hooks atau Link untuk bernavigasi tetapi di bawah tenda, itu akan menjadi memanggil metode router NextJS .push dan .replace .

Memanggil metode router NextJS diperlukan, jika tidak, perubahan rute tidak akan benar-benar memicu metode NextJS get*Props . Dengan kata lain, ini akan bekerja sama seperti opsi shallow menggunakan NextJS Link . Kelemahan dari penggunaan react-router Link adalah tidak ada prefetch . Namun, Anda masih dapat menggunakan NextJS Link dan react-router masih dapat bereaksi terhadap perubahan rute.

Hal yang keren tentang itu adalah Anda sekarang dapat memanfaatkan rute NextJS dynamic dan react-router dan melakukan hal-hal seperti:

// /foo/[[...bar]].js
import * as React from 'react'
import { Route, Routes } from 'react-router-dom'
import dynamic from 'next/dynamic'

const Home = dynamic(() => import('src/views/Home'))
const About = dynamic(() => import('src/views/About'))
const Navigation = dynamic(() => import('src/views/Navigation'))

export default function Root() {
    return (
        <>
            <Navigation />
            <Routes>
                <Route path="/foo/" element={<Home />} />
                <Route path="/foo/about" element={<About />} />
            </Routes>
        </>
    )
}

Bagaimanapun, saya harap ini membantu seseorang. Saya belum pernah menggunakan ini dalam produksi dan kode ini berasal dari taman bermain lokal yang saya miliki, jadi mungkin ada hal-hal yang dapat ditingkatkan tetapi ini adalah permulaan.

Menggunakan React Router dengan Next.js 9.5+

Jika Anda menggunakan Next.js 9.5 atau yang lebih baru, cara yang benar untuk melakukannya adalah dengan Rewrites . _Jangan gunakan server khusus_! Ada tutorial terperinci tentang cara melakukan ini di sini: https://colinhacks.com/essays/building-a-spa-with-nextjs

Ide dasarnya:

1. Buat Aplikasi kustom ( /pages/_app.tsx )

2. Kembalikan null jika typeof window === "undefined" . Ini diperlukan untuk mencegah react-router agar tidak melakukan kesalahan selama langkah SSR!

// pages/_app.tsx

import { AppProps } from 'next/app';

function App({ Component, pageProps }: AppProps) {
  return (
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : <Component {...pageProps} />}
    </div>
  );
}

export default App;

Atribut suppressHydrationWarning adalah untuk mencegah peringatan yang dilemparkan oleh React ketika konten yang dirender server tidak setuju dengan konten yang dirender klien.

1. Tulis ulang semua rute ke beranda

// next.config.js

module.exports = {
  async rewrites() {
    return [
      // Rewrite everything else to use `pages/index`
      {
        source: '/:path*',
        destination: '/',
      },
    ];
  },
};

Kemudian Anda dapat menggunakan React Router seperti biasa! Ada lebih banyak konteks / penjelasan dalam tutorial yang ditautkan tetapi ini akan membantu Anda memulai. https://vriad.com/essays/building-a-spa-with-nextjs

@colinhacks Solusi bagus dapat mengonfirmasi bahwa itu berfungsi. Sesuatu yang perlu dipikirkan mungkin memindahkan aplikasi ke halamannya sendiri seperti app.js atau routes.js atau sesuatu. Kemudian menulis ulang ke

// next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/app/:path*',
        destination: '/app',
      },
    ];
  },
};

Hanya sesuatu untuk dipikirkan, solusi Anda adalah yang terbaik yang saya temukan.