Seterusnya.js v— Merenung Kesilapan

Hello! Ini adalah satu lagi artikel tentang next.js. Dan akhirnya, mengenai versi baharu! Setiap keluaran ialah satu set ciri baharu, menarik dan kontroversi. Versi ini tidak akan terkecuali. Walau bagaimanapun, versi baharu menarik bukan untuk fungsi baharunya, tetapi untuk perubahan dalam keutamaan dan organisasi dalam next.js. Dan ya, seperti yang anda mungkin telah meneka dari tajuknya, sebahagian besar keluaran ini berharga untuk merenung kesilapan sebelumnya.

Saya telah bekerja dengan next.js sejak sekitar versi 8. Selama ini saya memerhati perkembangannya dengan penuh minat (kadangkala tidak mengecewakan). Baru-baru ini, saya telah menerbitkan satu siri artikel tentang bergelut dengan Penghala Apl baharu - "Penghala Apl Seterusnya.js. Laluan ke masa depan atau belokan yang salah", "Cache Next.js. Hadiah atau kutukan", " Lebih banyak perpustakaan untuk dewa perpustakaan atau bagaimana saya memikirkan semula i18n". Semua ini adalah hasil daripada perkembangan idea dan keupayaan yang sangat lemah dalam versi sebelumnya next.js. Dan kerana ini, minat saya terhadap versi baharu semakin bertambah. Seiring dengan itu, terdapat keinginan untuk memahami vektor perubahan dalam rangka kerja.

Dalam artikel ini, saya tidak akan memikirkan apa itu Penghala Apl atau komponen pelayan - ini diterangkan secara terperinci dalam artikel sebelumnya. Kami akan menumpukan hanya pada versi baharu dan hanya pada perubahan baharu.

Nota: Artikel menggambarkan perubahan paling menarik dari perspektif pengarang. Ia berbeza daripada senarai rasmi, kerana pengarang memilihnya daripada komit dan PR dalam rangka kerja.

Keluaran Next.js v15

Pertama, sedikit tentang perubahan dalam proses pembangunan dalaman next.js. Buat pertama kalinya, pasukan rangka kerja telah menerbitkan calon keluaran (Versi RC). Jelas sekali, mereka melakukan ini kerana keputusan pasukan React.js untuk menerbitkan React v19 RC.

Biasanya, pasukan next.js dalam keluaran stabil mereka dengan tenang menggunakan tindak balas daripada cawangan keluaran "Canary" (cawangan ini dianggap stabil dan disyorkan untuk digunakan oleh rangka kerja). Kali ini, bagaimanapun, mereka memutuskan untuk melakukan perkara secara berbeza (spoiler - tidak sia-sia).

Pelan untuk kedua-dua pasukan adalah mudah - terbitkan versi pra-keluaran, biarkan komuniti menyemak isu dan dalam beberapa minggu menerbitkan keluaran penuh.

Tweet daripada pembangun pasukan teras React.js https://x.com/acdlite/status/1797668537349328923

Sudah lebih enam bulan sejak calon keluaran React.js dikeluarkan, tetapi versi stabil masih belum diterbitkan. Kelewatan dalam mengeluarkan versi stabil React.js telah memberi kesan kepada rancangan next.js juga. Oleh itu, bertentangan dengan tradisi, mereka menerbitkan sejumlah 15 versi tampalan tambahan sementara sudah mengusahakan versi ke-15 (biasanya 3-5 tampalan dan kemudian keluaran). Apa yang patut diberi perhatian di sini ialah versi tampung ini tidak termasuk semua perubahan terkumpul, tetapi hanya menangani isu kritikal, yang juga menyimpang daripada proses biasa next.js.

Proses keluaran asas dalam next.js ialah segala-galanya bergabung ke dalam cawangan kenari, dan kemudian, pada satu ketika, cawangan ini diterbitkan sebagai keluaran stabil.

Walau bagaimanapun, akibatnya, pasukan next.js memutuskan untuk memisahkan diri daripada keluaran React.js dan menerbitkan versi rangka kerja yang stabil sebelum versi stabil React.js dikeluarkan.

Versi Dokumentasi

Satu lagi perubahan organisasi yang sangat berguna. Akhir sekali, adalah mungkin untuk melihat versi dokumentasi yang berbeza. Inilah sebabnya mengapa ini sangat penting:

Pertama sekali, mengemas kini next.js selalunya boleh menjadi tugas yang agak mencabar kerana perubahan besar. Malah, inilah sebabnya mengapa masih terdapat lebih 2 juta muat turun untuk versi 12 dan lebih 4 juta untuk versi 13 setiap bulan (untuk bersikap adil, versi 14 mempunyai lebih 20 juta muat turun).

Oleh itu, pengguna versi terdahulu memerlukan dokumentasi khusus untuk versi mereka, kerana versi baharu mungkin ditulis semula selama separuh.

Versi dokumentasi Next.js - nextjs.org/docs

Masalah lain ialah Next.js pada asasnya menggunakan satu saluran. Perubahan dokumentasi juga dibuat kepadanya. Oleh itu, perihalan perubahan daripada versi kenari serta-merta muncul dalam dokumentasi utama. Kini ia dipaparkan di bawah bahagian "kanari".

Menggunakan React

Pada mulanya, saya menyebut bahawa Next.js sedang menggunakan versi RC React.js. Tetapi pada hakikatnya, ini tidak sepenuhnya benar, atau sebaliknya tidak sepenuhnya benar. Malah, Next.js sedang menggunakan dua konfigurasi React.js: versi kenari ke-19 untuk Penghala Apl dan versi ke-18 untuk Penghala Halaman.

Menariknya, pada satu ketika mereka mahu memasukkan versi ke-19 untuk Penghala Halaman juga, tetapi kemudian melancarkan semula perubahan ini. Kini, sokongan penuh untuk React.js versi 19 dijanjikan selepas keluaran versi stabilnya.

Seiring dengan ini, versi baharu akan mempunyai beberapa penambahbaikan berguna untuk pelayan tindakan fungsi (ya, pasukan React menamakan semula mereka):

• Pengoptimuman berat dan prestasi;
• Pengendalian ralat yang dipertingkatkan;
• Pengesahan semula dan ubah hala tetap daripada fungsi pelayan.

Saya rasa saya akan memasukkan ciri baharu Next.js dalam bahagian ini juga - komponen Borang. Secara keseluruhan, ia adalah bentuk biasa dari react-dom, tetapi dengan beberapa penambahbaikan. Komponen ini diperlukan terutamanya jika penyerahan borang yang berjaya melibatkan navigasi ke halaman lain. Untuk halaman seterusnya, abstraksi loading.tsx dan layout.tsx akan dipramuat.

import Form from 'next/form'

export default function Page() {
  return (
    <Form action="/search">;
      {/* On submission, the input value will be appended to 
          the URL, e.g. /search?query=abc */}
      <input name="query" />;
      <button type="submit">Submit</button>;
    </Form>;
  )
}

Pengalaman Pembangun (DX)

Apabila bercakap tentang Next.js, kami tidak boleh mengabaikan pengalaman pembangun. Sebagai tambahan kepada standard "Lebih Cepat, Lebih Tinggi, Lebih Kuat" (yang juga akan kita bincangkan, tetapi sedikit kemudian), beberapa penambahbaikan berguna telah dikeluarkan.

Sokongan yang telah lama ditunggu-tunggu untuk ESLint terbaharu. Next.js tidak menyokong ESLint v9 sehingga sekarang. Ini walaupun fakta bahawa kedua-dua eslint itu sendiri (v8) dan beberapa subdependensinya telah ditandakan sebagai tidak digunakan lagi. Ini mengakibatkan situasi yang tidak menyenangkan di mana projek pada dasarnya terpaksa menyimpan pakej yang tidak digunakan.

Antara muka ralat telah dipertingkatkan sedikit (yang dalam Next.js sudah jelas dan mudah):

• Menambahkan butang untuk menyalin surih tindanan;
• Menambahkan keupayaan untuk membuka sumber ralat dalam editor pada baris tertentu.

Contoh menyalin tindanan ralat dalam next.js

"Penunjuk Statik" telah ditambahkan - elemen di penjuru halaman yang menunjukkan bahawa halaman itu telah dibina dalam mod statik.
Secara keseluruhan, ia adalah perkara kecil, tetapi ia lucu bahawa mereka memasukkannya dalam perubahan utama sebagai sesuatu yang baru. Penunjuk untuk halaman "pra-bina" telah wujud sejak kira-kira versi 8 (2019) dan di sini, pada asasnya, mereka baru sahaja mengemas kini sedikit dan menyesuaikannya untuk Penghala Apl.

Direktori dengan maklumat penyahpepijatan juga telah ditambahkan - .next/diagnostics. Ia akan mengandungi maklumat tentang proses binaan dan semua ralat yang berlaku. Masih belum jelas sama ada ini berguna dalam penggunaan harian, tetapi ia pasti akan digunakan apabila menyelesaikan masalah dengan Vercel devrels (ya, kadangkala mereka membantu menyelesaikan masalah).

Respons pasukan Next.js kepada [tweet tentang binaan projek perlahan](https://x.com/darshansrc/status/1797339543571755425)

Perubahan dalam Proses Binaan

Selepas membincangkan DX, adalah berbaloi untuk bercakap tentang proses binaan. Dan bersama-sama dengannya, Turbopack.

Pek turbo

Dan berita terbesar di kawasan ini. Turbopack kini siap sepenuhnya untuk mod pembangunan! "100% ujian sedia ada lulus tanpa ralat dengan Turbopack"

Kini pasukan Turbo sedang mengusahakan versi pengeluaran, secara beransur-ansur menjalani ujian dan memperhalusinya (kini kira-kira 96% siap)

Contoh bahagian changelog dalam next.js

Turbopack juga menambah keupayaan baharu:

• Menetapkan had memori untuk binaan dengan Turbopack;
• Tree Shaking (alih keluar kod yang tidak digunakan).

import Form from 'next/form'

export default function Page() {
  return (
    <Form action="/search">;
      {/* On submission, the input value will be appended to 
          the URL, e.g. /search?query=abc */}
      <input name="query" />;
      <button type="submit">Submit</button>;
    </Form>;
  )
}

Peningkatan ini dan lain-lain dalam Turbopack "mengurangkan penggunaan memori sebanyak 25-30%" dan juga "mempercepatkan pembinaan halaman berat sebanyak 30-50%".

Lain-lain

Isu gaya yang ketara telah dibetulkan. Dalam versi 14, situasi sering timbul apabila susunan gaya dipecahkan semasa navigasi, menyebabkan gaya A menjadi lebih tinggi daripada gaya B, berbanding sebaliknya. Ini mengubah keutamaan mereka dan akibatnya, elemen kelihatan berbeza.

Peningkatan seterusnya yang ditunggu-tunggu. Sekarang fail konfigurasi boleh ditulis dalam TypeScript - next.config.ts

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

Satu lagi kemas kini menarik ialah mencuba semula percubaan untuk binaan halaman statik. Ini bermakna jika halaman gagal pada masa binaan (contohnya, disebabkan masalah internet) - ia akan cuba membina semula.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

Dan untuk menyimpulkan bahagian ini, fungsi yang sangat diingini oleh komuniti - keupayaan untuk menentukan laluan ke fail tambahan untuk membina. Dengan pilihan ini, anda boleh, sebagai contoh, menentukan bahawa fail tidak terletak dalam direktori aplikasi, tetapi dalam direktori seperti modul/utama, modul/invois.

Namun, pada masa ini, mereka hanya menambahnya untuk tujuan pasukan dalaman. Dan dalam versi ini, mereka pasti tidak akan membentangkannya. Pada masa hadapan, ia sama ada akan digunakan untuk keperluan Vercel, atau mereka akan mengujinya dan membentangkannya dalam keluaran seterusnya.

Perubahan dalam API Rangka Kerja

Bahagian paling menyakitkan kemas kini Next.js - perubahan API. Dan dalam versi ini, terdapat juga kemas kini terkini.

Beberapa API rangka kerja dalaman telah menjadi tak segerak - kuki, pengepala, param dan searchParams (yang dipanggil API Dinamik).

const nextConfig = {
  experimental: {
    staticGenerationRetryCount: 3,
  },
}

Ini adalah perubahan besar, tetapi pasukan Next.js berjanji bahawa semua fungsi ini boleh dikemas kini secara automatik dengan memanggil codemod mereka:

npx @next/codemod@canary next-async-request-api .

Satu lagi perubahan, tetapi mungkin tidak relevan kepada ramai. Kekunci geo dan ip telah dialih keluar daripada NextRequest (digunakan dalam perisian tengah dan laluan API). Pada asasnya, fungsi ini hanya berfungsi di Vercel, manakala di tempat lain pembangun membuat kaedah mereka sendiri. Untuk Vercel, fungsi ini akan dialihkan ke pakej @vercel/functions

Dan beberapa lagi kemas kini:

• Dalam revalidateTag, anda kini boleh menghantar berbilang tag serentak;
• Kekunci images.remotePatterns.search dan images.localPatterns telah ditambahkan pada konfigurasi untuk seterusnya/imej. Ini membenarkan kawalan yang lebih baik ke atas sekatan alamat untuk pemampatan imej.

import Form from 'next/form'

export default function Page() {
  return (
    <Form action="/search">;
      {/* On submission, the input value will be appended to 
          the URL, e.g. /search?query=abc */}
      <input name="query" />;
      <button type="submit">Submit</button>;
    </Form>;
  )
}

Caching

Pada pendapat peribadi saya, di sinilah perubahan paling penting untuk Next.js telah berlaku. Dan berita terbesar ialah - Caching kini dilumpuhkan secara lalai! Saya tidak akan menerangkan secara terperinci tentang masalah caching, ini sebahagian besarnya dibincangkan dalam artikel "Next.js Caching. Gift or Curse".

Mari kita lalui semua perubahan utama dalam caching:

• Secara khusus, ambil sekarang menggunakan nilai tiada kedai secara lalai dan bukannya cache paksa;
• Laluan API kini berfungsi dalam mod dinamik daya secara lalai (sebelum ini lalai adalah statik daya, bermakna laluan tersebut disusun menjadi tindak balas statik semasa masa binaan [jika API dinamik tidak digunakan pada halaman]);
• Caching dalam penghala pelanggan juga telah dilumpuhkan. Sebelum ini, jika pelanggan melawat halaman dalam laluan - ia telah dicache pada klien dan kekal dalam keadaan itu sehingga halaman dimuat semula. Sekarang, halaman semasa akan dimuatkan setiap kali. Fungsi ini boleh dikonfigurasikan semula melalui next.config.js:

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

• Selain itu, walaupun caching sisi klien didayakan - nampaknya ia akan dikemas kini pada masa yang tepat. Khususnya, jika cache halaman yang didayakan pada pelayan tamat tempoh.
• Komponen pelayan kini dicache dalam mod pembangunan. Ini menjadikan kemas kini dalam pembangunan berlaku lebih cepat. Cache boleh dikosongkan hanya dengan memuat semula halaman. Anda juga boleh melumpuhkan sepenuhnya fungsi ini melalui next.config.js:

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

• Anda kini boleh mengurus pengepala "Cache-Control". Sebelum ini, ia sentiasa ditimpa secara tegar dengan nilai dalaman Next.js. Ini menyebabkan artifak dengan caching melalui CDN;
• modul cache seterusnya/dinamik dan menggunakannya semula, bukannya memuatkannya semula setiap kali;

Itu mengenai "salah faham sejarah". API baharu juga akan muncul dalam Next.js. Iaitu, apa yang dipanggil Dynamic I/O. Ia belum ditulis tentang mana-mana lagi, jadi berikut akan menjadi tekaan penulis berdasarkan perubahan.

I/O Dinamik nampaknya merupakan mod lanjutan bagi bangunan dinamik. Sesuatu seperti PPR (Prapaparan Separa), atau lebih tepat lagi, pelengkapnya. Ringkasnya, Prapaparan Separa ialah mod pembinaan halaman di mana kebanyakan elemen dibina pada masa binaan dan dicache, manakala elemen individu dibina untuk setiap permintaan.

Jadi, I/O dinamik [mungkin] memuktamadkan seni bina untuk logik ini. Ia mengembangkan keupayaan caching supaya ia boleh didayakan dan dilumpuhkan dengan tepat bergantung pada mod dan tempat penggunaan (sama ada dalam blok "dinamik" atau tidak).

import Form from 'next/form'

export default function Page() {
  return (
    <Form action="/search">;
      {/* On submission, the input value will be appended to 
          the URL, e.g. /search?query=abc */}
      <input name="query" />;
      <button type="submit">Submit</button>;
    </Form>;
  )
}

Seiring dengan ini, arahan "guna cache" ditambah. Ia akan tersedia dalam nodejs dan runtimes tepi dan, nampaknya, dalam semua segmen pelayan dan abstraksi. Dengan menyatakan arahan ini di bahagian atas fungsi atau modul yang mengeksport fungsi - hasilnya akan dicache. Arahan hanya akan tersedia apabila dynamicIO didayakan.

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

Juga, khusus untuk penggunaan cache, kaedah cacheLife dan cacheTag ditambah

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

cacheTag akan digunakan untuk pengesahan semula menggunakan revalidateTag, dan cacheLife akan menetapkan seumur hidup cache. Untuk nilai cacheLife, anda perlu menggunakan salah satu nilai pratetap. Beberapa pilihan akan tersedia di luar kotak ("saat", "minit", "jam", "hari", "minggu", "maks"), yang tambahan boleh dinyatakan dalam next.config.js:

const nextConfig = {
  experimental: {
    staticGenerationRetryCount: 3,
  },
}

Prapaparan Separa (PPR)

Mungkin ciri utama keluaran seterusnya. Seperti yang dinyatakan sebelum ini, PPR ialah mod pembinaan halaman di mana kebanyakan elemen dipasang pada masa binaan dan dicache, manakala elemen individu dipasang untuk setiap permintaan. Pada masa yang sama, bahagian pra-bina segera dihantar kepada pelanggan, manakala selebihnya dimuatkan secara dinamik.

Cara Prapaparan Separa berfungsi

Fungsi itu sendiri telah diperkenalkan enam bulan lalu dalam calon keluaran sebagai API percubaan. API ini akan kekal dalam keadaan ini dan kami mungkin akan melihatnya sebagai stabil hanya dalam versi 16 (yang bagus, kerana fungsi utama sering beralih kepada stabil dalam tempoh enam bulan hingga setahun).

Mengenai perubahan. Seperti yang dinyatakan sebelum ini, ia mengemas kini prinsip kerja terutamanya. Walau bagaimanapun, dari perspektif penggunaan PPR, ini hampir tidak menjejaskan apa-apa. Pada masa yang sama, ia menerima beberapa penambahbaikan:

Sebelum ini, hanya terdapat bendera dalam konfigurasi, tetapi kini untuk mendayakan PPR, anda perlu menentukan 'incremental'. Ini nampaknya dilakukan untuk menjadikan logik lebih telus - kandungan boleh dicache oleh pembangun walaupun dalam PPR, dan untuk mengemas kininya, anda perlu memanggil kaedah pengesahan semula.

import { cookies } from 'next/headers';

export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');

  // ...
}

Selain itu, sebelum ini PPR telah dilancarkan untuk keseluruhan projek, tetapi kini ia perlu didayakan untuk setiap segmen (susun atur atau halaman):

const nextConfig = {
  images: {
    localPatterns: [
      {
        pathname: '/assets/images/**',
        search: 'v=1',
      },
    ],
  },
}

Perubahan lain ialah Partial Fallback Prerendering (PFPR). Justru disebabkan oleh peningkatan ini, bahagian pra-bina segera dihantar kepada pelanggan, manakala selebihnya dimuatkan secara dinamik. Sebagai ganti elemen dinamik, komponen panggil balik ditunjukkan pada masa ini.

import Form from 'next/form'

export default function Page() {
  return (
    <Form action="/search">;
      {/* On submission, the input value will be appended to 
          the URL, e.g. /search?query=abc */}
      <input name="query" />;
      <button type="submit">Submit</button>;
    </Form>;
  )
}

Instrumentasi

Instrumentasi ditandakan sebagai API yang stabil. Fail instrumentasi membolehkan pengguna menyambung ke dalam kitaran hayat pelayan Next.js. Ia berfungsi merentas keseluruhan aplikasi (termasuk semua segmen Penghala Halaman dan Penghala Apl).

Pada masa ini, instrumentasi menyokong cangkuk berikut:

daftar - dipanggil sekali apabila memulakan pelayan Next.js. Ia boleh digunakan untuk penyepaduan dengan perpustakaan kebolehmerhatian (OpenTelemetry, datadog) atau untuk tugasan khusus projek.

onRequestError - cangkuk baharu yang dipanggil untuk semua ralat pelayan. Ia boleh digunakan untuk penyepaduan dengan perpustakaan penjejakan ralat (Sentry).

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

pemintas

Pemintas, juga dikenali sebagai perisian tengah peringkat laluan. Ia adalah seperti perisian tengah [yang sudah sedia ada] sepenuhnya, tetapi tidak seperti yang kedua:

• Ia boleh berfungsi dalam masa jalan Node.js;
• Ia berfungsi pada pelayan (yang bermaksud ia mempunyai akses kepada persekitaran dan cache bersatu);
• Ia boleh ditambah beberapa kali dan diwarisi dalam sarang (serupa dengan cara perisian tengah berfungsi semasa ia dalam versi beta);
• Ia juga berfungsi untuk fungsi pelayan.

Selain itu, apabila membuat fail pemintas, semua halaman di bawah dalam pepohon menjadi dinamik.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

Bercakap tentang Vercel, middleware kini akan berkesan sebagai semakan mudah utama di peringkat CDN (oleh itu, sebagai contoh, segera mengembalikan ubah hala jika permintaan tidak dibenarkan), manakala pemintas akan berfungsi pada pelayan, melakukan semakan penuh dan operasi yang kompleks.

Walau bagaimanapun, dalam pengehosan kendiri, pembahagian sedemikian nampaknya akan menjadi kurang berkesan (memandangkan kedua-dua abstraksi berfungsi pada pelayan). Ia mungkin mencukupi untuk menggunakan hanya pemintas.

Kesimpulan

Menulis ganti pengambilan, caching agresif, banyak pepijat dan mengabaikan permintaan komuniti. Pasukan Next.js membuat keputusan yang salah, mengeluarkan tergesa-gesa dan mengekalkan pandangan mereka walaupun maklum balas komuniti. Ia mengambil masa hampir setahun untuk mengenali masalah. Dan kini, akhirnya, ada perasaan bahawa rangka kerja itu sekali lagi menangani isu komuniti.

Sebaliknya, terdapat rangka kerja lain. Setahun yang lalu, pada pembentangan React.js, nampaknya semua rangka kerja tidak lama lagi akan setanding dengan Next.js. React mula menyebut Next.js kurang kerap sebagai alat utama, rangka kerja mempamerkan sistem binaan yang akan datang, sokongan untuk komponen dan fungsi pelayan, dan siri perubahan dan penyepaduan global. Masa telah berlalu, dan pada asasnya, tiada seorang pun daripada mereka yang mencapai tahap itu.

Sudah tentu, kesimpulan akhir hanya boleh dibuat selepas beberapa ketika, tetapi buat masa ini, rasanya seperti perubahan dalam React.js, bukannya meratakan rangka kerja yang dijangka, telah membawa kepada penguasaan yang lebih besar bagi Next.js dan a perbezaan yang lebih luas antara rangka kerja (memandangkan pelaksanaan komponen pelayan dan tindakan diserahkan kepada budi bicara rangka kerja).

Pada masa yang sama, OpenAI bertukar kepada Remix ("disebabkan oleh kestabilan dan kemudahan yang lebih baik"):

Penggunaan remix dalam ChatGPT

Dan nampaknya ia bermula sebelum perubahan ketara dalam Next.js

Tweet tentang ChatGPT bertukar kepada Remix dari Ogos, 2024

Secara umum, dalam tinjauan stateofjs dan stackoverflow seterusnya, kami berkemungkinan akan melihat rombakan yang ketara.

Kredit

Contoh kod atau asasnya diambil daripada dokumentasi next.js, serta daripada commit, PR dan teras next.js;

Posskrip

Jika anda memerlukan alat untuk menjana dokumentasi berdasarkan fail MD - lihat robindoc.com, jika anda bekerja dengan next.js - anda mungkin menemui sesuatu yang berguna dalam penyelesaian di nimpl.tech.

Atas ialah kandungan terperinci Seterusnya.js v— Merenung Kesilapan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!