Bir Vue.js Güzellemesi

Bana “Kendini profesyonel anlamda nasıl tanımlıyorsun?” diye sorsalardı, .NET teknolojilerinde uzmanlaşmış back-end developer olarak cevap verirdim heralde. Yazılarımı takip edenler de bilir, genelde bugüne kadar .NET teknolojileri üzerine yazılar yazdım. Aynı şekilde Codefiction podcast’lerini takip edenler benim fullstack developer (!) kavramına mesafeli durduğumu biliyorlardır.

Peki yazının başlığını neden “Bir Vue.js Güzellemesi” olarak yazdım? Öncelikle bu konunun detaylarına geçmeden önce bir kaç noktayı açıklığa kavuşturmak istiyorum. Yazılım dillerinin, yazılım geliştirme metodolojilerinin veya paradigmalarının, bir soruna çözüm üretmek için kullandığımız araçlar olduğuna inanıyorum. Dolayısıyla hiç bir zaman bir dilin, platformun, framework’ün ölümüne savunucusu olmadım. Yazılım geliştiriciler olarak bu kavramların üzerinde, bunlardan bağımsız bir şekilde yazılım geliştirmemiz gerektiğine inanıyorum. Bazıları fullstack developer (!) kavramının tanımı bu zaten diyebilir, ben ise elimizde developer diye bir kavram varken ayrıca başka bir kavrama ihtiyacımız olmadığını düşünenlerdenim. Bunların yanı sıra, uzmanlık kavramına da inanıyorum. Yazılım geliştirme takım işi, güçlü ve etkin bir takım olmanın yolu da farklı uzmanlıkları olan insanların uyumlu bir şekilde çalışmasından geçiyor. Yani uzmanlık belirten back-end, front-end, mobil developer gibi kavramlara karşı değilim.

Çalıştığım şirket Armut.com’dan örnek vermek gerekirse, ekipteki bütün back-end developer’lar Angular projelerimizde de geliştirme yapabiliyorlar, aynı şekilde front-end developer’lar da back-end kodlarını debug edip belli değişiklikleri yapabiliyor, mobil developer’lar herkesin yazdığı kodları review edebiliyorlar.

Peki bütün bu yazdıklarımın Vue.js ile alakası nedir?

Her ne kadar yukarıda yazdığım herşeyin arkasında olsam da, on dört yıllık yazılım geliştiricilik kariyerimde konforlu alanımdan pek fazla çıkmadım. Yani ağırlıklı olarak .NET teknolojileri kullanarak geliştirmeler yaptım. Javascript seven bir insanım ve dil olarak belli bir seviyede uzmanlığım olduğunu söyleyebilirim.

Bu yazıyı yazmamın sebebi, son dört ayda Vue.js kullanarak üç tane proje geliştirmiş olmam. Bu projelerde vue, javascript, typescript, webpack, Vue CLI, server-side rendering, node.js gibi daha önce yanından geçmediğim teknolojileri kullandım ve konforlu alanımdan çıkmak gibi bir imkana sahip oldum. Bir back-end developer olarak edindiğim tecrübeleri ve Vue.js ile ilgili izlenimlerimi paylaşmak istedim.

Öncelikle belirtmek istiyorum, konu front-end teknolojilerine geldiği zaman çok yetkin bir insan değilim ve büyük ihtimalle benim yazının geri kalanında “oooovvvv müthiş” şeklinde anlattığım teknolojileri front-end developer’lar yıllardır etkin bir şekilde kullanıyorlar. Dolayısıyla belli yerlerde haddimi aşarsam şimdiden özür diliyorum. Bu yazı tamemen bir back-end developer’ın gözünden yazılmıştır.

Başlayalım…

Vue.js yeni JQuery’dir!!!

Bu şekilde provakatif bir başlık atmamın sebebi, ne JQuery’i övmek ne de Vue.js’i yermek. Günümüzde artık JQuery kullanmak afaroz edilme sebebi ve oldukça haklı nedenleri de var.

Yine de sizlere biraz bir back-end developer’ın gözüden 2006 sonrası ve 2010'lu yılların başlarının nasıl olduğu anlatmak istiyorum.

Javascript ve front-end teknolojileri oldukça hızlı bir yükselişe geçmişti, hayatımıza Ajax, Json, CSS 3 ve HTML 5 gibi kavramlar girmeye başlamıştı. O zamanlar bir yazılım evinde çalışıyordum ve Ajax’ın patlama yaptığı dönemlerde müşterilerden “ Hani böyle bazı web sayfaları bir hüşu içinde yavaaaş yavaş bulanıktan netleşerek açılır ya hani. ondan.” şeklinde spec’ler gelmeye başlamıştı.

Ben o zamanlar kariyerinin başında, gayet kibirli, kendini rock star sanan, .NET ruleezz şeklinde dolaşan bir developer’dım (baya hıyarın tekiydim yani). Ve javascript’e bakış açım “bu ne kötü bir dil ya” şeklindeydi.

JQuery’nin çıkmasıyla beraber bir anda ben ve benim gibi bir sürü back-end developer için javascript=jquery oluverdi. Daha önce getElementById yapamayan ben, bir anda CSS selector’lar (ki o zamanlar css selector olduğunu bilmiyordum) kullanarak harikalar yaratmaya, daha önce yapamadığımız şeyler yapmaya başlamıştık. Ayrıca Ajax kullanımı bir anda inanılmaz bir şekilde kolaylaşmıştı. Bütün bu gelişmeler benim o zamanlar YUI (Yahoo! User Interface) takımının başında olan Douglas Crockford ( kendisi json’ı standart haline getiren insandır ) ile tanışmamı ve benim javascript’i derinlemesine öğrenme sürecini başlattı. (Bu yazıyı okuyan herkese Crockford on Javascript serisini izlmesini tavsiye ederim. Hem yazılım dilleri tarihini hem de javascript’i çok iyi anlatıyor.)

Kim ne derse desin JQuery front-end dünyasında bir devrimdi, benim gibi javascript özürlü insanların bile client-side teknolojileri kullanarak geliştirme yapmasına ön ayak oldu. Öğrenmesi çok kolaydı ve önemlisi DOM gibi belki de dünyanın yazılmış en kötü platformunda kolay bir şekilde geliştirme yapabilmemizi sağladı. (IE 6 nın problem olduğu yıllardan bahsediyorum)

Peki neden Vue.js yeni JQuery’dir dedim?

Front-end dünyasında bir devrim mi? Hayır. Özellikle hergün yeni bir UI framework’ünün çıktığı bugünlerde hiç değil. Ama bence basitliği, öğrenme kolaylığı, hızlı geliştirmeye imkan sağlaması açısından diğer UI framework’lerinden ayrılıyor. Vue kullanarak, webpack’lerin npm’lerin havada uçuştuğu kompleks web uygulamaları geliştirebileceğiniz gibi tek bir html sayfasından oluşan basit bir web uygulması da geliştirebilirsiniz.

Vue.js, Angular, React ve diğerleri

Yine provakatif bir başlık gibi gelebilir ama amacım şu library şundan üstündür gibi bir şeyler yazmak değil. Aslına bakarsanız Angular ile ortalama, React ile ise çok az tecrübem oldu, o yüzden teknik bir karşılaştırma yapabilecek yetkinlikte değilim.

Vue hem Angular’dan hem de React’dan birşeyler almış bir library. Syntax olarak Angular’a benziyor ayrıca Angular gibi two-way binding de destekliyor. Jsx mantığı açısından bakarsak React ile benzerlikleri var. Ekstradan render function’ları da destekliyor. Daha detaylı karşılaştırmayı kendi sayfalarından da okuyabilirsiniz.

Aslında bu üç platformu birbirleriyle karşılaştırmak bir noktada elma ile armutu karşılaştırmak gibi. Özellikle Angular bir library’den ziyade enterprise bir framework. Çalıştığım firmada Angular kullandığımızdan dolayı Angular’a aşinayım. Büyük ürünler geliştirmek için oldukça iyi bir tercih olduğunu düşünüyorum, özellikle ekosistemi son yıllarda oldukça olgunlaştı. Ama benim şahsi görüşüm Angular ufak projeler için biraz abartı kalabiliyor. Bootstrap etmesi ve öğrenme kolaylığı açısından Vue ile kıyaslanınca geride kalıyor.

React ise yine Angular gibi zengin bir ekosistemi olan bir library. Ama bir noktadan sonra tek başına kullanmak zor, package.json bir anda adam boyu uzunluğa ulaşabiliyor, aynı şeyleri çözen bir sürü library var. Bu açıdan bakınca öğrenme zorluğu daha yüksek çünkü sadece React öğrenmekle kurtulamayabiliyorsunuz.

Ben konuyu daha çok öğrenme kolaylığı ve hızlı geliştirme açısından değerlendirdim. Elbette ki bir teknoloji seçerken tek kriteriniz bu olmamalı.

Bir noktaya daha değinmek isterim ki Vue ile ilgili insanları en rahatsız eden konulardan biri de bu.

Angular -> Google
React -> Facebook
Vue -> Evan You

Vue çok büyük oranda tek bir kişi tarafından geliştiriyor. Bunun da belli riskleri var. Konu hakkındaki görüşlerimi yazının devamında daha detaylı açıklayacağım.

Şimdi biraz da benim Vue ile olan tecrübelerimden bahsetmek istiyorum.

Kim korkar Webpack’den

Geliştirdiğim üç projenin ikisinde Vue CLI birinde webpack kullandım. Webpack kullandığım projeye kadar hayatımda bir webpack konfigurasyon dosyasına üç saniyeden fazla bakabilmişliğim yoktu. Yani o güne kadar bir kod parçasına bakıp da bu kadar hiç birşey anlamadığım olmamıştı. O yüzden webpack’e karşı büyük bir korku ve ön yargı besliyordum.

Vue ile geliştirme yapmaya başlamam biraz bilinçsiz tüketici usulü oldu, yani ne yaptığımdan çok emin değildim, o yüzden sağdan soldan okuduğum makalelerle ve bir çok yerden çarptığım webpack kod parçacıklarıyla projeye giriştim. Belirtmek isterim ki benim gibi gariban bir back-end developer bile webpack öğrendiyse herkes öğrenebilir. O yüzden bence ön yargılarınızı biraz geri plana atarak bakmakta fayda var. Projede typescript, scss gibi çok aşina olmadığım diller kulandım. Yani aslında benim için herşey yeniydi ve büyük bir hevesle, deneye yanıla, bazen neyi neden yaptığımı pek anlamadan webpack konfigurasyonumu oluşturmaya başladım. Bu süreçte babel’ler, loader’lar, css extractor’lar, hot module replacement gibi benim için adeta mitolojik yaratıklar olan bir sürü teknolojiyi öğrendim.

Yaklaşık bir haftam beş sayfadan oluşan projenin webpack kısmını oturtmakla geçti. Ama sonunda elimde typescript’den javascript’e derlenebilen, minify olan, optimize edilmiş, css’leri ayrılmış hem canlı hem test ortamlarına deploy edilen bir proje olmuştu. Tabi ki bunlar benim için büyük, front-end dünyası için küçük adımlardı.

React’ı bu konuda o kadar eleştirmeme rağmen package.json dosyamda toplamda altı paket, dev dependencies kısmında ise sayısız paket vardı.

Demek istediğim webpack’den korkmayın arkadaşlar, hala anlamadığım bir çok kısmı var ama artık bir webpack dosyasına baktığım zaman ne yapmak istenildiğini anlayabiliyorum ve değişiklikler yapabiliyorum.

Sonra Vue CLI ile tanıştım…

Vue CLI, aslında Webpack kullanmaya çok gerek yokmuş

Sektörde on dört yılını doldurmuş bir insan olarak mesleğimle ilgili makale okumayı, video izlemeyi çok sevsem de dökümantasyon okuma konusunda aynı motivasyonu hiç bir zaman bulamadım.

Siz siz olun önce resmi dökümantasyonu okuyun. Projeyi bitirdikten çok kısa bir süre sonra Vue CLI’ın varlığından haberdar oldum. Öncelikle şunu belirteyim adamlar (daha doğrusu adam) yapmış. Vue CLI çok güçlü bir araç ve Vue projelerinizi standartize etmenize oldukça yardımcı oluyor. Vue CLI arka tarafta webpack kullanıyor ve en uygun konfigurasyon zaten yapılmış durumda, dolayısıyla sizin tek yapmanız gereken build, serve gibi komutları kullanmak. Benim bir haftamı gömüp yapmaya çalıştığım her şeyi tek bir komutla çok daha iyi bir şekilde yapabiliyormuş. Ayrıca özelleştirme ihtiyacınız varsa vue.config.js dosyasında değişiklikler yaparak kendi istediğiniz webpack plugin’lerini kullanabilirsiniz veya mevcut plugin’lerin ayarlarını değiştirebilirsiniz.

Sırf bunlar da değil. Yeni bir projeye başlıyorsanız, create komutunu kullanıp projenizi direkt bootstrap edebiliyorsunuz, boilerplate aramaya son. Create komutu size bir çok seçenek sunuyor. Örneğin typescript mi javascript mi kullanmak istiyorsunuz, linter’ınız ne olsun, unit test library’leri, scss mi stylus mu yoksa düz css mi veya hangi e2e test framework’ü gibi size birçok soru soruyor. Bu soruları cevapladıktan sonra paketler yükleniyor ve elinizde konfigurasyonu yapılmış, geliştirme yapmaya hazır bir projeniz oluyor.

Yine de Vue CLI’dan sonradan haberdar olduğum için pişman değilim. Bu sayede benim için öcü ile eşdeğer olan webpack öğrenmiş oldum.

Typescript mi? Javascript mi?

Vue her iki dili de destekliyor. Hatta component’lerinizin bir kısmı typescript bir kısmı da javascript olabilir. Her iki dili kullanarak da Vue projesi geliştirdim. Typescript desteği oldukça tatmin edici, isterseniz component’lerinizi yazarken class kullanıp component ve property annotation’larını kullanabilirsiniz. Veya hiç class’a bulaşmayıp export default içerisinde klasik javascript nesne formatında component yazabilirsiniz. Bu konuda sizi oldukça özgür bırakıyor.

İlk geliştirdiğim projeyi typescript kullanarak geliştirdim. Typescript’in proje büyüdükçe ve karmaşıklaştıkça bakım yapılabilirlik açısından sağladığı avantajlar tartışılmaz. Açıkçası ben Vue ve typescript kullanırken çok büyük problemler yaşamadım. Ama her ne kadar Vue typescript’i destekliyor olsa da iki sorun var.

Birincisi dökümantasyonları ve örnekleri daha çok javascript üzerine yoğunlaşmış durumda. Bazı şeylerin typescript ve class yapısında karşılıklarını bulmak için araştırma yapmanız gerekebiliyor. Ayrıca çoğu vue paketinin d.ts dosyaları yok, dolayısıyla typescript içerisinden kullanırken ya wrap etmeniz gerekiyor ya da boş declare module içeren d.ts dosyaları oluşturmanız gerekiyor. Açıkçası ben ikisini de çok büyük sorun olarak görmüyorum.

Diğer geliştirdiğim iki projede ise hiç typescript’e bulaşmadan javascript kullandım. Galiba javascript Vue.js’e biraz daha uyuyor, daha pürüzsüz bir geliştirme deneyim yaşadım ve açıkçası typescript’in eksikliğini de çok fazla hissetmedim. Zaten javascript seven birisiyim ve javascript’in güçlü yönlerinden birinin de dynamic yapısı olduğunu düşünüyorum. Hem jsdoc varken ne gerek var typescript’e (!).

Dediğim gibi dil konusunda Vue size büyük bir esneklik veriyor, birinden birini seçmek zorunda değilsiniz, ikisini de aynı anda kullanabilirsiniz.

Bootstrap ve Vue

Konuyla direkt alakası yok ama bu süreçte derinlemesine Bootstrap öğrenme şansım da oldu. Bugüne kadar bir label ile textbox’ı aynı hizaya getirememiş bir insan olarak css’e olan tavrımı az çok tahmin edebilirsiniz.

Vue maceram ile beraber front-end’de harikalar yaratmaya başladım, yani en azından bir footer’ı header’ı olan, araya form koyabildiğim, yeri geldimi side-bar da ekleyebildiğim sayfalar yapabilmeye başladım. Yani artık :before mu istersin :after mı istersin, font awesome’lar scss’ler felan ohooo yani…

Öğrendiğim her yeni şeyle birlikte koştura koştura Armut.com’da beraber çalıştığımız ve Codefiction’da da podcast‘lere katıldığımız sevgili Fatma’nın yanına gidip “böyle birşey varmış, biliyor muydun?” dediğim çok oldu. Her seferinde yüzünde önce bir şaşkınlık, sonra “ayy canıııım” bakışı ve ardından “biliyorum hatta şöyle birşey de var” diye cevap aldım. Dolayısıyla yine belirtmek gerekirse bu sadece benim için büyük bir adımdı.

Neyse çok uzatmayayım, Bootstrap öğrenmeme de vesile oldu. Ayrıca hayırsever geliştirici arkadaşlarımızdan bir tanesi Vue ile bootstrap kullanımı kolaylaştıran, içerisinde hazır bootstrap yapılarını içeren bir library geliştirmiş. Adını da çok yaratıcı bir şekilde Bootstrap Vue koymuş. Geliştirdiğim projelerden birtanesinde kullanma fırsatım oldu, tavsiye ederim.

Vue, SSR (Server Side Rendering) ve Webpack’e dönüş.

Vue gibi SPA (Single Page Application) platformlarının sorunlarından biri de ortaya çıkan uygulamanın geleneksel web uygulamaları kadar SEO dostu olamaması. Yani arama motorları bu tür uygulamaları indekslerken zorlanabiliyor. Her ne kadar Google ve Bing arama motorları uzun süredir javascript çalıştırıyor olsalar da yüksek indekslenme ihtiyacı olan web uygulamalarında SSR kullanmak gerekebiliyor. SSR indekslenme problemeni çözebileceğiniz tek alternatif değil elbette, static sayfa generate etme gibi başka seçenekler de var.

Daha önce Angular Universal ile tecrübesi olmuş biri olarak SSR kavramına yabancı değildim. Vue ile geliştirdiğim projelerden birtanesinde böyle bir ihtiyaç hasıl oldu (ihtiyacı biraz ben de yaratmış olabilirim). Hemen kolları sıvadım ve geçmiş projelerde edindiğim Vue tecrübeme güvenerek projeyi geliştirmeye başladım.

Öncelikle belirtmek isterim ki delirmenin eşiğine geldiğim çok fazla an oldu. Tamamen farklı bir tecrübe diyemem ama yazdığınız kodda bir takım değişiklikler yapmanız gerekiyor. Maalesef geliştirdiğim projede hazır bir template kullanmıştım ve template’i yapan arkadaşlarımız bir sürü JQuery plug-in’i kullanmışlar.

Şimdi bunun ne sakıncısı var diye düşünebilirsiniz. Biraz aslında SSR dediğimiz olayın nasıl çalıştığından bahsedelim. SPA’lerde SSR fikri “Zaten Node.js de Google V8 engine kullanıyor, o zaman client-side’da geliştirdiğimiz kodları Node.js’de de çalıştırıp, server’da da render edebiliriz.” yaklaşımından çıkıyor. Fakar server tarafında DOM diye birşey olmadığından dolayı window, document kullandığınız yerler patlıyor. Çünkü bu arkadaşlar sadece browser’da varlar. Dolayısıyla belli yerlerde client’da mıyım server’da mıyım kontrollerini yapmanız, bazı kodlarınızın SSR esnasında çalışmamasını sağlamanız lazım.

Bütün bunları çözseniz bile (ki çok zor değil), webpack’de kullandığınız bazı paketler de document’a ulaşmaya çalışabiliyorlar. Örneğin daha önceki projemde sorunsuz kullandığım mini-css-extract-plugin meğerse css’leri dinamik yüklerken bunu document nesnesini kullanarak yapıyormuş. Dolayısıyla konfigurasyonunda değişiklikler yapmam gerekti. Ama sorunun kaynağını çözene kadar baya vakit harcadım. O yüzden kendi kodunuzda document ve window kullanımlarına önlem alsanız bile, kullandığınız diğer paketleri de gözden geçermenizde fayda var.

Webpack demişken, Vue ve SSR konusunda dökümantasyon çok fazla yok daha doğrusu çok fazla örnek yok. Resmi dökümantasyonunda ise verilen örnek Vue CLI yerine webpack 3 kullanılarak yapılmış. Zaten o anda anladım ki benim webpack diye öğrendiğim şey webpack 4 müş, webpack 3 de varmış, benim önceden bakıp kör olduğum ve hiç anlayamadığım versiyonu da webpack 3 müş. Neyse iki hafta süren hayata küsme durumlarından sonra webpack 3 de öğrenmiş bulundum, aslında paketler haricinde müthiş farklar yok ama daha zor ve daha karmaşık diyebilirim. Yaşadığım tecrübe, hep otomatik vites araba kullanıp sonrasında düz vites arabayı ilk kez kullanmaya çalışan bir insanın ilk başlardaki sendelemesi gibiydi.

SSR tecrübem oldukça acı doluydu diyebilirim. Sıfırdan Vue öğrendim gibi birşey demiyorum ama SSR farklı bir dünya arkadaşlar, girmeden önce alternatiflerini de değerlendirmenizi tavsiye ederim.

Yine projeyi bitirdikten sonra beni birşeyler dürttü ve bu iş bu kadar zor olmamalı diyerek araştırmalarımı biraz daha derinleştirdim ve iki yeni şey öğrendim.

Öncelikle yine webpack kullanmak gibi bir zorunluluğumuz yokmuş, biraz araştırma ve edindiğim tecrübelerden sonra webpack 3'lü projemi Vue CLI’a geçirmeyi başardım.

Ama yıkıldığım an Nuxt.js isimli projeyi öğrenmemle oldu, daha doğrusu hep rastlıyordum da çok ciddiye alıp araştırmamıştım. Nuxt.js yine bir grup hayırsever developer’ın geliştirdiği, oldukça kapsamlı ve öncelikli olarak Vue ve SSR problemlerini çözen bir framework. Benim projemde el yordamıyla çözmeye çalıştığım bir çok sorunu çözmüşler ve Vue SSR deneyimini adeta Vue CLI gibi kolaylaştırmışlar. Vue ve SSR kullanmak isteyen arkadaşlara tavsiyem, “Artistliğin lüzumu yok, Nuxt.js kullanın” yönünde olacaktır.

VSCode, Vetur, Eslint, Tslint ve Prettier

Anladığım kadarıyla front-end dünyasındaki en büyük kafa karışıklığı “Bugün hangi yeni çıkmış UI framework’ünü kullansam” değil de, daha çok “Hangi lint standartını kullansam? Eslint mi kullansam? prettier mı kullansam? ikisini bir arada mı kullansam? vscode ile nasıl entegre etsem?” şeklinde.

Ben bir linting ve formatting işinin bu kadar karmaşık olabileceğini hiç düşünmemiştim. Airbnb standartı var, Google standartı var, standart diye ayrı birşey var, double quote (“) kullanan var, single quote (‘) kullanan var, herşeyin sonuna virgül koyan var.

Bir de typescript’de ayrı, javascript’de ayrı, node.js’de ayrı, babel kullanıyorsan ayrı. Hangi ES versiyonunu kullandığın ise herşeyi değiştirebiliyor.

Ben bu kadar karar verilememiş bir konu daha görmedim. Uzun araştırmalardan, deneme yanılmalardan ve VSCode’u üç kez silip yeniden yüklemek zorunda kaldıktan sonra kendimce en doğru kombinasyonu buldum. Linting işini en iyi eslint yapıyor biraz formatting işini de yapabiliyor ama o işleri prettier’a bırakmak daha doğru. Airbnb’nin stanadartını sevdim onu kullanıyorum. “Autofix on save” ayarını yapmak hayat kurtarıyor ama bu yetkiyi prettier’dan alıp eslint’e vermek VSCode’un daha sağlıklı çalışmasını sağlıyor. Bu yoldan gidecekseniz eslint ile prettier’ı birbirleriyle konuşturmanız lazım, konuşturduğunuz zaman da birbirlerinin yetki alanlarını girmemelerini sağlamanız lazım. Typescript kullanmayı tercih ederseniz işin rengi biraz daha değişiyor. En sonunda kendimce doğru yolu bulup, ilgili VSCode settings.json ayarlarını oluşturdum, ihtiyaca göre onları kullanıyorum.

Vue bu konuda sözde bir takım preset’ler hazırlamış ve Vue CLI ile yarattığınız projelerde bu ayarlar hazır geliyor. Ama eninde sonunda eslint dosyasına müdehale edip VSCode ayarlarını fine tune etmeniz gereken noktaya geliyorsunuz.

Bir de Vetur diye muhteşem VSCode eklentisinden de bahsetmek istiyorum. Aslında Vue geliştirirken .vue uzantılı dosyalar kullanarak geliştirme yapmak istiyorsanız zaten başka seçeneğiniz de yok. Vetur VSCode’a Vue için syntax highlighting, auto completion ve scaffolding desteği getiriyor. Ben oldukça başarılı buldum tavsiye ediyorum.

Axios, Vuex ve Vue Router

Vue projelerinde standart haline gelmiş birkaç library var, onlardan kendimce en önemlilerinden bahsetmek istiyorum.

Axios promise tabanlı bir HTTP istemcisi ve Vue haricinde genel olarak hem client-side’da hem de Node.js tarafında giderek popülerleşiyor. Request ve response’ları intercept etme, transform etme gibi işleri kolayca yapmanıza imkan veriyor. Açıkcası bir HTTP istemcisi ne kadar övülebilir emin değilim ama Axios oldukça hafif ve kullanımı çok kolay.

Front-end dünyasında tüylerimi diken diken eden konulardan bir tanesi de state management. Ne state’miş arkadaş, bu kadar devlet meselesi, uygulamanın bekası haline getirilmesine anlam veremiyorum. Neyse React’ın Redux’ı, Angular’ın NgRx’i gibi, Vue’nun da Vuex’i var. Daha önce state management ile uğraştıysanız yine çok benzer ve tanıdık gelen yöntemlerle Vuex kullanarak state’inizi yönetebilirsiniz.

SPA’ler ile beraber hayatımıza giren kavramlardan biri de client-side routing. Vue’nun resmi router paketi kendisinden beklenenleri karşılıyor. Açıkcası benim çok hoşuma gitti diyebilirim, oldukça sade ve bir kaç lifecycle event’inde araya girerek istediğinizi yapabiliyorsunuz. Özellikle view’ler arası geçişlerde transition desteğinin basitçe sağlanması çok hoşuma gitti. Genel olarak her Vue projesinin ayrılmaz paketi diyebilirim.

Vue ve Testing, Mocha, Chai, Gherkin ve Testcafe

Vue ve testing konusunda Vue’ya özel birşey yok aslında. Ama Vue CLI için popüler test framework’lerine plug’inler yazılmış. Testleri çalıştırma ve raporlama oldukça kolay. Yine projenizi Vue CLI kullanarak yarattıysanız size bir kaç seçenek sunuyor. Ben tamamen bilinçsiz bir şekilde ilk seçenek olduğundan dolayı mocha + chai ikilisini seçtim, diğer alternatif jest’di.

Back-end tarafında yoğun olarak unit test yazan birisiyim, test mantığı assert’ler mock gibi kavramlar biraz daha değişik olsa da, daha önce unit test yazdıysanız zorlanacağınızı sanmam. Oldukça olaysız bir unit test deneyimim oldu.

E2E testlerinde ise Vue CLI size Cypress ve Nightwatch olmak üzere iki seçenek sunuyor. Ben ikisini de kullanmadım.

Sevgili dostum Mert’in tavsiyesiyle Cucumber Gherkin ve Testcafe kullanmaya karar verdim. Bu arada Gherkin formatında test yazmak istiyorsanız hemen hemen bütün e2e framework’lerinin böyle bir desteği var. Behaviour-Driven Development (BDD) konusu ise bu makalenin kapsamı dışında apayrı bir konu. Ama mutlaka araştırmanızı ve kendi şirketlerinizde yazılım geliştirme süreçlerine katmanızı öneririm.

Gherkin öğrenmem çok üzün sürmedi ama Testcafe ile entegre etmem biraz vakit aldı, daha önce yapmadığım bir şeyi yaptığım için biraz uğraştım ama sonunda bir Docker container içerisinde Headless Chrome ve Firefox kullanarak testlerimi çalıştırmayı başardım.

Diğer bütün seçimlerim gibi Testcafe seçimim de çok bilinçli bir tercih değildi. Mert önerdiyse bir bildiği vardır diye düşünerek seçmiştim. Gerçekten de Mert’in bir bildiği varmış.

Testcafe’nin en büyük avantajı çoklu browser desteği. Bunu başarmasının temel sebebi de e2e testlerinizin browser yerine node.js’de çalışması ve arada haberleşmenin Testcafe tarafından yönetilmesi. Dolayısıyla Testcafe’nin herhangi bir driver bağımlılığı yok. Ayrıca css selector’lar kullanarak DOM elementlerine kolay bir şekilde ulaşabiliyorsunuz. Bunun yanı sıra BrowserStack gibi popüler testing platformlarıyla da entegrasyonu var. Yani aklınızda sadece e2e değil, cross-browser testing de varsa Testcafe bu konuda çok başarılı.

Öte yandan Cypress’i hiç kullanmadığımı da belirtmek isterim. Ama okuduğum makalelerden anladığım kadarıyla oldukça olgun bir framework ve güzel özellikleri var. Tercih etmememin sebebi dediğim gibi Testcafe’nin browser desteğinin daha güçlü olmasıydı.

Bonus: Node.js, Lerna, Husky, GraphQL ve Apollo

Yine bu yolda öğrendiğim bir kaç yararlı library ve framework’den bahsetmek istiyorum.

Geliştirdiğim Vue projelerinden birinde UI’ın yanı sıra API da geliştirmem gerekiyordu. “Artık madem boğazımıza kadar javascript’e battık bari API’ı da Node.js ile yazayım” dedim.

Doğru bir karar vermişim. Bir .NET developer olarak, javascript’i çok sevsem de yıllarca Node.js’den uzak durdum. Hatta ortamlarda “Hiç compile olan bir dille, interpret olan dir bir olur mu? Hıahahahah” diye lüzumsuz espiriler yapmışlığım da var.

Sonuç olarak Node.js ile bir projeye başlamak yaklaşık bir dakika alırken, .NET’de bu süre ne kadar seramoni sevdiğinize bağlı olarak bir saat alabiliyor. Demem o ki iki tane endpoint’i olan bir API yapacaksanız, npm init, npm install express diyerek daha ne olduğunu anlamadan API’ınızı bitirebiliyorsunuz. Yanlış anlamayın üç endpoint olunca .NET yapın demiyorum. Ama belli durumlarda Node.js çok daha iyi bir seçenek.

Bir workspace içerisinde birden fazla projeniz olduğu zaman ve bu projelerin build, serve, test, lint gibi ortak özellikleri olmaya başladığı zaman Lerna imdadınızı yetişiyor. Lerna asıl amacı mono-repo kullanılan projelerde, projelerin birbirlerine olan bağımlılıklarını ve versiyon yönetimi konusu çözmek olan bir library. Benim çok şükür öyle bir derdim olmadı. Ama workspace’in root’undan her proje için build, test, lint gibi komutları tek seferde çalıştırmak veya uygulamaları aynı anda başlatmak gibi işler için kullandım. Paralel bir şekilde komutların çalıştırılması gibi özellikleri var. Kullanmanızı tavsiye ederim.

Code Review, kod standartları, formatting gibi konularda bazen hastalık derecesine ulaşan bir takıntım var, property’ler arasında bir satır boşluk konmadığı içi PR’larda olay çıkartmışlığım, sevgili ekip arkadaşlarımı hayatlarından bezdirmişliğim oldu. Aslında hiç gerek yokmuş. Husky size git’in commit hook’larında bir takım script’ler çalıştırmanıza imkan sağlıyor. Mesela şirkette geliştirdiğimiz bir projede linter’ın çalışmasını commit öncesine bağlayıp repoya gönderdim. Artık kimse linter’dan geçemediyse commit dahi yapamıyor, dolayısla ben de kötü insan olmaktan kurtulmuş oldum.

API’yı geliştirdiğim aynı hafta Mert benden Codefiction’ın podcast, video, twitter gibi platformlardan gelen istatistiki bilgileri derlediğimiz ve open-source yaptığımız projemizde geliştirme yapmamı istedi. Daha doğrusu “Artık sen de bir ucundan tutsan mı?” şeklinde bir serzenişle geldi. Ben de open issue’lardan linter eklenmesi desteği ile ilgili task’ı alıp yapmaya başladım. Yine kötü adam kahkahaları eşliğinde husky’yi de ekleyerek task’ı bitirdim.

Projede React, GraphQL, Apollo gibi daha önce hiç kullanmadığım teknolojiler kullanılmıştı. React’ı “Ayda bir tane UI framework’ü öğrenmek yeterli” diyerek pas geçtim. Uzun süredir GraphQL öğrenmeyi çok istiyordum. Projede GraphQL kullanımını oldukça kolaylaştıran Apollo’da kullanılmış. Bu iki teknoloji öğrenmek istiyorsanız, size güzel bir referans proje olabilir. Ayrıca Lerna ve Husky kullanım örneklerini de içeriyor. Üzerinde bir iki gün çalıştıktan sonra Express ile geliştirdiğim API’yı GraphQL’e taşıyabildim.

Şimdi geriye dönüp yazdıklarıma bakıyordum da, bir noktadan sonra o package.json’ın Michael Jordan boyuna ulaşmaması imkansız gibi. Anladığım kadarıyla front-end geliştirmenin alametifarikası package.json dosyasının uzunluğu.

Evan You’yu dinozor yese ne olur?

Vue ile ilgi sevdiğim özellikleri ve dört aylık Vue maceramda kullandığım bütün diğer teknolojileri açıklamaya çalıştım.

Gelelim Vue ile ilgili en büyük eleştiri sebeplerinden birine.

Angular ve React’ın aksine Vue.js büyük oranda tek bir kişi tarafından geliştiriliyor, o kişi de Evan You. Her ne kadar Github’da yaklaşık iki yüz kişilik bir contributer listesi görseniz de, code insert ve delete’lere baktığınız zaman Evan You’nun açık ara önde olduğunu fark edeceksiniz.

Bu durum haklı olarak insanlarda Vue geleceği tek bir kişiye bağlı bir proje izlenimi yaratıyor. Yani bir gün Evan You bu işten sıkılır veya başına bir şey gelirse Vue’nun geleceği muallakta diye düşünülüyor.

Açıkçası ben de bu endişelere hak veriyorum ama Evan You’nun başına bir şey gelmesi durumunda Vue’nun sahipsiz kalacağını sanmıyorum. Ortalıkta dolanan söylentilerden biri de Alibaba’nın alttan alta Vue’yu destekliyor olması. Ayrıca Vue’ya ikinci en çok katkıyı sağlayan kişi de bir Alibaba çalışanı.

Bütün bunların haricinde daha önce de bahsettiğim gibi Nuxt.js, Bootstrap Vue, Vue Material, Vuetify gibi oldukça başarılı ve popüler projeler var. Her ne kadar core proje Evan You tekelinde gibi gözükse de Vue’nun geniş bir ekosistemi var ve her geçen gün büyümeye devam ediyor.

Konforlu alanınızdan çıkın!!!

Bütün bu Vue maceram bana çok şey kattı, daha önce öcü muamalesi yaptığım bir çok teknolojiyi öğrenme fırsatım oldu. Özellikle bir back-end developer olarak, front-end dünyasını daha yakından tanımama ve oralardaki bakış açılarını anlamama çok yardımcı oldu. Bunların yanı sıra aslında Node.js yeteneklerimi de baya geliştirdim. Dolayısıyla naçizane tavsiyem konforlu alanlarınızdan çıkıp, farklı yaklaşımları da öğrenmeniz yönünde.

Maalesef bu süreçte front-end virüsünü de kapmış oldum. Ne zaman yeni bir library, framework çıksa, üzerine atlama güdüsü oluştu. Haftaya “Vue öldü yaşasın Svelte!!!” diye bir yazı yazabilirim, bilmiyorum.

Bir sonraki yazımda görüşünceye dek hepinize iyilikler dilerim.