Bagaimana Situs Web Berbasis API Saya Membantu Saya Berkeliling Dunia

Diterbitkan: 2022-03-10
Ringkasan cepat Setelah membangun beberapa situs web klien, mulai dari kafe kecil hingga perusahaan rintisan yang sedang berkembang, Stefan Judis menemukan bahwa editor suci WYSIWYG tidak selalu merupakan peluru perak yang kita semua cari. Antarmuka ini bertujuan untuk membuat situs web menjadi mudah, tetapi selalu ada lebih banyak kasus penggunaan untuk konten Anda di berbagai platform.

(Ini adalah posting bersponsor.) Baru-baru ini, saya memutuskan untuk membangun kembali situs web pribadi saya, karena sudah berusia enam tahun dan terlihat — dengan sopan — sedikit “ketinggalan zaman.” Tujuannya adalah untuk memasukkan beberapa informasi tentang diri saya, area blog, daftar proyek sampingan saya baru-baru ini, dan acara yang akan datang.

Saat saya melakukan pekerjaan klien dari waktu ke waktu, ada satu hal yang tidak ingin saya tangani — database ! Sebelumnya, saya membuat situs WordPress untuk semua orang yang menginginkan saya. Bagian pemrograman biasanya menyenangkan bagi saya, tetapi rilis, pemindahan database ke lingkungan yang berbeda, dan penerbitan yang sebenarnya, selalu mengganggu. Penyedia hosting murah hanya menawarkan antarmuka web yang buruk untuk mengatur database MySQL dan akses FTP untuk mengunggah file selalu merupakan bagian terburuk. Saya tidak ingin berurusan dengan ini untuk situs web pribadi saya.

Jadi persyaratan yang saya miliki untuk mendesain ulang adalah:

  • Tumpukan teknologi terkini berdasarkan JavaScript dan teknologi frontend.
  • Solusi manajemen konten untuk mengedit konten dari mana saja.
  • Situs berkinerja baik dengan hasil cepat.

Dalam artikel ini saya ingin menunjukkan kepada Anda apa yang saya buat dan bagaimana situs web saya ternyata menjadi teman harian saya.

Mendefinisikan Model Konten

Menerbitkan sesuatu di web tampaknya mudah. Pilih sistem manajemen konten (CMS) yang menyediakan editor WYSIWYG ( W hat You S ee I s W hat You G et ) untuk setiap halaman yang diperlukan dan semua editor dapat mengelola konten dengan mudah. Itu saja, kan?

Setelah membangun beberapa situs web klien, mulai dari kafe kecil hingga perusahaan rintisan yang sedang berkembang, saya menemukan bahwa editor suci WYSIWYG tidak selalu merupakan peluru perak yang kita semua cari. Antarmuka ini bertujuan untuk membuat situs web menjadi mudah, tetapi inilah intinya:

Membangun Situs Web Tidak Mudah

Untuk membangun dan mengedit konten situs web tanpa terus-menerus merusaknya, Anda harus memiliki pengetahuan mendalam tentang HTML dan setidaknya memahami sedikit CSS. Itu bukan sesuatu yang dapat Anda harapkan dari editor Anda.

Saya telah melihat tata letak kompleks yang mengerikan yang dibangun dengan editor WYSIWYG dan saya tidak dapat mulai menyebutkan semua situasi ketika semuanya berantakan karena sistemnya terlalu rapuh. Situasi ini menyebabkan pertengkaran dan ketidaknyamanan di mana semua pihak saling menyalahkan atas sesuatu yang tidak dapat dihindari. Saya selalu berusaha menghindari situasi ini dan menciptakan lingkungan yang nyaman dan stabil bagi editor untuk menghindari email marah yang berteriak, “Tolong! Semuanya rusak.”

Konten Terstruktur Menyelamatkan Anda Dari Masalah

Saya belajar dengan cepat bahwa orang jarang merusak sesuatu ketika saya membagi semua konten situs web yang dibutuhkan menjadi beberapa bagian, masing-masing terkait satu sama lain tanpa memikirkan representasi apa pun. Di WordPress, ini dapat dicapai dengan menggunakan jenis posting khusus. Setiap jenis posting kustom dapat menyertakan beberapa properti dengan bidang teks yang mudah dipahami. Saya mengubur konsep berpikir di halaman sepenuhnya.

Pengaturan WordPress dengan jenis posting khusus membuat pengeditan lebih mudah.

Tugas saya adalah menghubungkan potongan konten dan membangun halaman web dari blok konten ini. Ini berarti bahwa editor hanya dapat melakukan sedikit, jika ada, perubahan visual di situs web mereka. Mereka bertanggung jawab atas konten dan hanya konten. Perubahan visual harus dilakukan oleh saya — tidak semua orang dapat mendesain situs, dan kami dapat menghindari lingkungan yang rapuh. Konsep ini terasa seperti pertukaran yang hebat dan biasanya diterima dengan baik.

Kemudian, saya menemukan bahwa apa yang saya lakukan adalah mendefinisikan model konten. Rachel Lovinger mendefinisikan, dalam artikelnya yang sangat bagus “Content Modelling: A Master Skill,” sebuah model konten sebagai berikut:

“Model konten mendokumentasikan semua jenis konten berbeda yang akan Anda miliki untuk proyek tertentu. Ini berisi definisi terperinci dari setiap elemen tipe konten dan hubungannya satu sama lain.”

Dimulai dengan pemodelan konten bekerja dengan baik untuk sebagian besar klien, kecuali satu.

“Stefan, Saya Tidak Mendefinisikan Skema Basis Data Anda!”

Ide dari proyek yang satu ini adalah untuk membangun situs web besar-besaran yang harus menghasilkan banyak lalu lintas organik dengan menyediakan banyak konten — dalam semua variasi yang ditampilkan di beberapa halaman dan tempat yang berbeda. Saya mengadakan pertemuan untuk membahas strategi kami untuk mendekati proyek ini.

Saya ingin mendefinisikan semua halaman dan model konten yang harus disertakan. Tidak masalah widget kecil apa atau sidebar apa yang ada dalam pikiran klien, saya ingin itu didefinisikan dengan jelas. Tujuan saya adalah membuat struktur konten yang solid yang memungkinkan untuk menyediakan antarmuka yang mudah digunakan bagi editor dan menyediakan data yang dapat digunakan kembali untuk menampilkannya dalam format apa pun yang dapat dipikirkan.

Ternyata, ide proyek ini tidak terlalu jelas, dan saya tidak bisa mendapatkan jawaban atas semua pertanyaan saya. Pimpinan proyek tidak mengerti bahwa kita harus memulai dengan pemodelan konten yang tepat (bukan desain dan pengembangan). Baginya, ini hanya satu ton halaman. Konten duplikat dan area teks besar untuk menambahkan sejumlah besar teks, sepertinya tidak menjadi masalah. Dalam benaknya, pertanyaan yang saya miliki tentang struktur bersifat teknis, dan mereka tidak perlu mengkhawatirkannya. Singkat cerita, saya tidak mengerjakan proyeknya.

Yang penting, pemodelan konten bukan tentang database.

Ini tentang membuat konten Anda dapat diakses dan tahan masa depan. Jika Anda tidak dapat menentukan kebutuhan konten Anda pada awal proyek, akan sangat sulit, jika bukan tidak mungkin, untuk menggunakannya kembali nanti.

Pemodelan konten yang tepat adalah kunci untuk situs web sekarang dan masa depan.

Contentful: CMS Tanpa Kepala

Jelas bahwa saya ingin mengikuti pemodelan konten yang baik untuk situs saya juga. Namun, ada satu hal lagi. Saya tidak ingin berurusan dengan lapisan penyimpanan untuk membangun situs web baru saya, jadi saya memutuskan untuk menggunakan Contentful, CMS tanpa kepala, yang (penafian penuh!) yang sedang saya kerjakan. "Headless" berarti bahwa layanan ini menawarkan antarmuka web untuk mengelola konten di cloud dan menyediakan API yang akan mengembalikan data saya dalam format JSON. Memilih CMS ini membantu saya menjadi produktif segera karena saya memiliki API yang tersedia dalam hitungan menit dan saya tidak harus berurusan dengan pengaturan infrastruktur apa pun. Contentful juga menyediakan paket gratis yang sempurna untuk proyek kecil, seperti situs web pribadi saya.

Contoh kueri untuk mendapatkan semua posting blog terlihat seperti ini:

 <a href="https://cdn.contentful.com/spaces/space_id/entries?access_token=access_token&content_type=post">https://cdn.contentful.com/spaces/space_id/entries?access_token=access_token&content_type=post</a>

Dan responsnya, dalam versi singkat, terlihat seperti ini:

 { "sys": { "type": "Array" }, "total": 7, "skip": 0, "limit": 100, "items": [ { "sys": { "space": {...}, "id": "455OEfg1KUskygWUiKwmkc", "type": "Entry", "createdAt": "2016-07-29T11:53:52.596Z", "updatedAt": "2016-11-09T21:07:19.118Z", "revision": 12, "contentType": {...}, "locale": "en-US" }, "fields": { "title": "How to React to Changing Environments Using matchMedia", "excerpt": "...", "slug": "how-to-react-to-changing-environments-using-match-media", "author": [...], "body": "...", "date": "2014-12-26T00:00+02:00", "comments": true, "externalUrl": "https://4waisenkinder.de/blog/2014/12/26/handle-environment-changes-via-window-dot-matchmedia/" }, {...}, {...}, {...}, {...}, {...}, {...} ] } }

Bagian hebat tentang Contentful adalah hebat dalam pemodelan konten, yang saya butuhkan. Menggunakan antarmuka web yang disediakan, saya dapat menentukan semua bagian konten yang dibutuhkan dengan cepat. Definisi model konten tertentu di Contentful disebut tipe konten. Hal yang hebat untuk ditunjukkan di sini adalah kemampuan untuk memodelkan hubungan antara item konten. Misalnya, saya dapat dengan mudah menghubungkan penulis dengan posting blog. Ini dapat menghasilkan pohon data terstruktur, yang sempurna untuk digunakan kembali untuk berbagai kasus penggunaan.

Penyiapan tipe konten menggunakan editor model konten (Pratinjau besar)

Jadi, saya menyiapkan model konten saya tanpa memikirkan halaman apa pun yang mungkin ingin saya buat di masa mendatang.

Model konten untuk situs web

Langkah selanjutnya adalah mencari tahu apa yang ingin saya lakukan dengan data ini. Saya bertanya kepada seorang desainer yang saya kenal, dan dia datang dengan halaman indeks situs web dengan struktur berikut.

Mockup untuk halaman indeks situs web

Merender Halaman HTML Menggunakan Node.js

Sekarang sampai pada bagian yang sulit. Sejauh ini, saya tidak harus berurusan dengan penyimpanan dan database, yang merupakan pencapaian besar bagi saya. Jadi, bagaimana saya bisa membangun situs web saya ketika saya hanya memiliki API yang tersedia?

Pendekatan pertama saya adalah pendekatan do-it-yourself. Saya mulai menulis skrip Node.js sederhana yang akan mengambil data dan merender beberapa HTML darinya.

Merender semua file HTML di muka memenuhi salah satu persyaratan utama saya. HTML statis dapat disajikan dengan sangat cepat.

Jadi, mari kita lihat skrip yang saya gunakan.

 'use strict'; const contentful = require('contentful'); const template = require('lodash.template'); const fs = require('fs'); // create contentful client with particular credentials const client = contentful.createClient({ space: 'your_space_id', accessToken: 'your_token' }); // cache templates to not read // them over and over again const TEMPLATES = { index : template(fs.readFileSync(`${__dirname}/templates/index.html`)) }; // fetch all the data Promise.all([ // get posts client.getEntries({content_type: 'content_type_post_id'}), // get events client.getEntries({content_type: 'content_type_event_id'}), // get projects client.getEntries({content_type: 'content_type_project_id'}), // get talk client.getEntries({content_type: 'content_type_talk_id'}), // get specific person client.getEntries({'sys.id': 'person_id'}) ]) .then(([posts, events, projects, talks, persons]) => { const renderedHTML = TEMPLATES.index({ posts, events, projects, talks, person : persons.items[0] }) fs.writeFileSync(`${__dirname}/build/index.html`, renderedHTML); console.log('Rendered HTML'); }) .catch(console.error);
 <!doctype html> <html lang="en"> <head> <!-- ... --> </head> <body> <!-- ... --> <h2>Posts</h2> <ul> <% posts.items.forEach( function( talk ) { %> <li><%- talk.fields.title %> <% }) %> </ul> <!-- ... --> </body> </html>

Ini bekerja dengan baik. Saya dapat membangun situs web yang saya inginkan dengan cara yang sepenuhnya fleksibel, membuat semua keputusan tentang struktur dan fungsionalitas file. Rendering jenis halaman yang berbeda dengan set data yang sama sekali berbeda tidak ada masalah sama sekali. Semua orang yang telah berjuang melawan aturan dan struktur CMS yang ada yang dikirimkan dengan rendering HTML tahu bahwa kebebasan penuh bisa menjadi hal yang luar biasa. Terutama, ketika model data menjadi lebih kompleks dari waktu ke waktu termasuk banyak relasi — fleksibilitas terbayar.

Dalam skrip Node.js ini, klien Contentful SDK dibuat dan semua data diambil menggunakan metode klien getEntries . Semua metode klien yang disediakan didorong oleh janji, yang memudahkan untuk menghindari panggilan balik yang sangat bersarang. Untuk templating, saya memutuskan untuk menggunakan mesin templating lodash. Terakhir, untuk membaca dan menulis file, Node.js menawarkan modul fs asli, yang kemudian digunakan untuk membaca template dan menulis HTML yang dirender.

Namun, ada satu kelemahan dari pendekatan ini; itu sangat telanjang. Bahkan ketika metode ini sepenuhnya fleksibel, rasanya seperti menciptakan kembali roda. Apa yang saya bangun pada dasarnya adalah generator situs statis, dan sudah ada banyak di luar sana. Sudah waktunya untuk memulai dari awal lagi.

Pergi Untuk Generator Situs Statis Nyata

Generator situs statis terkenal, misalnya, Jekyll atau Middleman, biasanya menangani file penurunan harga yang akan dirender ke HTML. Editor bekerja dengan ini, dan situs web dibuat menggunakan perintah CLI. Pendekatan ini gagal salah satu persyaratan awal saya, meskipun. Saya ingin dapat mengedit situs di mana pun saya berada, tidak bergantung pada file yang ada di komputer pribadi saya.

Ide pertama saya adalah membuat file penurunan harga ini menggunakan API. Meskipun ini akan berhasil, rasanya tidak benar. Merender file penurunan harga untuk diubah menjadi HTML nanti masih merupakan dua langkah yang tidak menawarkan manfaat besar dibandingkan dengan solusi awal saya.

Untungnya, ada integrasi Contentful, misalnya Metalsmith dan Middleman. Saya memutuskan Metalsmith untuk proyek ini, seperti yang tertulis di Node.js dan saya tidak ingin membawa ketergantungan Ruby.

Metalsmith mengubah file dari folder sumber dan merendernya di folder tujuan. File-file ini tidak harus berupa file penurunan harga. Anda juga dapat menggunakannya untuk transpiling Sass atau mengoptimalkan gambar Anda. Tidak ada batasan, dan sangat fleksibel.

Dengan menggunakan integrasi Contentful, saya dapat mendefinisikan beberapa file sumber yang diambil sebagai file konfigurasi dan kemudian dapat mengambil semua yang diperlukan dari API.

 --- title: Blog contentful: content_type: content_type_id entry_filename_pattern: ${ fields.slug } entry_template: article.html order: '-fields.date' filter: include: 5 layout: blog.html description: >- Recent articles by Stefan Judis. ---

Konfigurasi contoh ini merender area posting blog dengan file blog.html induk, termasuk respons dari permintaan API, tetapi juga merender beberapa halaman anak menggunakan template article.html . Nama file untuk halaman anak ditentukan melalui entry_filename_pattern .

Seperti yang Anda lihat, dengan sesuatu seperti ini, saya dapat membangun halaman saya dengan mudah. Pengaturan ini bekerja dengan sempurna untuk memastikan semua halaman bergantung pada API.

Hubungkan Layanan Dengan Proyek Anda

Satu-satunya bagian yang hilang adalah menghubungkan situs dengan layanan CMS dan membuatnya dirender ulang ketika ada konten yang diedit. Solusi untuk masalah ini — webhook, yang mungkin sudah Anda kenal jika Anda menggunakan layanan seperti GitHub.

Webhook adalah permintaan yang dibuat oleh perangkat lunak sebagai layanan ke titik akhir yang ditentukan sebelumnya yang memberi tahu Anda bahwa sesuatu telah terjadi. GitHub, misalnya, dapat mem-ping Anda kembali ketika seseorang membuka pull request di salah satu repo Anda. Mengenai manajemen konten, kami dapat menerapkan prinsip yang sama di sini. Setiap kali sesuatu terjadi dengan konten, ping titik akhir dan buat lingkungan tertentu bereaksi terhadapnya. Dalam kasus kami, ini berarti merender ulang HTML menggunakan metalsmith.

Untuk menerima webhook, saya juga menggunakan solusi JavaScript. Penyedia hosting pilihan saya (Uberspace) memungkinkan untuk menginstal Node.js dan menggunakan JavaScript di sisi server.

 const http = require('http'); const exec = require('child_process').exec; const server = http.createServer((req, res) => { res.setHeader('Content-Type', 'text/plain'); // check for secret header // to not open up this endpoint for everybody if (req.headers.secret === 'YOUR_SECRET') { res.end('ok'); // wait for the CDN to // invalidate the data setTimeout(() => { // execute command exec('npm start', { cwd: __dirname }, (error) => { if (error) { return console.log(error); } console.log('Rebuilt success'); }); }, 1000 * 120 ); } else { res.end('Not allowed'); } }); console.log('Started server at 8000'); server.listen(8000);

Skrip ini memulai server HTTP sederhana pada port 8000. Skrip ini memeriksa permintaan masuk untuk header yang tepat untuk memastikan bahwa itu adalah webhook dari Contentful. Jika permintaan dikonfirmasi sebagai webhook, perintah standar npm start dijalankan untuk merender ulang semua halaman HTML. Anda mungkin bertanya-tanya mengapa ada batas waktu. Ini diperlukan untuk menjeda tindakan sejenak hingga data di cloud tidak valid karena data yang disimpan disajikan dari CDN.

Tergantung pada lingkungan Anda, server HTTP ini mungkin tidak dapat diakses ke internet. Situs saya dilayani menggunakan server apache, jadi saya perlu menambahkan aturan penulisan ulang internal untuk membuat server node yang berjalan dapat diakses ke internet.

 # add node endpoint to enable webhooks RewriteRule ^rerender/(.*) https://localhost:8000/$1 [P]

API-Pertama Dan Data Terstruktur: Sahabat Selamanya

Pada titik ini, saya dapat mengelola semua data saya di cloud dan situs web saya akan bereaksi sesuai setelah perubahan.

Pengulangan di Semua Tempat

Berada di jalan adalah bagian penting dalam hidup saya, jadi saya perlu memiliki informasi, seperti lokasi tempat tertentu atau hotel mana yang saya pesan, tepat di ujung jari saya — biasanya disimpan dalam spreadsheet Google. Sekarang, informasi itu tersebar di spreadsheet, beberapa email, kalender saya, dan juga di situs web saya.

Harus saya akui, saya membuat banyak duplikasi data dalam aliran harian saya.

Momen Data Terstruktur

Saya memimpikan satu sumber kebenaran, (sebaiknya di ponsel saya) untuk dengan cepat melihat acara apa yang akan datang, tetapi juga mendapatkan informasi tambahan tentang hotel dan tempat. Acara yang terdaftar di situs web saya tidak memiliki semua informasi pada saat ini, tetapi sangat mudah untuk menambahkan bidang baru ke jenis konten di Contentful. Jadi, saya menambahkan bidang yang diperlukan ke tipe konten "Acara".

Memasukkan informasi ini ke dalam CMS situs web saya tidak pernah menjadi niat saya, karena seharusnya tidak ditampilkan secara online, tetapi karena dapat diakses melalui API membuat saya sadar bahwa sekarang saya dapat melakukan hal yang sama sekali berbeda dengan data ini.

Menambahkan lebih banyak informasi ke dalam bidang acara (Pratinjau besar)

Membangun Aplikasi Asli Dengan JavaScript

Membangun aplikasi untuk seluler telah menjadi topik selama bertahun-tahun sekarang, dan ada beberapa pendekatan untuk ini. Progressive Web Apps (PWA) adalah topik yang sangat hangat akhir-akhir ini. Dengan menggunakan Service Worker dan Manifes Aplikasi Web, Anda dapat membangun pengalaman seperti aplikasi yang lengkap mulai dari ikon layar beranda hingga perilaku offline terkelola menggunakan teknologi web.

Ada satu kelemahan lagi. Aplikasi Web Progresif sedang meningkat, tetapi belum sepenuhnya ada. Service Worker, misalnya, tidak didukung di Safari hari ini dan sejauh ini hanya "dalam pertimbangan" dari pihak Apple. Ini adalah pemecah kesepakatan bagi saya karena saya juga ingin memiliki aplikasi berkemampuan offline di iPhone.

Jadi saya mencari alternatif. Seorang teman saya sangat menyukai NativeScript dan terus memberi tahu saya tentang teknologi yang cukup baru ini. NativeScript adalah kerangka kerja sumber terbuka untuk membangun aplikasi seluler asli dengan JavaScript, jadi saya memutuskan untuk mencobanya.

Mengenal NativeScript

Penyiapan NativeScript membutuhkan waktu karena Anda harus menginstal banyak hal untuk dikembangkan untuk lingkungan seluler asli. Anda akan dipandu melalui proses instalasi saat Anda menginstal alat baris perintah NativeScript untuk pertama kalinya menggunakan npm install nativescript -g .

Kemudian, Anda dapat menggunakan perintah scaffolding untuk menyiapkan proyek baru: tns create MyNewApp

Namun, bukan ini yang saya lakukan. Saya sedang memindai dokumentasi dan menemukan contoh aplikasi manajemen bahan makanan yang dibangun di dalam NativeScript. Jadi saya mengambil aplikasi ini, menggali kodenya, dan memodifikasinya selangkah demi selangkah, menyesuaikannya dengan kebutuhan saya.

Saya tidak ingin menyelam terlalu jauh ke dalam prosesnya, tetapi untuk membuat daftar yang terlihat bagus dengan semua informasi yang saya inginkan, tidak butuh waktu lama.

NativeScript bermain sangat baik bersama dengan Angular 2, yang saya tidak ingin coba kali ini karena menemukan NativeScript sendiri terasa cukup besar. Di NativeScript Anda harus menulis "Tampilan." Setiap tampilan terdiri dari file XML yang mendefinisikan tata letak dasar dan JavaScript dan CSS opsional. Semua ini didefinisikan dalam satu folder per tampilan.

Rendering daftar sederhana dapat dicapai dengan template XML seperti ini:

 <!-- call JavaScript function when ready --> <Page loaded="loaded"> <ActionBar title="All Travels" /> <!-- make it scrollable when going too big --> <ScrollView> <!-- iterate over the entries in context --> <ListView items="{{ entries }}"> <ListView.itemTemplate> <Label text="{{ fields.name }}" textWrap="true" class="headline"/> </ListView.itemTemplate> </ListView> </ScrollView> </Page>

Hal pertama yang terjadi di sini adalah mendefinisikan elemen halaman. Di dalam halaman ini, saya mendefinisikan ActionBar untuk memberikan tampilan Android klasik serta judul yang tepat. Membangun sesuatu untuk lingkungan asli terkadang bisa sedikit rumit. Misalnya, untuk mencapai perilaku gulir yang berfungsi, Anda harus menggunakan 'ScrollView.' Hal terakhir adalah, cukup ulangi acara saya menggunakan ListView . Secara keseluruhan, rasanya cukup mudah!

Tapi dari mana entri ini berasal yang digunakan dalam tampilan? Ternyata ada objek konteks bersama yang bisa digunakan untuk itu. Saat membaca XML untuk tampilan, Anda mungkin telah memperhatikan bahwa halaman tersebut memiliki kumpulan atribut yang loaded . Dengan menyetel atribut ini, saya memberi tahu tampilan untuk memanggil fungsi JavaScript tertentu saat halaman dimuat.

Fungsi JavaScript ini didefinisikan dalam file JS tergantung. Itu dapat diakses hanya dengan mengekspornya menggunakan exports.something . Untuk menambahkan pengikatan data, yang harus kita lakukan adalah menyetel Observable baru ke properti halaman bindingContext . Observables di NativeScript memancarkan event propertyChange yang diperlukan untuk bereaksi terhadap perubahan data di dalam 'iews, tetapi Anda tidak perlu khawatir tentang itu, karena ini bekerja di luar kotak.

 const context = new Observable({ entries: null}); const fetchModule = require('fetch'); // export loaded to be called from // List.xml when everything is loaded exports.loaded = (args) => { const page = args.object; page.bindingContext = context; fetchModule.fetch( `https://cdn.contentful.com/spaces/${config.space}/entries?access_token=${config.cda.token}&content_type=event&order=fields.start`, { method: "GET", headers: { 'Content-Type': 'application/json' } } ) .then(response => response.json()) .then(response => context.set('entries', response.items)); }

Hal terakhir adalah mengambil data dan mengaturnya ke konteks. Ini dapat dilakukan dengan menggunakan modul fetch NativeScript. Di sini, Anda dapat melihat hasilnya.

Pratinjau besar

Jadi, seperti yang Anda lihat — membuat daftar sederhana menggunakan NativeScript tidak terlalu sulit. Saya kemudian memperluas aplikasi dengan tampilan lain serta fungsionalitas tambahan untuk membuka alamat yang diberikan di Google Maps dan tampilan web untuk melihat situs web acara.

Satu hal yang perlu diperhatikan di sini adalah, NativeScript masih cukup baru, yang berarti bahwa plugin yang ditemukan di npm biasanya tidak memiliki banyak unduhan atau bintang di GitHub. Ini membuat saya kesal pada awalnya, tetapi saya menggunakan beberapa komponen asli (nativescript-floatingactionbutton, nativescript-advanced-webview dan nativescript-pulltorefresh) yang membantu saya mencapai pengalaman asli dan semuanya bekerja dengan baik.

Anda dapat melihat hasil yang ditingkatkan di sini:

Pratinjau besar

Semakin banyak fungsionalitas yang saya masukkan ke dalam aplikasi ini, semakin saya menyukainya dan semakin saya menggunakannya. Bagian terbaiknya adalah, saya dapat menghilangkan duplikasi data, mengelola semua data di satu tempat, sekaligus cukup fleksibel untuk menampilkannya untuk berbagai kasus penggunaan.

Halaman yang Kemarin: Konten Terstruktur yang Berumur Panjang!

Membangun aplikasi ini menunjukkan kepada saya sekali lagi bahwa prinsip memiliki data dalam format halaman adalah sesuatu dari masa lalu. Kami tidak tahu kemana data kami akan pergi — kami harus siap untuk jumlah kasus penggunaan yang tidak terbatas.

Melihat ke belakang, apa yang saya capai adalah:

  • Memiliki sistem manajemen konten di cloud
  • Tidak harus berurusan dengan pemeliharaan basis data
  • Tumpukan teknologi JavaScript lengkap
  • Memiliki situs web statis yang efisien
  • Memiliki aplikasi Android untuk mengakses konten saya setiap saat dan di mana saja

Dan bagian terpenting:

Memiliki konten saya terstruktur dan dapat diakses membantu saya untuk meningkatkan kehidupan sehari-hari saya.

Kasus penggunaan ini mungkin terlihat sepele bagi Anda saat ini, tetapi ketika Anda memikirkan produk yang Anda buat setiap hari — selalu ada lebih banyak kasus penggunaan untuk konten Anda di berbagai platform. Hari ini, kami menerima bahwa perangkat seluler akhirnya mengambil alih lingkungan desktop sekolah lama, tetapi platform seperti mobil, jam tangan, dan bahkan lemari es sudah menunggu sorotan mereka. Saya bahkan tidak bisa memikirkan kasus penggunaan yang akan datang.

Jadi, mari kita coba bersiap dan meletakkan konten terstruktur di tengah karena pada akhirnya ini bukan tentang skema database — ini tentang membangun untuk masa depan.

Bacaan Lebih Lanjut tentang SmashingMag:

  • Pengikisan Web Dengan Node.js
  • Berlayar Dengan Sails.js: Kerangka Gaya MVC Untuk Node.js
  • 40 Ikon Perjalanan Untuk Merapikan Desain Anda
  • Pengantar Rinci Untuk Webpack