API Güdümlü Web Sitem Dünyayı Seyahat Etmeme Nasıl Yardımcı Oluyor?

(Bu sponsorlu bir gönderidir.) Geçenlerde, kişisel web sitemi yeniden oluşturmaya karar verdim, çünkü site altı yaşındaydı ve kibarca konuşmak gerekirse, biraz "modası geçmiş" görünüyordu. Amaç kendimle ilgili bazı bilgileri, bir blog alanını, son yan projelerimin bir listesini ve yaklaşan etkinlikleri eklemekti.

Zaman zaman müşteri işi yaptığım için uğraşmak istemediğim bir şey vardı - veritabanları ! Daha önce, beni isteyen herkes için WordPress siteleri kurdum. Programlama kısmı benim için genellikle eğlenceliydi, ancak sürümler, veritabanlarının farklı ortamlara taşınması ve gerçek yayıncılık her zaman can sıkıcıydı. Ucuz barındırma sağlayıcıları, MySQL veritabanlarını kurmak için yalnızca zayıf web arayüzleri sunar ve dosyaları yüklemek için bir FTP erişimi her zaman en kötü kısımdı. Kişisel web sitem için bununla uğraşmak istemedim.

Yani yeniden tasarım için sahip olduğum gereksinimler şunlardı:

• JavaScript ve ön uç teknolojilerine dayalı güncel bir teknoloji yığını.
• İçeriği her yerden düzenlemek için bir içerik yönetimi çözümü.
• Hızlı sonuçlar veren iyi performans gösteren bir site.

Bu yazıda size ne yaptığımı ve web sitemin nasıl şaşırtıcı bir şekilde günlük yoldaşım olduğunu göstermek istiyorum.

İçerik Modeli Tanımlama

Web'de bir şeyler yayınlamak kolay görünüyor. İhtiyaç duyulan her sayfa için bir WYSIWYG düzenleyicisi ( Ne Görüyorsanız Neler Alırsınız ) sağlayan bir içerik yönetim sistemi ( CMS ) seçin ve tüm editörler içeriği kolayca yönetebilir. Bu kadar, değil mi?

Küçük kafelerden büyüyen startuplara kadar çeşitli müşteri web siteleri oluşturduktan sonra, kutsal WYSIWYG editörünün her zaman aradığımız gümüş kurşun olmadığını anladım. Bu arayüzler, web siteleri oluşturmayı kolaylaştırmayı amaçlar, ancak asıl nokta şudur:

Web Siteleri Oluşturmak Kolay Değil

Bir web sitesinin içeriğini sürekli bozmadan oluşturmak ve düzenlemek için, derin HTML bilgisine sahip olmanız ve en azından biraz CSS anlamanız gerekir. Bu, editörlerinizden bekleyebileceğiniz bir şey değil.

WYSIWYG editörleriyle oluşturulmuş korkunç karmaşık düzenler gördüm ve sistem çok kırılgan olduğu için her şeyin dağıldığı tüm durumları adlandırmaya başlayamıyorum. Bu durumlar, kaçınılmaz olan bir şey için tüm tarafların birbirini suçladığı kavgalara ve rahatsızlıklara yol açar. Her zaman bu durumlardan kaçınmaya ve editörlerin “Yardım edin! Her şey kırıldı."

Yapılandırılmış İçerik Size Biraz Sorun Kurtarır

Oldukça hızlı bir şekilde, gerekli tüm web sitesi içeriğini, herhangi bir temsil düşünmeden birbiriyle ilişkili birkaç parçaya böldüğümde, insanların nadiren bir şeyleri kırdığını öğrendim. WordPress'te bu, özel gönderi türleri kullanılarak elde edilebilir. Her özel gönderi türü, kavranması kolay kendi metin alanına sahip birkaç özellik içerebilir. Düşünme kavramını tamamen sayfalara gömdüm.

Benim işim içerik parçalarını birbirine bağlamak ve bu içerik bloklarından web sayfaları oluşturmaktı. Bu, editörlerin web sitelerinde çok az görsel değişiklik yapabildikleri anlamına geliyordu. İçerikten ve sadece içerikten sorumluydular. Görsel değişikliklerin benim tarafımdan yapılması gerekiyordu - herkes siteyi şekillendiremez ve kırılgan bir ortamdan kaçınabilirdik. Bu konsept büyük bir takas gibi geldi ve genellikle iyi karşılandı.

Daha sonra, yaptığım şeyin bir içerik modeli tanımlamak olduğunu keşfettim. Rachel Lovinger, “Content Modelling: A Master Skill” adlı mükemmel makalesinde bir içerik modelini şu şekilde tanımlar:

“Bir içerik modeli, belirli bir proje için sahip olacağınız tüm farklı içerik türlerini belgeler. Her içerik türünün öğelerinin ayrıntılı tanımlarını ve bunların birbirleriyle olan ilişkilerini içerir.”

İçerik modelleme ile başlamak, biri hariç çoğu müşteri için iyi sonuç verdi.

“Stefan, Veritabanı Şemanızı Tanımlamıyorum!”

Bu tek projenin fikri, birkaç farklı sayfa ve yerde görüntülenen tüm varyasyonlarda tonlarca içerik sağlayarak çok fazla organik trafik oluşturması gereken devasa bir web sitesi oluşturmaktı. Bu projeye yaklaşma stratejimizi tartışmak için bir toplantı ayarladım.

Dahil edilmesi gereken tüm sayfaları ve içerik modellerini tanımlamak istedim. İstemcinin aklında hangi küçük widget'ın veya hangi kenar çubuğunun olduğu önemli değildi, açıkça tanımlanmasını istedim. Amacım, editörler için kullanımı kolay bir arayüz sağlamayı mümkün kılan ve yeniden kullanılabilir verileri akla gelebilecek herhangi bir formatta görüntülemek için sağlam bir içerik yapısı oluşturmaktı.

Bu proje fikrinin çok net olmadığı ortaya çıktı ve tüm sorularıma cevap alamadım. Proje lideri, uygun içerik modelleme ile başlamamız gerektiğini anlamadı (tasarım ve geliştirme değil). Onun için bu sadece bir ton sayfaydı. Yinelenen içerik ve büyük miktarda metin eklemek için büyük metin alanları bir sorun gibi görünmüyordu. Kafasında, yapıyla ilgili sorularım teknikti ve onlar için endişelenmelerine gerek yoktu. Kısaca anlatmak gerekirse, projeyi ben yapmadım.

Önemli olan, içerik modellemenin veritabanlarıyla ilgili olmamasıdır.

İçeriğinizi erişilebilir ve geleceğe hazır hale getirmekle ilgilidir. Proje başlangıcında içeriğinizin ihtiyaçlarını tanımlayamazsanız, daha sonra yeniden kullanmak imkansız değilse de çok zor olacaktır.

Doğru içerik modelleme, mevcut ve gelecekteki web sitelerinin anahtarıdır.

İçerikli: Başsız Bir CMS

Sitem için de iyi bir içerik modellemesi yapmak istediğim açıktı. Ancak bir şey daha vardı. Yeni web sitemi oluşturmak için depolama katmanıyla uğraşmak istemedim, bu yüzden şu anda üzerinde çalıştığım (tam sorumluluk reddi!) başsız bir CMS olan Contentful'u kullanmaya karar verdim. "Başsız", bu hizmetin buluttaki içeriği yönetmek için bir web arayüzü sunduğu ve verilerimi JSON formatında bana geri verecek bir API sağladığı anlamına gelir. Bu CMS'yi seçmek, dakikalar içinde bir API'ye sahip olduğum ve herhangi bir altyapı kurulumuyla uğraşmak zorunda olmadığım için hemen üretken olmama yardımcı oldu. Contentful ayrıca kişisel web sitem gibi küçük projeler için mükemmel olan ücretsiz bir plan sunar.

Tüm blog gönderilerini almak için örnek bir sorgu şöyle görünür:

 <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>

Ve yanıt, kısaltılmış bir versiyonda şöyle görünür:

 { "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/" }, {...}, {...}, {...}, {...}, {...}, {...} ] } }

Contentful'ın en güzel yanı, ihtiyacım olan içerik modellemede harika olmasıdır. Sağlanan web arayüzünü kullanarak gerekli tüm içerik parçalarını hızlı bir şekilde tanımlayabilirim. Contentful'daki belirli bir içerik modelinin tanımına içerik türü denir. Burada belirtilmesi gereken harika bir şey, içerik öğeleri arasındaki ilişkileri modelleme yeteneğidir. Örneğin, bir yazarı bir blog yazısıyla kolayca bağlayabilirim. Bu, çeşitli kullanım durumları için yeniden kullanım için mükemmel olan yapılandırılmış veri ağaçlarıyla sonuçlanabilir.

Bu nedenle, gelecekte oluşturmak isteyebileceğim sayfaları düşünmeden içerik modelimi kurdum.

Bir sonraki adım, bu verilerle ne yapmak istediğimi bulmaktı. Tanıdığım bir tasarımcıya sordum ve web sitesinin aşağıdaki yapıya sahip bir dizin sayfası buldu.

Node.js Kullanarak HTML Sayfaları Oluşturma

Şimdi zor kısım geldi. Şimdiye kadar depolama ve veritabanlarıyla uğraşmak zorunda kalmadım, bu benim için büyük bir başarıydı. Öyleyse, yalnızca bir API'm olduğunda web sitemi nasıl oluşturabilirim?

İlk yaklaşımım kendin yap yaklaşımıydı. Verileri alacak ve ondan bir miktar HTML oluşturacak basit bir Node.js betiği yazmaya başladım.

Tüm HTML dosyalarını önceden oluşturmak, temel gereksinimlerimden birini yerine getirdi. Statik HTML gerçekten hızlı sunulabilir.

Şimdi kullandığım scripte bir göz atalım.

 '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>

Bu iyi çalıştı. Dosya yapısı ve işlevselliği ile ilgili tüm kararları vererek, istediğim web sitesini tamamen esnek bir şekilde oluşturabilirim. Tamamen farklı veri kümeleriyle farklı sayfa türleri oluşturmak hiç sorun değildi. HTML oluşturma ile birlikte gelen mevcut bir CMS'nin kurallarına ve yapısına karşı savaşan herkes, tam özgürlüğün mükemmel bir şey olabileceğini bilir. Özellikle, veri modeli birçok ilişki içeren zaman içinde daha karmaşık hale geldiğinde, esneklik karşılığını verir.

Bu Node.js betiğinde, bir Contentful SDK istemcisi oluşturulur ve tüm veriler getEntries istemci yöntemi kullanılarak getirilir. İstemcinin sağladığı tüm yöntemler vaat odaklıdır, bu da derinlemesine iç içe geçmiş geri aramalardan kaçınmayı kolaylaştırır. Şablonlama için lodash'ın şablonlama motorunu kullanmaya karar verdim. Son olarak, dosya okuma ve yazma için Node.js, daha sonra şablonları okumak ve oluşturulan HTML'yi yazmak için kullanılan yerel fs modülünü sunar.

Ancak bu yaklaşımın bir dezavantajı vardı; çok çıplaktı. Bu yöntem tamamen esnek olduğunda bile, tekerleği yeniden icat etmek gibi geldi. İnşa ettiğim şey temelde statik bir site oluşturucuydu ve zaten piyasada bunlardan bolca var. Her şeye yeniden başlama zamanıydı.

Gerçek Bir Statik Site Oluşturucuya Gitmek

Ünlü statik site oluşturucular, örneğin Jekyll veya Middleman, genellikle HTML'ye dönüştürülecek Markdown dosyalarıyla ilgilenir. Editörler bunlarla çalışır ve web sitesi bir CLI komutu kullanılarak oluşturulur. Yine de bu yaklaşım, ilk gereksinimlerimden birinde başarısız oluyordu. Özel bilgisayarımda duran dosyalara güvenmeden, nerede olursam olayım siteyi düzenleyebilmek istedim.

İlk fikrim, bu Markdown dosyalarını API kullanarak oluşturmaktı. Bu işe yaramış olsa da, doğru gelmiyordu. Markdown dosyalarını daha sonra HTML'ye dönüştürmek için işlemek, ilk çözümüme kıyasla hala büyük bir fayda sağlamayan iki adımdı.

Neyse ki, örneğin Metalsmith ve Middleman için Contentful entegrasyonları var. Node.js'de yazıldığı ve Ruby bağımlılığı getirmek istemediğim için bu proje için Metalsmith'e karar verdim.

Metalsmith, dosyaları bir kaynak klasörden dönüştürür ve onları bir hedef klasörde işler. Bu dosyaların mutlaka Markdown dosyaları olması gerekmez. Sass'ı aktarmak veya resimlerinizi optimize etmek için de kullanabilirsiniz. Sınır yoktur ve gerçekten esnektir.

Contentful entegrasyonunu kullanarak, yapılandırma dosyaları olarak alınan bazı kaynak dosyaları tanımlayabildim ve ardından API'den gereken her şeyi getirebildim.

 --- 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. ---

Bu örnek yapılandırma, blog gönderisi alanını API isteğinin yanıtı da dahil olmak üzere bir üst blog.html dosyasıyla işler, ancak aynı zamanda article.html şablonunu kullanarak birkaç alt sayfa oluşturur. Alt sayfalar için dosya adları entry_filename_pattern aracılığıyla tanımlanır.

Gördüğünüz gibi, böyle bir şeyle sayfalarımı kolayca oluşturabiliyorum. Bu kurulum, tüm sayfaların API'ye bağımlı olmasını sağlamak için mükemmel bir şekilde çalıştı.

Hizmeti Projenize Bağlayın

Eksik olan tek kısım, siteyi CMS hizmetine bağlamak ve herhangi bir içerik düzenlendiğinde yeniden oluşturmasını sağlamaktı. Bu sorunun çözümü — GitHub gibi hizmetleri kullanıyorsanız zaten aşina olabileceğiniz web kancaları.

Web kancaları, bir şeyin olduğunu size bildiren, önceden tanımlanmış bir uç noktaya hizmet olarak yazılım tarafından yapılan isteklerdir. Örneğin GitHub, biri depolarınızdan birinde bir çekme isteği açtığında size geri ping atabilir. İçerik yönetimi ile ilgili olarak, aynı prensibi burada da uygulayabiliriz. İçerikle ilgili bir şey olduğunda, bir uç noktaya ping atın ve belirli bir ortamın buna tepki vermesini sağlayın. Bizim durumumuzda bu, metal ustası kullanarak HTML'yi yeniden oluşturmak anlamına gelir.

Web kancalarını kabul etmek için bir JavaScript çözümü de kullandım. Benim seçimim barındırma sağlayıcısı (Uberspace), Node.js'yi yüklemeyi ve sunucu tarafında JavaScript'i kullanmayı mümkün kılıyor.

 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);

Bu komut dosyaları, 8000 numaralı bağlantı noktasında basit bir HTTP sunucusu başlatır. Bunun Contentful'dan gelen web kancası olduğundan emin olmak için uygun bir başlık için gelen istekleri kontrol eder. İstek web kancası olarak onaylanırsa, tüm HTML sayfalarını yeniden oluşturmak için önceden tanımlanmış npm start komutu yürütülür. Yerinde neden bir zaman aşımı olduğunu merak edebilirsiniz. Bu, depolanan veriler bir CDN'den sunulduğundan buluttaki veriler geçersiz kılınana kadar eylemleri bir an için duraklatmak için gereklidir.

Ortamınıza bağlı olarak bu HTTP sunucusuna internet üzerinden erişilemeyebilir. Siteme bir apache sunucusu kullanılarak sunuluyor, bu yüzden çalışan düğüm sunucusunu internete erişilebilir kılmak için dahili bir yeniden yazma kuralı eklemem gerekiyordu.

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

API-İlk ve Yapılandırılmış Veri: Sonsuza Kadar En İyi Arkadaşlar

Bu noktada tüm verilerimi bulutta yönetebiliyordum ve web sitem değişikliklerden sonra buna göre tepki veriyordu.

Her Yerde Tekrarlama

Yolda olmak hayatımın önemli bir parçası, bu nedenle belirli bir mekanın konumu veya hangi otel için rezervasyon yaptığım gibi bilgilerin parmaklarımın ucunda olması gerekiyordu - genellikle bir Google elektronik tablosunda saklanıyor. Şimdi, bilgiler bir elektronik tabloya, birkaç e-postaya, takvimime ve web siteme yayıldı.

İtiraf etmeliyim ki günlük akışımda çok fazla veri tekrarı oluşturdum.

Yapılandırılmış Veri Anı

Hangi olayların geldiğini hızlıca görmek, aynı zamanda oteller ve mekanlar hakkında ek bilgi almak için (tercihen telefonumda) tek bir gerçek kaynağı hayal ettim. Web sitemde listelenen olaylar bu noktada tüm bilgilere sahip değildi, ancak Contentful'da bir içerik türüne yeni alanlar eklemek gerçekten çok kolay. Bu yüzden gerekli alanları “Etkinlik” içerik türüne ekledim.

Bu bilgiyi web sitem CMS'ye koymak hiçbir zaman amacım değildi, çünkü çevrimiçi olarak gösterilmemesi gerekiyordu, ancak bir API aracılığıyla erişilebilir olması, bu verilerle artık tamamen farklı şeyler yapabileceğimi anlamamı sağladı.

JavaScript ile Yerel Bir Uygulama Oluşturma

Mobil cihazlar için uygulamalar oluşturmak yıllardır bir konu haline geldi ve buna birkaç yaklaşım var. Aşamalı Web Uygulamaları (PWA) bu günlerde özellikle sıcak bir konudur. Service Workers ve Web App Manifest'i kullanarak, web teknolojilerini kullanarak bir ana ekran simgesinden yönetilen çevrimdışı davranışa giden eksiksiz uygulama benzeri deneyimler oluşturmak mümkündür.

Bahsedilmesi gereken bir dezavantaj var. Aşamalı Web Uygulamaları yükselişte, ancak henüz tam olarak orada değiller. Örneğin Servis Çalışanları bugün Safari'de desteklenmiyor ve şu ana kadar yalnızca Apple tarafından “göz önünde bulunduruluyor”. İPhone'larda da çevrimdışı özellikli bir uygulamaya sahip olmak istediğim için bu benim için bir anlaşma oldu.

Bu yüzden alternatifler aradım. Bir arkadaşım NativeScript'e gerçekten meraklıydı ve bana bu oldukça yeni teknolojiden bahsetmeye devam etti. NativeScript, JavaScript ile gerçekten yerel mobil uygulamalar oluşturmak için açık kaynaklı bir çerçevedir, bu yüzden denemeye karar verdim.

NativeScript'i Tanımak

NativeScript kurulumu biraz zaman alır çünkü yerel mobil ortamlar için geliştirmek üzere birçok şey yüklemeniz gerekir. NativeScript komut satırı aracını npm install nativescript -g kullanarak ilk kez kurduğunuzda, kurulum sürecinde size yol gösterilecektir.

Ardından, yeni projeler oluşturmak için iskele komutlarını kullanabilirsiniz: tns create MyNewApp

Ancak, yaptığım şey bu değil. Belgeleri tarıyordum ve NativeScript'te yerleşik örnek bir yiyecek yönetimi uygulamasına rastladım. Bu yüzden bu uygulamayı aldım, kodun içine girdim ve adım adım değiştirerek ihtiyaçlarıma uygun hale getirdim.

Sürecin derinliklerine dalmak istemiyorum, ancak istediğim tüm bilgileri içeren iyi bir liste oluşturmak uzun sürmedi.

NativeScript, Angular 2 ile birlikte gerçekten iyi oynuyor, bu sefer NativeScript'i keşfetmek yeterince büyük hissettirdiği için denemek istemedim. NativeScript'te “Görünümler” yazmanız gerekir. Her görünüm, temel düzeni ve isteğe bağlı JavaScript ve CSS'yi tanımlayan bir XML dosyasından oluşur. Tüm bunlar, görünüm başına bir klasörde tanımlanır.

Basit bir liste oluşturma, aşağıdaki gibi bir XML şablonuyla gerçekleştirilebilir:

 <!-- 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>

Burada gerçekleşen ilk şey, bir sayfa öğesi tanımlamaktır. Bu sayfanın içinde, ona klasik Android görünümü ve uygun bir başlık vermek için bir ActionBar tanımladım. Yerel ortamlar için bir şeyler inşa etmek bazen biraz zor olabilir. Örneğin, çalışan kaydırma davranışı elde etmek için bir 'ScrollView' kullanmanız gerekir. Son şey, o zaman, basitçe bir ListView kullanarak olaylarımı yinelemektir. Genel olarak, oldukça basit hissettim!

Ancak görünümde kullanılan bu girişler nereden geliyor? Bunun için kullanılabilecek paylaşılan bir bağlam nesnesi olduğu ortaya çıktı. Görünüm için XML'i okurken, sayfanın loaded bir öznitelik kümesine sahip olduğunu fark etmiş olabilirsiniz. Bu niteliği ayarlayarak, sayfa yüklendiğinde görünüme belirli bir JavaScript işlevini çağırmasını söylerim.

Bu JavaScript işlevi, bağlı JS dosyasında tanımlanır. exports.something kullanılarak basitçe dışa aktarılarak erişilebilir hale getirilebilir. Veri bağlamayı eklemek için tek yapmamız gereken, bindingContext sayfa özelliğine yeni bir Gözlenebilir ayarlamaktır. NativeScript'teki gözlemlenebilirler, "iews" içindeki veri değişikliklerine tepki vermek için gerekli olan propertyChange olaylarını yayar, ancak kutudan çıktığı için bu konuda endişelenmenize gerek yoktur.

 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)); }

Son şey, verileri almak ve bağlama göre ayarlamaktır. Bu, NativeScript fetch modülü kullanılarak yapılabilir. Burada sonucu görebilirsiniz.

Gördüğünüz gibi – NativeScript kullanarak basit bir liste oluşturmak gerçekten zor değil. Daha sonra, etkinlik web sitelerine bakmak için Google Haritalar ve web görünümlerinde belirli adresleri açmak için ek işlevlerin yanı sıra uygulamayı başka bir görünümle genişlettim.

Burada belirtilmesi gereken bir şey, NativeScript'in hala oldukça yeni olmasıdır, bu da npm'de bulunan eklentilerin GitHub'da genellikle çok fazla indirme veya yıldıza sahip olmadığı anlamına gelir. Bu ilk başta beni rahatsız etti, ancak yerel bir deneyim elde etmeme yardımcı olan birkaç yerel bileşen (nativescript-floatingactionbutton, nativescript-advanced-webview ve nativescript-pulltorefresh) kullandım ve hepsi mükemmel çalıştı.

İyileştirilmiş sonucu burada görebilirsiniz:

Bu uygulamaya ne kadar işlevsellik katarsam o kadar çok sevdim ve o kadar çok kullandım. En iyi yanı, çeşitli kullanım durumları için görüntülemek için yeterince esnek olurken, verileri tek bir yerde yöneterek veri tekrarından kurtulabilmemdi.

Sayfalar Dündür: Yaşasın Yapılandırılmış İçerik!

Bu uygulamayı oluşturmak bana bir kez daha verilerin sayfa biçiminde olması ilkesinin geçmişte kaldığını gösterdi. Verilerimizin nereye gideceğini bilmiyoruz - sınırsız sayıda kullanım durumu için hazır olmamız gerekiyor.

Geriye dönüp baktığımda elde ettiğim şey:

• Bulutta içerik yönetim sistemine sahip olmak
• Veritabanı bakımı ile uğraşmak zorunda kalmamak
• Eksiksiz bir JavaScript teknolojisi yığını
• Etkili bir statik web sitesine sahip olmak
• İçeriğime her zaman ve her yerde erişmek için bir Android uygulamasına sahip olmak

Ve en önemli kısım:

İçeriğimin yapılandırılmış ve erişilebilir olması günlük hayatımı iyileştirmeme yardımcı oldu.

Bu kullanım durumu size şu anda önemsiz görünebilir, ancak her gün oluşturduğunuz ürünleri düşündüğünüzde, farklı platformlarda içeriğiniz için her zaman daha fazla kullanım durumu vardır. Bugün, mobil cihazların nihayet eski tarz masaüstü ortamlarını geride bıraktığını kabul ediyoruz, ancak arabalar, saatler ve hatta buzdolapları gibi platformlar şimdiden ilgi odağı olmayı bekliyor. Gelecek kullanım durumlarını düşünemiyorum bile.

Öyleyse hazır olmaya çalışalım ve yapılandırılmış içeriği ortaya koyalım çünkü sonuçta bu veritabanı şemalarıyla ilgili değil - gelecek için inşa etmekle ilgili.

SmashingMag'de Daha Fazla Okuma :

• Node.js ile Web Kazıma
• Sails.js ile Yelken: Node.js için MVC tarzı bir Çerçeve
• Tasarımlarınızı Güzelleştirecek 40 Seyahat Simgesi
• Web Paketine Ayrıntılı Bir Giriş