Cara Bermigrasi Dari jQuery Ke Next.js
Diterbitkan: 2022-03-10Artikel ini telah didukung dengan baik oleh teman-teman terkasih kami di Netlify yang merupakan kelompok beragam talenta luar biasa dari seluruh dunia dan menawarkan platform untuk pengembang web yang melipatgandakan produktivitas. Terima kasih!
Ketika jQuery muncul pada tahun 2006, banyak pengembang dan organisasi mulai mengadopsinya untuk proyek mereka. Kemungkinan memperluas dan memanipulasi DOM yang ditawarkan perpustakaan sangat bagus, dan kami juga memiliki banyak plugin untuk menambahkan perilaku ke halaman kami jika kami perlu melakukan tugas yang tidak didukung oleh perpustakaan utama jQuery. Ini menyederhanakan banyak pekerjaan untuk pengembang, dan, pada saat itu, membuat JavaScript menjadi bahasa yang kuat untuk membuat aplikasi web atau Aplikasi Halaman Tunggal.
Hasil popularitas jQuery masih dapat diukur hingga hari ini: Hampir 80% situs web paling populer di dunia masih menggunakannya. Beberapa alasan mengapa jQuery begitu populer adalah:
- Ini mendukung manipulasi DOM.
- Ini menyediakan manipulasi CSS.
- Bekerja sama di semua browser web.
- Ini membungkus metode acara HTML.
- Mudah untuk membuat panggilan AJAX.
- Efek dan animasi yang mudah digunakan.
Selama bertahun-tahun, JavaScript banyak berubah dan menambahkan beberapa fitur yang sebelumnya tidak kami miliki. Dengan definisi ulang dan evolusi ECMAScript, beberapa fungsi yang disediakan jQuery ditambahkan ke fitur JavaScript standar dan didukung oleh semua browser web. Dengan kejadian ini, beberapa perilaku yang ditawarkan jQuery tidak diperlukan lagi , karena kami dapat melakukan hal yang sama dengan JavaScript biasa.
Di sisi lain, cara berpikir dan merancang antarmuka pengguna baru mulai muncul. Kerangka kerja seperti React, Angular atau Vue memungkinkan pengembang untuk membuat aplikasi web berdasarkan komponen fungsional yang dapat digunakan kembali. Bereaksi, yaitu, bekerja dengan "DOM virtual", yang merupakan representasi DOM di memori, sedangkan jQuery berinteraksi langsung dengan DOM , dengan cara yang kurang berkinerja. Juga, React menawarkan fitur-fitur keren untuk memfasilitasi pengembangan fitur-fitur tertentu, seperti manajemen negara. Dengan pendekatan baru ini dan popularitas yang mulai diperoleh Aplikasi Halaman Tunggal, banyak pengembang mulai menggunakan React untuk proyek aplikasi web mereka.
Dan pengembangan front-end semakin berkembang, dengan kerangka kerja yang dibuat di atas kerangka kerja lainnya. Itulah yang terjadi, misalnya, Next.js. Seperti yang mungkin Anda ketahui, ini adalah kerangka kerja React sumber terbuka yang menawarkan fitur untuk menghasilkan halaman statis, membuat halaman yang dirender sisi server, dan menggabungkan kedua jenis dalam aplikasi yang sama. Ini juga memungkinkan pembuatan API tanpa server di dalam aplikasi yang sama.
Ada skenario yang aneh: Meskipun kerangka kerja frontend ini semakin populer selama bertahun-tahun, jQuery masih diadopsi oleh sebagian besar halaman web. Salah satu alasan mengapa ini terjadi adalah persentase situs web yang menggunakan WordPress sangat tinggi, dan jQuery termasuk dalam CMS . Alasan lain adalah bahwa beberapa perpustakaan, seperti Bootstrap, memiliki ketergantungan pada jQuery, dan ada beberapa template siap pakai yang menggunakannya dan pluginnya.
Tetapi alasan lain untuk jumlah situs web yang menggunakan jQuery ini adalah biaya migrasi aplikasi web lengkap ke kerangka kerja baru. Tidak mudah, tidak murah dan memakan waktu. Namun, pada akhirnya, bekerja dengan alat dan teknologi baru membawa banyak manfaat: dukungan yang lebih luas, bantuan komunitas, pengalaman pengembang yang lebih baik, dan kemudahan membuat orang mengerjakan proyek.
Ada banyak skenario di mana kita tidak perlu (atau tidak ingin) mengikuti arsitektur yang diterapkan oleh kerangka kerja seperti React atau Next.js pada kita, dan itu tidak masalah. Namun, jQuery adalah library yang berisi banyak kode dan fitur yang tidak diperlukan lagi. Banyak fitur yang ditawarkan jQuery dapat dicapai dengan menggunakan fungsi asli JavaScript modern , dan mungkin dengan cara yang lebih berkinerja.
Mari kita bahas bagaimana kita dapat berhenti menggunakan jQuery dan memigrasikan situs web kita ke dalam aplikasi web React atau Next.js.
Tentukan Strategi Migrasi
Apakah Kita Membutuhkan Perpustakaan?
Tergantung pada fitur aplikasi web kami, kami bahkan dapat memiliki kasus di mana kerangka kerja tidak benar-benar diperlukan. Seperti disebutkan sebelumnya, beberapa fitur jQuery disertakan (atau setidaknya yang sangat mirip) dengan versi standar web terbaru. Jadi, mengingat:
-
$(selector)
pola dari jQuery dapat diganti denganquerySelectorAll()
.
Alih-alih melakukan:
$("#someId");
Kita bisa:
document.querySelectorAll("#someId");
- Kami sekarang memiliki properti
Element.classList
jika kami ingin memanipulasi kelas CSS.
Alih-alih melakukan:
$(selector).addClass(className);
Kita bisa:
element.classList.add(className);
- Banyak animasi dapat dilakukan secara langsung menggunakan CSS, alih-alih mengimplementasikan JavaScript.
Alih-alih melakukan:
$(selector).fadeIn();
Kita bisa:
element.classList.add('show'); element.classList.remove('hide');
Dan terapkan beberapa gaya CSS:
.show { transition: opacity 400ms; } .hide { opacity: 0; }
- Kami sekarang memiliki fungsi addEventListener jika kami ingin menangani acara.
Alih-alih melakukan:
$(selector).on(eventName, eventHandler);
Kita bisa:
element.addEventListener(eventName, eventHandler);
- Alih-alih menggunakan jQuery Ajax, kita dapat menggunakan
XMLHttpRequest
.
Alih-alih melakukan:
$.ajax({ type: 'POST', url: '/the-url', data: data });
Kita bisa:
var request = new XMLHttpRequest(); request.open('POST', '/the-url', true); request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8'); request.send(data);
Untuk lebih jelasnya, Anda dapat melihat Cuplikan Kode JavaScript Vanilla ini.
Identifikasi Komponen
Jika kita menggunakan jQuery dalam aplikasi kita, kita harus memiliki beberapa konten HTML yang dihasilkan di server web, dan kode JavaScript yang menambahkan interaktivitas ke halaman. Kami mungkin menambahkan pengendali peristiwa pada pemuatan halaman yang akan memanipulasi DOM saat peristiwa terjadi, mungkin memperbarui CSS atau gaya elemen. Kami juga dapat memanggil layanan backend untuk menjalankan tindakan, yang dapat memengaruhi DOM halaman, atau bahkan memuat ulang.
Idenya adalah untuk memfaktorkan ulang kode JavaScript yang ada di halaman dan membangun komponen React. Ini akan membantu kita untuk menggabungkan kode terkait dan menyusun elemen yang akan menjadi bagian dari komposisi yang lebih besar. Dengan melakukan ini, kami juga akan dapat menangani status aplikasi kami dengan lebih baik. Menganalisis frontend aplikasi kita, kita harus membaginya menjadi beberapa bagian yang didedikasikan untuk tugas tertentu, sehingga kita dapat membuat komponen berdasarkan itu.
Jika kita memiliki tombol:
<button>Click</button>
Dengan logika berikut:
var $btnAction = $("#btn-action"); $btnAction.on("click", function() { alert("Button was clicked"); });
Kami dapat memigrasikannya ke Komponen Bereaksi:
import React from 'react'; function ButtonComponent() { let handleButtonClick = () => { alert('Button clicked!') } return <button onClick={handleButtonClick}>Click</button> }
Tetapi kita juga harus mengevaluasi bagaimana proses migrasi akan diselesaikan karena aplikasi kita bekerja dan sedang digunakan, dan kita tidak ingin mempengaruhinya (atau, setidaknya, mempengaruhinya sesedikit mungkin).
Migrasi yang Baik
Migrasi yang baik adalah di mana semua bagian aplikasi dimigrasikan sepenuhnya ke kerangka kerja atau teknologi baru. Ini akan menjadi skenario ideal untuk aplikasi kami karena kami akan tetap menyinkronkan semua bagian, dan kami akan menggunakan alat terpadu dan versi rujukan yang unik.
Migrasi yang baik dan lengkap biasanya mencakup penulisan ulang lengkap kode aplikasi kita, dan itu masuk akal. Jika kami membangun aplikasi dari awal, kami memiliki kemungkinan untuk memutuskan arah yang ingin kami ambil dengan kode baru. Kami dapat menggunakan sudut pandang baru atas sistem dan alur kerja kami yang ada, dan membuat aplikasi yang sama sekali baru dengan pengetahuan yang kami miliki saat ini, lebih lengkap daripada yang kami miliki saat pertama kali membuat aplikasi web.
Tetapi penulisan ulang yang lengkap memiliki beberapa masalah. Pertama-tama, itu membutuhkan banyak waktu. Semakin besar aplikasi, semakin banyak waktu yang kita perlukan untuk menulis ulang. Masalah lain adalah jumlah pekerjaan, dan jumlah pengembang, yang dibutuhkan. Dan, jika kita tidak melakukan migrasi progresif, kita harus memikirkan berapa lama aplikasi kita tidak akan tersedia.
Biasanya, penulisan ulang lengkap dapat diselesaikan dengan proyek kecil, proyek yang tidak sering berubah, atau aplikasi yang tidak begitu penting untuk bisnis kita.
Migrasi Cepat
Pendekatan lain adalah membagi aplikasi menjadi beberapa bagian atau bagian. Kami memigrasikan aplikasi bagian demi bagian, dan kami merilis bagian-bagian itu saat sudah siap. Jadi, kami telah memigrasikan bagian dari aplikasi kami yang tersedia untuk pengguna, dan hidup berdampingan dengan aplikasi produksi kami yang ada.
Dengan migrasi bertahap ini, kami memberikan fitur terpisah dari proyek kami dengan cara yang lebih cepat kepada pengguna, karena kami tidak perlu menunggu aplikasi lengkap untuk ditulis ulang. Kami juga mendapatkan umpan balik yang lebih cepat dari pengguna, yang memungkinkan kami mendeteksi bug atau masalah lebih awal.
Tetapi migrasi bertahap mendorong kita untuk memiliki alat, pustaka, dependensi, dan kerangka kerja yang berbeda. Atau kita bahkan harus mendukung versi yang berbeda dari alat yang sama. Dukungan yang diperluas ini dapat membawa konflik ke aplikasi kami.
Kami bahkan dapat mengalami masalah jika kami menerapkan kebijakan dalam lingkup global karena setiap bagian yang dimigrasikan dapat bekerja dengan cara yang berbeda, tetapi dipengaruhi oleh kode yang menetapkan parameter global ke sistem kami. Contohnya adalah penggunaan logika kaskade untuk gaya CSS.
Bayangkan kami bekerja dengan versi jQuery yang berbeda di seluruh aplikasi web kami karena kami menambahkan fungsionalitas dari versi yang lebih baru ke modul yang telah dibuat nanti. Seberapa rumitkah untuk memigrasikan semua aplikasi kita ke versi jQuery yang lebih baru? Sekarang, bayangkan skenario yang sama tetapi bermigrasi ke kerangka kerja yang sama sekali berbeda seperti Next.js. Itu bisa rumit.
Migrasi Frankenstein
Denys Mishunov menulis sebuah artikel di Majalah Smashing yang menyajikan alternatif dari dua ide migrasi ini, mencoba mendapatkan yang terbaik dari dua pendekatan sebelumnya: Migrasi Frankenstein. Ini mendasarkan proses migrasi dalam dua komponen utama: Layanan Mikro dan Komponen Web.
Proses migrasi terdiri dari daftar langkah-langkah yang harus diikuti:
1. Identifikasi Layanan Mikro
Berdasarkan kode aplikasi kami, kami harus membaginya menjadi bagian-bagian independen yang didedikasikan untuk satu pekerjaan kecil. Jika kita berpikir untuk menggunakan React atau Next.js, kita dapat menghubungkan konsep layanan mikro ke berbagai komponen yang kita miliki.
Mari kita pikirkan tentang aplikasi daftar belanjaan sebagai contoh. Kami memiliki daftar barang untuk dibeli, dan masukan untuk menambahkan lebih banyak barang ke daftar. Jadi, jika kita ingin membagi aplikasi kita menjadi bagian-bagian kecil, kita bisa memikirkan komponen "daftar item" dan "tambahkan item". Dengan melakukan ini, kita dapat memisahkan fungsionalitas dan markup yang terkait dengan masing-masing bagian tersebut ke dalam komponen React yang berbeda.
Untuk menguatkan komponen independen, kita harus dapat menghapus salah satunya dari aplikasi, dan yang lain tidak boleh terpengaruh oleh itu. Jika kami mendapatkan kesalahan saat menghapus markup dan fungsionalitas dari suatu layanan, kami tidak mengidentifikasi komponen dengan benar, atau kami perlu memfaktorkan ulang cara kerja kode kami.
2. Izinkan Akses Host-to-Alien
"Host" adalah aplikasi kami yang sudah ada. "Alien" adalah yang akan kita mulai buat, dengan kerangka kerja baru. Keduanya harus bekerja secara independen, tetapi kami harus menyediakan akses dari Host ke Alien. Kita harus dapat menerapkan salah satu dari dua aplikasi tanpa merusak yang lain, tetapi menjaga komunikasi di antara mereka.
3. Tulis Komponen Alien
Tulis ulang layanan dari aplikasi Host kami ke dalam aplikasi Alien kami, menggunakan kerangka kerja baru. Komponen harus mengikuti prinsip independensi yang sama yang kami sebutkan sebelumnya.
Mari kembali ke contoh daftar belanjaan. Kami mengidentifikasi komponen "tambah item". Dengan jQuery, markup komponen akan terlihat seperti ini:
<input class="new-item" />
Dan kode JavaScript/jQuery untuk menambahkan item ke daftar akan menjadi seperti ini:
var ENTER_KEY = 13; $('.new-item').on('keyup', function (e) { var $input = $(e.target); var val = $input.val().trim(); if (e.which !== ENTER_KEY || !val) { return; } // code to add the item to the list $input.val(''); });
Alih-alih itu, kita dapat membuat komponen AddItem
React:
import React from 'react' function AddItemInput({ defaultText }) { let [text, setText] = useState(defaultText) let handleSubmit = e => { e.preventDefault() if (e.which === 13) { setText(e.target.value.trim()) } } return <input type="text" value={text} onChange={(e) => setText(e.target.value)} onKeyDown={handleSubmit} /> }
4. Tulis Pembungkus Komponen Web Di Sekitar Layanan Alien
Buat komponen pembungkus yang mengimpor layanan Alien yang baru saja kita buat dan merendernya. Idenya adalah untuk membuat jembatan antara aplikasi Host dan aplikasi Alien. Perlu diingat bahwa kita mungkin memerlukan package bundler untuk menghasilkan kode JavaScript yang berfungsi di aplikasi kita saat ini karena kita perlu menyalin komponen React baru kita dan membuatnya berfungsi.
Mengikuti contoh daftar belanjaan, kita dapat membuat file AddItem-wrapper.js
di proyek Host. File ini akan berisi kode yang membungkus komponen AddItem
yang sudah kita buat, dan membuat elemen kustom dengannya:
import React from "../alien/node_modules/react"; import ReactDOM from "../alien/node_modules/react-dom"; import AddItem from "../alien/src/components/AddItem"; class FrankensteinWrapper extends HTMLElement { connectedCallback() { const appWrapper = document.createElement("div"); appWrapper.classList.add("grocerylistapp"); ... ReactDOM.render( <HeaderApp />, appWrapper ); … } } customElements.define("frankenstein-add-item-wrapper", FrankensteinWrapper);
Kita harus membawa modul dan komponen simpul yang diperlukan dari folder aplikasi Alien karena kita perlu mengimpornya agar komponen berfungsi.
5. Ganti Layanan Host Dengan Komponen Web
Komponen wrapper ini akan menggantikan yang ada di aplikasi Host, dan kita akan mulai menggunakannya. Jadi, aplikasi dalam produksi akan menjadi campuran komponen Host dan komponen yang dibungkus Alien.
Dalam contoh aplikasi Host kami, kami harus mengganti:
<input class="new-item" />
Dengan
<frankenstein-add-item-wrapper></frankenstein-add-item-wrapper> ... <script type="module" src="js/AddItem-wrapper.js"></script>
6. Bilas Dan Ulangi
Lakukan langkah 3, 4, dan 5 untuk masing-masing layanan mikro yang diidentifikasi.
7. Beralih Ke Alien
Host sekarang merupakan kumpulan komponen pembungkus yang mencakup semua komponen web yang kita buat pada aplikasi Alien. Saat kami mengonversi semua layanan mikro yang teridentifikasi, kami dapat mengatakan bahwa aplikasi Alien telah selesai dan semua layanan telah dimigrasikan. Kami hanya perlu mengarahkan pengguna kami ke aplikasi Alien sekarang.
Metode Migrasi Frankenstein bekerja sebagai kombinasi dari pendekatan Baik dan Cepat. Kami memigrasikan aplikasi yang lengkap tetapi melepaskan komponen yang berbeda setelah selesai. Jadi, mereka tersedia untuk digunakan lebih cepat dan dievaluasi oleh pengguna dalam produksi.
Namun, kita harus mempertimbangkan bahwa kita melakukan beberapa pekerjaan berlebihan dengan pendekatan ini. Jika kita ingin menggunakan komponen yang kita buat untuk aplikasi Alien kita, kita harus membuat komponen pembungkus untuk disertakan dalam aplikasi Host. Ini membuat kami menghabiskan waktu mengembangkan kode untuk elemen pembungkus ini. Juga, dengan menggunakannya di aplikasi Host kami, kami menduplikasi penyertaan kode dan dependensi, dan menambahkan kode yang akan memengaruhi kinerja aplikasi kami.
Aplikasi pencekik
Pendekatan lain yang bisa kita ambil adalah Legacy Application Strangulation. Kami mengidentifikasi tepi aplikasi web kami yang ada, dan kapan pun kami perlu menambahkan fungsionalitas ke aplikasi kami, kami melakukannya menggunakan kerangka kerja yang lebih baru hingga sistem lama "dicekik". Pendekatan ini membantu kami mengurangi potensi risiko yang dapat kami uji saat memigrasikan aplikasi.
Untuk mengikuti pendekatan ini, kita perlu mengidentifikasi komponen yang berbeda, seperti yang kita lakukan dalam Migrasi Frankenstein. Setelah kami membagi aplikasi kami menjadi bagian-bagian berbeda dari kode imperatif terkait, kami membungkusnya dalam komponen React baru. Kami tidak menambahkan perilaku tambahan, kami hanya membuat komponen React yang merender konten yang ada.
Mari kita lihat contoh untuk lebih jelasnya. Misalkan kita memiliki kode HTML ini di aplikasi kita:
<div class="accordion"> <div class="accordion-panel"> <h3 class="accordion-header">Item 1</h3> <div class="accordion-body">Text 1</div> </div> <div class="accordion-panel"> <h3 class="accordion-header">Item 2</h3> <div class="accordion-body">Text 2</div> </div> <div class="accordion-panel"> <h3 class="accordion-header">Item 3</h3> <div class="accordion-body">Text 3</div> </div>> </div>
Dan kode JavaScript ini (kami telah mengganti fungsi jQuery dengan fitur standar JavaScript baru).
const accordions = document.querySelectorAll(".accordion"); for (const accordion of accordions) { const panels = accordion.querySelectorAll(".accordion-panel"); for (const panel of panels) { const head = panel.querySelector(".accordion-header"); head.addEventListener('click', () => { for (const otherPanel of panels) { if (otherPanel !== panel) { otherPanel.classList.remove('accordion-expanded'); } } panel.classList.toggle('accordion-expanded'); }); } }
Ini adalah implementasi umum dari komponen accordion
untuk JavaScript. Karena kami ingin memperkenalkan React di sini, kami perlu membungkus kode yang ada dengan komponen React baru:
function Accordions() { useEffect(() => { const accordions = document.querySelectorAll(".accordion") for (const accordion of accordions) { const panels = accordion.querySelectorAll(".accordion-panel") for (const panel of panels) { const head = panel.querySelector(".accordion-header") head.addEventListener("click", () => { for (const otherPanel of panels) { if (otherPanel !== panel) { otherPanel.classList.remove("accordion-expanded") } } panel.classList.toggle("accordion-expanded") }); } } }, []) return null } ReactDOM.render(<Accordions />, document.createElement("div"))
Komponen tidak menambahkan perilaku atau fitur baru. Kami menggunakan useEffect
karena komponen telah dipasang di dokumen. Itulah mengapa fungsi mengembalikan null karena hook tidak perlu mengembalikan komponen.
Jadi, kami tidak menambahkan fungsionalitas baru apa pun ke aplikasi kami yang sudah ada, tetapi kami memperkenalkan React tanpa mengubah perilakunya. Mulai sekarang, setiap kali kami menambahkan fitur baru atau perubahan pada kode kami, kami akan melakukannya menggunakan kerangka kerja yang dipilih yang lebih baru.
Rendering Sisi Klien, Render Sisi Server, Atau Pembuatan Statis?
Next.js memberi kita kemungkinan untuk memilih bagaimana kita ingin merender setiap halaman aplikasi web kita. Kita dapat menggunakan rendering sisi klien yang telah ditawarkan oleh React kepada kita untuk menghasilkan konten secara langsung di browser pengguna. Atau, kita dapat merender konten halaman kita di server menggunakan rendering sisi server. Akhirnya, kita dapat membuat konten halaman kita pada waktu pembuatan menggunakan pembuatan statis.
Dalam aplikasi kita, kita harus memuat dan merender kode pada pemuatan halaman, sebelum kita mulai berinteraksi dengan pustaka atau kerangka kerja JavaScript apa pun. Kami mungkin menggunakan bahasa atau teknologi pemrograman rendering sisi server, seperti ASP.NET, PHP, atau Node.js. Kita bisa mendapatkan keuntungan dari fitur Next.js dan mengganti metode rendering kita saat ini dengan metode rendering sisi server Next.js . Dengan melakukan ini, kami menyimpan semua perilaku di dalam proyek yang sama, yang bekerja di bawah payung kerangka kerja yang kami pilih. Juga, kami menjaga logika halaman utama kami dan komponen React dalam kode yang sama yang menghasilkan semua konten yang dibutuhkan untuk halaman kami.
Mari kita pikirkan tentang halaman dasbor sebagai contoh. Kami dapat menghasilkan semua markup awal halaman pada waktu buka, di server, daripada harus membuatnya dengan React di browser web pengguna.
const DashboardPage = ({ user }) => { return ( <div> <h2>{user.name}</h2> // User data </div> ) } export const getServerSideProps = async ({ req, res, params }) => { return { props: { user: getUser(), }, } }, }) export default DashboardPage
Jika markup yang kami render pada pemuatan halaman dapat diprediksi dan didasarkan pada data yang dapat kami ambil pada waktu pembuatan, pembuatan statis akan menjadi pilihan yang baik. Menghasilkan aset statis pada waktu pembuatan akan membuat aplikasi kita lebih cepat, lebih aman, skalabel, dan lebih mudah dirawat. Dan, jika kita perlu membuat konten dinamis pada halaman aplikasi kita, kita dapat menggunakan rendering sisi klien React untuk mengambil informasi dari layanan atau sumber data.
Bayangkan kita memiliki situs blog, dengan banyak posting blog. Jika kita menggunakan Static Generation, kita dapat membuat file [blog-slug].js
generik di aplikasi Next.js kita, dan menambahkan kode berikut, kita akan menghasilkan semua halaman statis untuk posting blog kita pada waktu pembuatan.
export const getStaticPaths = async () => { const blogPosts = await getBlogPosts() const paths = blogPosts.map(({ slug }) => ({ params: { slug, }, })) return { paths, fallback: false, } } export const getStaticProps = async ({ params }) => { const { slug } = params const blogPost = await getBlogPostBySlug(slug) return { props: { data: JSON.parse(JSON.stringify(blogPost)), }, } }
Buat API Menggunakan Rute API
Salah satu fitur hebat yang ditawarkan Next.js adalah kemungkinan untuk membuat Rute API. Dengan mereka, kita dapat membuat fungsi tanpa server kita sendiri menggunakan Node.js. Kami juga dapat menginstal paket NPM untuk memperluas fungsionalitas. Hal yang keren tentang ini adalah bahwa API kami akan meninggalkan proyek/aplikasi yang sama dengan frontend kami, jadi kami tidak akan memiliki masalah CORS.
Jika kita memelihara API yang dipanggil dari aplikasi web kita menggunakan fungsionalitas jQuery AJAX, kita bisa menggantinya menggunakan API Routes . Dengan melakukan ini, kami akan menyimpan semua basis kode aplikasi kami di repositori yang sama, dan kami akan membuat penerapan aplikasi kami lebih sederhana. Jika kami menggunakan layanan pihak ketiga, kami dapat menggunakan Rute API untuk "menutupi" URL eksternal.
Kita bisa memiliki Rute API /pages/api/get/[id].js
yang mengembalikan data yang kita gunakan di halaman kita.
export default async (req, res) => { const { id } = req.query try { const data = getData(id) res.status(200).json(data) } catch (e) { res.status(500).json({ error: e.message }) } }
Dan panggil dari kode halaman kami.
const res = await fetch(`/api/get/${id}`, { method: 'GET', }) if (res.status === 200) { // Do something } else { console.error(await res.text()) }
Terapkan ke Netlify
Netlify adalah platform lengkap yang dapat digunakan untuk mengotomatisasi, mengelola, membangun, menguji, menyebarkan, dan meng-host aplikasi web. Ini memiliki banyak fitur yang membuat pengembangan aplikasi web modern lebih mudah dan lebih cepat. Beberapa sorotan Netlify adalah:
- Platform hosting CDN global,
- Dukungan fungsi tanpa server,
- Terapkan pratinjau berdasarkan Permintaan Tarik Github,
- Webhook,
- Rollback instan,
- Kontrol akses berbasis peran.
Netlify adalah platform hebat untuk mengelola dan menghosting aplikasi Next.js kami, dan cukup mudah untuk menerapkan aplikasi web dengannya.
Pertama-tama, kita perlu melacak kode aplikasi Next.js kita di repositori Git. Netlify terhubung ke GitHub (atau platform Git yang kami sukai), dan setiap kali perubahan diperkenalkan ke cabang (komit atau Permintaan Tarik), tugas "build and deploy" otomatis akan dipicu.
Setelah kita memiliki repositori Git dengan kode aplikasi kita, kita perlu membuat "Situs Netlify" untuk itu. Untuk melakukan ini, kami memiliki dua opsi:
- Menggunakan Netlify CLI
Setelah kita menginstal CLI (npm install -g netlify-cli
) dan masuk ke akun Netlify kita (ntl login
), kita dapat pergi ke direktori root aplikasi kita, jalankanntl init
dan ikuti langkah-langkahnya. - Menggunakan aplikasi web Netlify
Kita harus pergi ke https://app.netlify.com/start. Hubungkan ke penyedia Git kami, pilih repositori aplikasi kami dari daftar, konfigurasikan beberapa opsi build, dan terapkan.
Untuk kedua metode tersebut, kita harus mempertimbangkan bahwa perintah build kita akan menjadi next build
dan direktori yang akan kita gunakan sudah out
.
Terakhir, plugin Essential Next.js diinstal secara otomatis, yang memungkinkan kita untuk menggunakan dan menggunakan rute API, rute dinamis, dan Mode Pratinjau. Dan hanya itu, kami memiliki aplikasi Next.js kami dan berjalan di layanan hosting CDN yang cepat dan stabil.
Kesimpulan
Dalam artikel ini, kami mengevaluasi situs web menggunakan perpustakaan jQuery, dan kami membandingkannya dengan kerangka kerja frontend baru seperti React dan Next.js. Kami mendefinisikan bagaimana kami dapat memulai migrasi, jika itu menguntungkan kami, ke alat yang lebih baru. Kami mengevaluasi berbagai strategi migrasi dan kami melihat beberapa contoh skenario yang dapat kami migrasikan ke proyek aplikasi web Next.js. Terakhir, kami melihat cara men-deploy aplikasi Next.js kami ke Netlify dan menjalankannya.
Bacaan dan Sumber Daya Lebih Lanjut
- Migrasi Frankenstein: Pendekatan Kerangka-Agnostik
- Menghapus jQuery dari antarmuka GitHub.com
- Memulai dengan Next.js
- Cara Menyebarkan Situs Next.js ke Netlify
- Artikel Next.js di Netlify Blog