Neden Angular Framework?

Bu aslında AngularJS logosu. Ben ise Angular kullanıyorum. Farkını merak edenler, yazımı okumaya başlasın :)

Bir süredir üzerinden çalışmak istediğim Web uygulaması için kendime UI framework arıyordum. Piyasa da en çok konuşulanlar olmalarından dolayı, VueJS, Angular, ve React tabi ki ilk aklıma gelenler oldu. Açıkçası bir sürü yazılımcı gibi JS dünyasında her ay tüm sorunlarımızı çözeceğine inanılan yeni bir UI framework’un çıkmasından bende sıkıldım. Tamam, her ay demek abartılı oldu biraz… Ama çeşitliliğin de hem rekabeti arttırması hem de önce ki hatalardan alınan derslerin tekrarlanmaması için gerekli olduğuna inanıyorum. Yeni piyasaya sürülmüş kütüphaneler ile alakalı genelde en ciddi sorunum, oturmamış kullanıcı topluluğu ve internette başkaları tarafından sorulmuş ve cevaplanmış soruların azlığı. Bir şeyi yeni baştan öğreniyorsanız, bu iki olayı yabana atmayın. Diğer önemli faktörler ise kütüphaneyi develop eden yazılımcıların geçmişleri ve bu kütüphaneyi kimlerin ve hangi şirketlerin desteklediği. Aksi halde çok uzağa gidemeden ölmeye başlayıp sonrasında içlerinde asla çözülmeyecek yüzlerce hata ile sizleri başbaşa bırakıyorlar. Angular, bu soru ve endişelerimin hemen hemen hepsine olumlu yanıtlar veriyor.

Yukarıda ki teknolojilere jQuery’de (jQuery ile ilk çıktığı zamanlardan beri yıllarca çalıştım) katarsak, hangi framework ile çalışayım soruma cevap ararken aslında 4 tane framework incelemiş oluyorum. Sonuç: Seçimim Angular. Ama neden? Çok detaylara inmeden ufak ufak inceleyelim:

Angular vs. AngularJS

Başlamadan önce karıştırılmaması gereken şeyin Angular ile AngularJS’in aynı şeyler olmadığı. AngularJS, 1.x versiyonlarının ismi. Sonrasında ciddi mimari değişikler yapacak olan Angular takımı, bunu radikal bir isim değişikliği yaparak da göstermek istemiş: Angular, sadece Angular. 2.x ve üstü tüm versiyonlar hem bu farklı mimari hem de bu farklı isim ile çıkıyorlar karşımıza. Hatta web adresleri bile farklı: Birisi AngularJS.org iken diğer Angular.io. İyi olmuş mu diye sorarsanız, süper olmuş. Farklı isimlendirilecek ve farklı sitelerde olacak kadar farklılık içeriyorlar gerçekten. Hangisi diye sorarsanız, performance kriteri yenisinde çok daha geliştirilmiş olsada, bence asıl kazanç mimari değişimi. Bundan dolayı yeni projelerinizde kullanacağınız versiyon Angular olmalı.

Neden Angular?

Aşağıda anlatacağım bazı özellikler diğer kütüphanelerde de olabilir. Ama benim seçimim hepsinin bir arada olmasından dolayı Angular. Değinmek istediğim noktalar daha çok mimari açılardan olacak. Neyse bakalım, çok zaman kaybetmeden başlayalım:

1. Opinionated Approach

Kod yazmaya başlarken, öncelikle aklımdan projenin mimarisinde neyin nerede olacağını planlarım ve sonrasında bunu kağıda döker ve detaylar eklerim. Bu tür belli bir detaya sahip tasarımı, eğer üzerinden çalışacağım proje büyükse yaparım. Angular kullanacağım proje de bu şekilde büyük bir proje olacak. Bu planlayıcı yaklaşım, neyin nereye konulacağı daha hızlı görmek ve sonra bulmak istediğimde nereye bakmam gerektiğini hızlıca cevaplaması açısından önemli bir yaklaşım. Ama bunu her zaman kendiniz yapmak zorunda değilsiniz. Bazen bunun bir kısmını çalıştığınız framework’de size dikte edebilir. Opinionated bir sistem size kendisini nasıl tasarlamanız gerektiğini söyler. Eğer convention over configuration diye bir deyiş duyduysanız, bunlar aslında opinionated sistemlerlerdir. Neyin ne ve nerede olduğunu bir .json, bir .xml ya da herhangi bir dosya içinde ayar olarak tanımlamak yerine, sizden beklenen mimari geleneği takip edersiniz.

Opinionated kelimesi sistemin kendine ait belli önyargıları olduğunu söyler ve sizden bunlara uymanızı bekler. Bu yaklaşım diğer popüler web ortamlarında da sıkça görebileceğiniz bir yöntem. Mesela Asp.NET MVC de aynı şekilde bir yaklaşıma sahip. Her projede mimari tasarımın kullandığım uygulama geliştirme ortamınca söylemesini çok istemem ama projemin UI kısmında bu büyük bir kolaylık. Eğer zaman, para, ve proje büyüklüğü gibi faktörler buna uygunsa, bu şekilde önceden düşünülmüş tasarım size çok kolaylık sağlayacaktır. Kısacası, her zaman olduğu gibi ‘Duruma göre değişir…’ cevabımız yine geçerli. Bu şekilde bir yaklaşımı ile Angular, kafamı implementasyon mimarisiyle çok yormadan, domaine bakan mimariye yönlenmemi sağlamış oluyor.

2. Explicitness

Yani açık açık demek. Neyin ne olduğunu ve kim tarafından kullanıldığını Angular sizden açık bir şekilde tanımlamanızı bekliyor. Bu daha az sürpriz ile karşılaşacaksınız demek. Mesela, bir NgModule, hangi Componentleri kullandığını, hangi servisleri inject edeceğini, neleri export ettiğini, ve diğer hangi Modüllere dependent olduğunu sizden açık açık söylemenizi bekliyor. Aşağıda ki kod örneğine bakabilirsiniz:

@NgModule({
declarations: [
AppComponent,
ItemDirective
],
imports: [
BrowserModule,
FormsModule,
HttpClientModule
],
providers: [],
bootstrap: [AppComponent]
})
export class AppModule { }

Kod okurken ya da ileride kendi static code analysis araçlarınızı yazarken bu açıklık size çok faydalı olacak. Bu açıklık hemen her seviyede var. Mesela Componentler de benzer şekilde çalışıyorlar. Hatta hangi template ve CSS dosyalarını kullandıklarını da sizden açık açık söylemenizi bekliyorlar. Bu sayede neyin ne ile ilişkili olduğunu rahatlıkla görebiliyorsunuz. Örnek olarak aşağıda ki Component tanımlamasına bakabilirsiniz:

@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.scss']
})
export class HeroAppComponent {
/* . . . */
}

2. Isolation

Eğer yukarıda ki kodları incelediyseniz, o zaman bir şey dikkatinize çarpmış olmalı: Isolation. Kolayca ve hızlıca sistemi oluşturan yapıları birbirlerinden izole edebilmeniz, bence Angular’ın en güçlü taraflarından bir tanesi. CSS dosyalarından JS kodlarına kadar her şey diğer kısımlardan izole edilebiliniyor. Bu sayede, mesela “Acaba şu style başka bir yerde tanımlanan bir style tarafından override edilir mi?” şeklinde ki korkularınız azalmış oluyor. Burada bunu tüm detayları ile anlatmam mümkün değil, ama Angular kullanmaya başlayınca bunu daha rahatlıkla görebiliyorsunuz. Bu arada Angularda ki JS izolasyonu JavaScript’in kendisinden gelen bazı yöntemler ile sağlanıyor ama izolasyon sadece bununla sınırlı kalmıyor. Anguların ise JavaScriptin bu özelliğini kullanması ve hatta dikte etmesi onu değerli kılan yaklaşımı. Aksi halde tüm kodları herhangi bir scope uygulamadan birleştirip çalıştırabilirdi. O zaman Angular’ın pek bir değeri kalmazdı gözümde, orası ayrı. JS modüllerinden farklı olarakta kendi yapıları arasında ki diğer bir izolasyonu da kendisine ait olan NgModules ile sağlıyor. Devamı hemen aşağıda ki Modüler başlığı altında.

3. Modularity

Angular kullanmış olduğu NgModule yapıları ile düzgün isolation tasarımı yapmış. Herşey kontrollü. Neyi dış dünyaya export edeceğinizden, neyi import edeceğinize kadar herşey NgModule içinde gerçekleşiyor. Bir nevi .JAR yada .DLL dosyaları gibi. İstediğiniz modülleri tanımlar ve orada güvenli bir şekilde başka modülleri bozma korkunuz olmadan çalışabilirsiniz. Tabi her zaman olduğu gibi tasarımınıza bağlı olarak bu güven ortamı kaybolabilir. Örnek bir kodu aşağıda koydum. Okurken kafanız karışıyorsa, kodun ne kadar basit olduğunu başka dillerden geliyorsanız rahatlıkla görebilirsiniz. @NgModule diğer dillerde Annotation (Java)ve Attribute (C#) olarak geçiyor. Kısacası bir tipe metadata eklenmesini sağlıyor. Ama hala kafanız karışıyorsa, o zaman JS diline gelen yeni özelliklere ve TypeScript’e bakmanız gerekecek.

@NgModule({
declarations: [
AppComponent,
ItemDirective
],
imports: [
BrowserModule,
FormsModule
],
exports:[BrowserModule],
providers: [],
bootstrap: [AppComponent]
})
export class AppModule { }

NgModule yapıları aynı zamanda mimarinizi tasarlarken, alakalı işleri aynı modül içerisinde toplayabilmeniz ve kod okunabilirliği ve bulunabilirliğini arttırabilmeniz içinde çok önemli. Hatta Shared Modules oluşturmak suretiyle, ortak olan bazı özellikleri, mesela common utilities gibi, bir arada toplayıp bunları istediğiniz modüle import ederek code duplication sorununu ciddi oranda azaltabilirsiniz.

4. Extending HTML

Angular da HTML dosyalarınızı extend etmeniz mümkün. Bunu başarmak için kullandığınız yapılara Directives deniyor. Bu isim nereden geliyor diye merak ediyorsanız, HTML’in declarative bir programlama dili olmasından. Yani yapılması gerekenleri teker teker yazmak yerine sadece tanımlıyorsunuz, mesela <br/> demek gibi: Bu bir satır ekle demek. Bakın, satırın nasıl eklenmesi gerektiğini söylemediniz. Sadece ne eklenmesi gerektiğini söylediniz. Onun için declarative bir programlama dili HTML. Directiveler de bu şekilde çalışan yapılar. Onlar sayesinde HTML kodunuza yeni özellikler ekleyebilir ve sonrasında onların nasıl çalışması gerektiğini JS kodu ile ayrı bir yerde tanımlayabilirsiniz. Bu size code readability ve reusability sunacak. Halihazırda Angular zaten çok kullanışlı bazı directiveler ile birlikte geliyor. Belki çoğu zaman kendi directivelerinizi tanımlamak zorunda bile kalmayacaksınız. Ama kalırsanız, yöntemi belli.

5. Dependency Injection

Dependency Injection’ın önemini kendisini hakkıyla anladıktan sonra görebilirsiniz. Eğer bu konu hakkında yeterli bilgiye sahip değilseniz, o zaman Google’da aratıldığında birinci sırada çıkan şu yazıma bakmanızı tavsiye ederim:

Evet, havamı da attıktan sonra, Angular’ın native bir şekilde DI implement etmiş olmasının çok önemli ve doğru bir yaklaşım olduğunu söylemem lazım. Ufak bir örnek ile ne gibi faydaları olabileceğine değinelim: Bir projeyi tasarlarken, öncelikle UI kısmında başlarım. Nedeni ise yapacağım şeyin asıl önemli olan tarafı öncelikle kullanıcıya hitap etme şekli. Diğer bir neden ise, neyin üzerine çalıştığımı daha iyi görmemi sağlıyor. Kullanıcıya sunabileceğim bir şey görünce, artık arka kısımlara çalışma zamanı gelmiş oluyor. Bunların yanı sıra, çalıştığınız projede UI görmek insanı mutlu ediyor. İnsana bir şeylerin ilerlediği hissini veriyor. Dolayısıyla UI tasarlarken, boş gözüken gridlerin, formların, vs. pek bir güzelliği ve özelliği olmuyor. Bunun içinde mock verilere ihtiyaç duyuyorsunuz. Bu verileri eğer diğer HTML içinde tanımlarsanız, sonrasında gerçekleri ile değiştirmek için uğraşmanız gerekiyor. Eğer bu veriler, bir kaynaktan gelirse, gerçek veriyi kullanmak istediğinizde tek yapmanız gereken bu kaynağı değiştirmek. Bu noktada, bu verileri sağlayacak kaynağı bir servis sınıfı olarak tanımlayabilir ve bu sınıfı ortak bir interface’den kalıtım aldırabilirsiniz. Eğer “Program to interfaces” deyimini duyduysanız, işte burada anlatmaya çalıştığım şey biraz da bu. Sonrasında bu servis sınıflarını istediğiniz component’e enjekte edebilirsiniz. Enjekte edilen sınıf, tasarımınız bitene kadar sadece mock veriler tutan bir sınıf olabilir. Sonrasında ise, yeni sınıfınız direk HTTP istekleri ile gerçek verileri web API’nızdan alıp getirebilir. Bu şekilde tanımladığınız sınıfları istediğiniz scope içinde kullanabilir hatta sadece bazı scopeler’da görülebilir olmasını sağlayabilirsiniz. Basit bir şekilde, Inject edilebilen bir sınıf Angular’da aşağıda ki gibi tanımlanır:

import { Injectable } from '@angular/core';
@Injectable({
providedIn: 'root',
})
export class UserService {
}

Angular’da ki DI ile alakalı tek sorunum ilk öğrenenler için biraz kompleks olması . Belki de kullandıkları terminoloji bana biraz garip geldi. Her ne ise, şunu diyebilirim: güçlü bir konsept. Tam olarak anlamak için kullanmanız gerekiyor. Ama kullandıkça, yukarıda ki örnek ve daha nice farklı senaryo için çok yardımcı olacak bir sistem. Öğrenirken, dikkat etmeniz gereken şeyler: Scope, Provider, Injectable, ve Injector. Aslında çok zor değil, sadece biraz kafa karıştırabiliyor.

6. More

Angular ile alakalı sevdiğim ve saymak istediğim daha çok şey var. Ama o zaman bu yazı okunmaz hale gelir. Yukarıda ki 5 tane neden kod tasarımı ve okunabilirliği açısından en değerli gördüğüm özellikler. Angular daha bir ton başka özellikler ile geliyor. Animasyonlar, Pipes, Lazy Loading, Material Design, vs. Açıkcası hepsi yerine göre altın değerinde olan özellikler. Mesela, kendi projemde Material Design kütüphanesini kullanıyorum ve yazılımcı olup, tasarımcı olmayan benim işimi fazlasıyla kolaştırmış oluyor.

Ufak Bir Ekleme: Angular CLI (Command Line Interface)

Angular’ın CLI desteğinden bahsetmemek olmazdı açıkcası. Yeni component ve module eklemeyi ciddi oranda kolaylaştırıyor ve aynı zamanda başka araçlar ile rahatlıkla entegre olabilecek şekilde çalışıyor. Eğer Angular ile çalışacaksanız, CLI komutlarını öğrenmemezlik yapmayın.

Sonuç

Angular güzel bir şey.