feat: updated blog content and blog detail component
This commit is contained in:
poyrazavsever
@@ -106,7 +106,7 @@ export function BlogContent({ data }: BlogContentProps) {
|
||||
date={post.date}
|
||||
readTime={post.readTime}
|
||||
href={post.href}
|
||||
className="rounded-sm border-border"
|
||||
className="rounded-sm border-border [&_h3]:line-clamp-2 [&_h3]:min-h-[2.5rem]"
|
||||
author={{ name: post.author, avatar: "/logo/logo.jpeg" }}
|
||||
/>
|
||||
))}
|
||||
|
||||
@@ -123,10 +123,9 @@ export function BlogDetailContent({ post }: BlogDetailContentProps) {
|
||||
</header>
|
||||
|
||||
<Card className="relative aspect-[16/8] overflow-hidden rounded-sm border-border">
|
||||
<Image
|
||||
<img
|
||||
src={post.coverImage}
|
||||
alt={post.title}
|
||||
fill
|
||||
sizes="(max-width: 768px) 100vw, 50vw"
|
||||
className="object-cover"
|
||||
/>
|
||||
|
||||
@@ -4,83 +4,64 @@ category: "Yazilim"
|
||||
date: "2026-02-01"
|
||||
readTime: "8 min read"
|
||||
author: "Poyraz Avsever"
|
||||
excerpt: "Yazılım geliştirme sürecinde, kod yazmanın ötesinde pek çok detayla uğraşıyoruz. Commit mesajları da bu sürecin kritik bir parçası tabii ki. Ancak commit mesajları, bazen dağını..."
|
||||
coverImage: "/news/performance.svg"
|
||||
excerpt: "Bu yazida temel kavramlari, pratik ornekleri ve uygulayabileceginiz ipuclarini sade bir dille bulabilirsiniz."
|
||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/1*WQOgajPE2m4aYuVC3SZoFQ.jpeg"
|
||||
---
|
||||
|
||||
Yazılım geliştirme sürecinde, kod yazmanın ötesinde pek çok detayla uğraşıyoruz. Commit mesajları da bu sürecin kritik bir parçası tabii ki. Ancak commit mesajları, bazen dağınık, anlaşılmaz ve düzensiz olabiliyor. İşte bu noktada “Conventional Commits” devreye giriyor.
|
||||
Yazılım geliştirme sürecinde yalnızca kod yazmıyoruz; aynı zamanda takım iletişimini ve proje geçmişini de yönetiyoruz. Commit mesajları bu süreçte kritik rol oynar. Conventional Commits, commit geçmişini daha anlaşılır ve sürdürülebilir hale getiren pratik bir standarttır.
|
||||
|
||||
|
||||
## Conventional Commits Nedir?
|
||||
|
||||
Conventional Commits Nedir?
|
||||
Conventional Commits, commit mesajlarını belirli bir formatta yazmayı öneren bir standarttır. Her commit'in amacı daha hızlı anlaşılır; release notları, sürümleme ve ekip içi takip süreçleri kolaylaşır.
|
||||
|
||||
Conventional Commits, commit mesajlarınızı belirli bir formata oturtan bir yazılım standardı. Amaç, her commit’in ne yaptığını net bir şekilde ifade etmek ve proje geçmişini daha anlaşılır hale getirmek. Commit mesajlarınızı bu standarda göre yazmak, projeyi daha düzenli, takip edilebilir ve sürdürülebilir kılar. Gelin şimdi beraber inceleyelim.
|
||||
Neden Conventional Commits Kullanmalıyız?
|
||||
1. Anlaşılabilirlik
|
||||
## Neden Kullanmalıyız?
|
||||
|
||||
Commit geçmişinin anlaşılabilir olması hepimiz için önemli. Bu standart, projede yapılan değişikliklerin kolayca takip edilmesini sağlıyor. Büyük projelerde, hangi commit’in hangi sorunu çözdüğünü veya hangi yeni özelliği eklediğini anlamak zaman zaman zorlaştığı için bu gibi standartları kullanmak yazılımcıların işini kolaylaştırıyor.
|
||||
2. İzlenebilirlik ve Şeffaflık
|
||||
### 1. Anlaşılabilirlik
|
||||
|
||||
Commit mesajlarımızı tutarlı ve net hale getirmek, proje geçmişimizde yapılan değişikliklerin izlenmesini kolaylaştırıyor. Özellikle geriye dönük uyumluluğu bozan değişikliklerde, bu düzenlemeler büyük bir avantaj sağlıyor.
|
||||
Peki Bu Commit Mesajları Nasıl Yazılıyor?
|
||||
Commit geçmişi daha okunabilir olur. Özellikle büyük projelerde hangi commit'in neyi değiştirdiğini bulmak çok daha hızlı hale gelir.
|
||||
|
||||
Conventional Commits’e göre, her commit mesajı üç ana bölümden oluşur:
|
||||
### 2. İzlenebilirlik ve Şeffaflık
|
||||
|
||||
Başlık (Summary): Mesajın türünü ve kısaca ne yaptığını belirtir.
|
||||
Gövde (Body): Değişikliğin detaylarını açıklar. Neden yapıldığını ve nasıl yapıldığını anlatır.
|
||||
Altbilgi (Footer): Breaking changes gibi uyumluluğu bozan değişiklikler veya kapatılan sorunlar burada belirtilir.
|
||||
Hangi değişikliğin bug fix, hangisinin yeni özellik olduğu netleşir. Geriye dönük analiz ve hata takibi kolaylaşır.
|
||||
|
||||
Commit Türleri
|
||||
## Commit Mesajı Yapısı
|
||||
|
||||
Commit mesajları belirli türlerle başlar. İşte en yaygın kullanılan türler: Daha detaylı commit türlerini incelemek için tıklayın.
|
||||
Conventional Commits'te mesaj genelde üç bölümden oluşur:
|
||||
|
||||
feat: Yeni bir özellik eklenmesi.
|
||||
fix: Bir hatanın düzeltilmesi.
|
||||
docs: Sadece dokümantasyonla ilgili değişiklikler.
|
||||
style: Kodun işleyişini değiştirmeyen biçimlendirme (boşluklar, noktalı virgüller vb.).
|
||||
refactor: Kodda, işlevini değiştirmeyen yeniden düzenleme.
|
||||
- **Başlık (Summary)**: Tür + kısa açıklama
|
||||
- **Gövde (Body)**: Değişikliğin nedeni ve detayları
|
||||
- **Altbilgi (Footer)**: Breaking change veya issue referansları
|
||||
|
||||
Gelin beraber örnek bir Commit Mesajını inceleyelim:
|
||||
## Sık Kullanılan Türler
|
||||
|
||||
feat(login): add JWT authentication
|
||||
- `feat`: Yeni özellik
|
||||
- `fix`: Hata düzeltmesi
|
||||
- `docs`: Dokümantasyon değişikliği
|
||||
- `style`: Format/stil düzeni (işlev değişmez)
|
||||
- `refactor`: Davranışı değiştirmeden kod iyileştirme
|
||||
|
||||
Added JWT authentication to the login process to enhance security.
|
||||
This change involves updating the login controller and modifying the user model.
|
||||
## Örnek Commit
|
||||
|
||||
BREAKING CHANGE: The user model now requires a JWT token for all login operations.
|
||||
```text
|
||||
feat(login): add JWT authentication
|
||||
|
||||
Başlık (Summary):
|
||||
Added JWT authentication to the login process to enhance security.
|
||||
This change involves updating the login controller and modifying the user model.
|
||||
|
||||
feat:
|
||||
Commit türünü belirtir. Burada feat (feature) türü kullanılmış, bu da commit'in projeye yeni bir özellik eklediğini gösterir. Başka türler de kullanılabilir, örneğin fix (bir hatayı düzeltmek), docs (dokümantasyon güncellemeleri) gibi.
|
||||
(login):
|
||||
Parantez içinde belirtilen bölüm, bu özelliğin veya değişikliğin hangi modülü veya bölümü etkilediğini gösterir. Burada login kullanılmış, yani yapılan değişiklik, login (giriş) süreciyle ilgilidir.
|
||||
add JWT authentication:
|
||||
Bu, commit'in yaptığı spesifik değişikliği kısa ve öz bir şekilde açıklar. Burada, JWT (JSON Web Token) ile kimlik doğrulamanın login sürecine eklendiği belirtiliyor.
|
||||
BREAKING CHANGE: The user model now requires a JWT token for all login operations.
|
||||
```
|
||||
|
||||
2. Gövde (Body):
|
||||
Bu örnekte:
|
||||
|
||||
İlk Cümle:
|
||||
“Added JWT authentication to the login process to enhance security.”
|
||||
Bu cümle, yapılan değişikliğin amacını ve sonucunu açıklar. Burada, JWT kimlik doğrulamasının login sürecine eklendiği ve bunun güvenliği artırmak amacıyla yapıldığı belirtiliyor.
|
||||
İkinci Cümle:
|
||||
“This change involves updating the login controller and modifying the user model.”
|
||||
Bu cümle, değişikliğin hangi dosya veya modülleri etkilediğini daha detaylı açıklar. Burada, login controller’ın güncellendiği ve user model’in değiştirildiği belirtiliyor.
|
||||
- `feat(login)` kısmı değişikliğin türünü ve kapsamını açıklar.
|
||||
- Body kısmı neyin ve neden yapıldığını anlatır.
|
||||
- `BREAKING CHANGE` ifadesi geriye dönük uyumluluğu etkileyen bir güncelleme olduğunu belirtir.
|
||||
|
||||
3. Altbilgi (Footer):
|
||||
## Sonuç
|
||||
|
||||
BREAKING CHANGE:
|
||||
Bu ifade, uyumluluğu bozan bir değişiklik olduğunu gösterir. Eğer bir commit, mevcut kodun çalışmasını bozacak bir değişiklik yapıyorsa, bu mutlaka belirtilmelidir. Bu, diğer geliştiricilerin bu değişiklikten haberdar olmasını sağlar.
|
||||
Detay:
|
||||
“The user model now requires a JWT token for all login operations.”
|
||||
Bu açıklama, uyumluluğu bozan değişikliğin ne olduğunu detaylandırır. Burada, kullanıcı modelinin artık tüm giriş işlemleri için bir JWT token gerektirdiği belirtiliyor. Bu, diğer geliştiricilerin bu değişikliği uygularken dikkatli olmaları gerektiğini ifade eder.
|
||||
Conventional Commits, proje geçmişini düzenler ve ekip verimliliğini artırır. Özellikle takım çalışmasında ve sürüm yönetiminde standart bir commit dili oluşturmak için güçlü bir yöntemdir.
|
||||
|
||||
Sonuç olarak
|
||||
## Kaynak
|
||||
|
||||
Conventional Commits, yazılım geliştirme sürecimizi daha düzenli, anlaşılır ve verimli hale getirdi. Commit mesajlarımızı belirli bir yapıya oturtarak, proje yönetimimizi daha sürdürülebilir ve izlenebilir bir hale getirdik.
|
||||
|
||||
Eğer siz de projelerinizde daha düzenli bir commit geçmişi istiyorsanız, Conventional Commits’i denemenizi tavsiye ederim.
|
||||
Kaynak
|
||||
|
||||
[https://www.conventionalcommits.org/en/v1.0.0/](https://www.conventionalcommits.org/en/v1.0.0/)
|
||||
[https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits](https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits)
|
||||
- [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
|
||||
- [3 reasons why you should use conventional commits](https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits)
|
||||
|
||||
@@ -4,146 +4,116 @@ category: "Testing"
|
||||
date: "2026-02-22"
|
||||
readTime: "9 min read"
|
||||
author: "Poyraz Avsever"
|
||||
excerpt: "Yazılım geliştirmek, heyecan verici bir yolculuk ama aynı zamanda dikkatli olunması gereken bir süreç değil mi?"
|
||||
coverImage: "/news/performance.svg"
|
||||
excerpt: "Bu yazida temel kavramlari, pratik ornekleri ve uygulayabileceginiz ipuclarini sade bir dille bulabilirsiniz."
|
||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*uNpkjRqVlaB2WbDl.png"
|
||||
---
|
||||
|
||||
|
||||
Frontend tarafında kaliteyi korumanın en sağlam yolu testtir. Bu yazıda, farklı amaçlara hizmet eden iki güçlü aracı birlikte ele alıyoruz: Jest ve Cypress.
|
||||
|
||||
Merhaba arkadaşlar!
|
||||
|
||||
Yazılım geliştirmek, heyecan verici bir yolculuk ama aynı zamanda dikkatli olunması gereken bir süreç değil mi? Kullanıcılar, uygulamalarımızdan her zaman en iyisini bekliyor ve bu beklentileri karşılamak için güvenilir, hatasız bir kod yazmak şart. İşte bu noktada test yazmanın önemi devreye giriyor.
|
||||
|
||||
Frontend alanı, kullanıcıların direk etkileşimde bulunduğu bir alan olduğu için, test yazmak daha da kritik hale geliyor. Unit testlerden E2E testlerine kadar pek çok farklı türde test var. Bu yazımda, seninle beraber popüler iki test aracı olan Jest ve Cypress’i keşfedeceğiz. Jest, JavaScript projelerinde sıkça tercih edilen bir test framework’ü, Cypress ise modern web uygulamaları için geliştirilmiş güçlü bir E2E test aracı. Bu araçların sağladığı avantajları ve nasıl kullanılacaklarını birlikte inceleyerek, test yazmaya dair daha fazla bilgi edinmene yardımcı olmayı umuyorum.
|
||||
## Jest Nedir?
|
||||
|
||||
|
||||
Jest, özellikle unit ve integration testlerde sık kullanılan hızlı bir JavaScript test framework'üdür. React projelerinde de çok yaygın kullanılır.
|
||||
|
||||
Jest Nedir?
|
||||
|
||||
Gelin bakalım, jest nedir? Jest, Facebook tarafından geliştirilen ve JavaScript projeleri için oldukça popüler bir test framework’üdür. Hızlı ve kullanıcı dostu olmasıyla bilinir; bu da onu hem yeni başlayanlar hem de deneyimli geliştiriciler için ideal bir seçim yapar. Jest, testleri yazmayı ve çalıştırmayı oldukça kolay hale getirir, böylece kodunu test etmek için saatler harcamana gerek kalmaz.
|
||||
|
||||
Peki, Jest’i ne zaman kullanmalısın? Eğer React componentleri üzerinde çalışıyorsan veya basit JavaScript fonksiyonlarını test etmek istiyorsan, Jest kesinlikle işine yarayacak. Özellikle unit test yazarken, Jest’in sağladığı araçlar ile hataları daha kolay tespit edebilir ve kodunu güvence altına alabilirsin.
|
||||
|
||||
Kurulum ise oldukça basit. Tek bir komutla Jest’i projene ekleyebilirsin:
|
||||
### Kurulum
|
||||
|
||||
```bash
|
||||
npm install --save-dev jest
|
||||
```
|
||||
|
||||
Kurulumdan sonra, Jest’i kullanmaya başlamak için birkaç temel ayar yapman yeterli. Şimdi, basit bir test örneğiyle devam edelim.
|
||||
### Basit Test Örneği
|
||||
|
||||
```js
|
||||
function toplama(a, b) {
|
||||
return a + b;
|
||||
}
|
||||
|
||||
Bu fonksiyonu test etmek için Jest ile şöyle bir test yazabilirsin:
|
||||
|
||||
test('2 + 3 eşittir 5', () => {
|
||||
test("2 + 3 eşittir 5", () => {
|
||||
expect(toplama(2, 3)).toBe(5);
|
||||
});
|
||||
```
|
||||
|
||||
İşte bu kadar! Testi çalıştırmak için terminalde npm test komutunu kullanabilirsin. Eğer her şey yolundaysa, testin geçtiğini göreceksin.
|
||||
Jest ile Test Örneği
|
||||
### Grup Testleri
|
||||
|
||||
Jest ile test yazmak, emin ol düşündüğünden çok daha kolay. Test senaryolarını yazarken, describe ve it blokları kullanarak yapıyı oluşturabilirsin. Bu, testlerinin daha düzenli ve okunabilir olmasını sağlar.
|
||||
|
||||
Örneğin, bir toplama fonksiyonunu test ederken şöyle bir yapı oluşturabilirsin:
|
||||
|
||||
describe('Toplama Fonksiyonu', () => {
|
||||
it('2 + 3 eşittir 5', () => {
|
||||
```js
|
||||
describe("Toplama Fonksiyonu", () => {
|
||||
it("2 + 3 eşittir 5", () => {
|
||||
expect(toplama(2, 3)).toBe(5);
|
||||
});
|
||||
|
||||
it('0 + 0 eşittir 0', () => {
|
||||
it("0 + 0 eşittir 0", () => {
|
||||
expect(toplama(0, 0)).toBe(0);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
Bu yapı ile fonksiyonunun farklı durumlarını test etmiş oluyorsun. describe bloğu, test grubu için bir başlık oluştururken, it blokları ise her bir test senaryosunu tanımlıyor. Basit değil mi?
|
||||
Mocking ve Spy Kullanımı
|
||||
### Mocking Örneği
|
||||
|
||||
Bazen test ettiğin kod, dış bağımlılıklara (örneğin, API isteklerine) ihtiyaç duyabilir. Bu durumlarda, Jest’in sunduğu mocking ve spy özellikleri devreye giriyor. Mocking ile bağımlılıkları taklit edebilir ve testlerinizi izole edebilirsin.
|
||||
```js
|
||||
jest.mock("axios");
|
||||
|
||||
Örneğin, bir API çağrısını mocklamak için şu şekilde yapabilirsin:
|
||||
it("API çağrısı başarılı olursa veriyi döndürmeli", async () => {
|
||||
const veriler = { data: { isim: "Ali" } };
|
||||
axios.get.mockResolvedValue(veriler);
|
||||
|
||||
jest.mock('axios'); // axios kütüphanesini mockladık
|
||||
|
||||
it('API çağrısı başarılı olursa veriyi döndürmeli', async () => {
|
||||
const veriler = { data: { isim: 'Ali' } };
|
||||
axios.get.mockResolvedValue(veriler); // Mock cevap
|
||||
|
||||
const cevap = await apiCagir(); // Api istek atıyoruz
|
||||
expect(cevap.isim).toBe('Ali');
|
||||
const cevap = await apiCagir();
|
||||
expect(cevap.isim).toBe("Ali");
|
||||
});
|
||||
```
|
||||
|
||||
Snapshot Testing
|
||||
### Snapshot Örneği
|
||||
|
||||
Snapshot testing, bileşenlerinin görsel çıktılarının kaydedilmesi ve daha sonra bu çıktılarla karşılaştırılması için mükemmel bir yöntemdir. Özellikle React componentlerinde oldukça kullanışlıdır.
|
||||
```js
|
||||
import { render } from "@testing-library/react";
|
||||
import MyComponent from "./MyComponent";
|
||||
|
||||
Bir bileşeni snapshot ile test etmek için, şu şekilde yazabilirsin:
|
||||
|
||||
import { render } from '@testing-library/react';
|
||||
import MyComponent from './MyComponent';
|
||||
|
||||
test('MyComponent snapshot testi', () => {
|
||||
test("MyComponent snapshot testi", () => {
|
||||
const { asFragment } = render(<MyComponent />);
|
||||
expect(asFragment()).toMatchSnapshot(); // Componentin çıktısını kaydediyor
|
||||
expect(asFragment()).toMatchSnapshot();
|
||||
});
|
||||
```
|
||||
|
||||
Cypress Nedir?
|
||||
## Cypress Nedir?
|
||||
|
||||
Cypress, gerçek tarayıcıda çalışan ve kullanıcı akışlarını uçtan uca test etmeye odaklanan bir E2E test aracıdır.
|
||||
|
||||
|
||||
|
||||
Cypress, modern web uygulamaları için geliştirilmiş güçlü bir E2E (end-to-end) test aracı. Kullanıcı etkileşimlerini gerçek zamanlı olarak simüle edebilmesi, onu diğer test araçlarından ayıran en önemli özelliklerinden biri. Cypress, kullanıcıların uygulamanla nasıl etkileşimde bulunduğunu test ederken, hataları hızlı bir şekilde tespit etmeni sağlıyor.
|
||||
|
||||
Cypress ile test yazmak oldukça keyifli, çünkü her şey anlık geri bildirim almanı sağlayacak şekilde tasarlanmış. Testlerini yazarken tarayıcıda anlık olarak sonuçları görebilirsin; bu da debugging sürecini oldukça kolaylaştırır.
|
||||
|
||||
Cypress’i projene eklemek de oldukça basit. Tek bir komutla kurulumunu gerçekleştirebilirsin:
|
||||
### Kurulum
|
||||
|
||||
```bash
|
||||
npm install cypress --save-dev
|
||||
```
|
||||
|
||||
Kurulumdan sonra, npx cypress open komutunu çalıştırarak Cypress arayüzünü açabilirsin. Buradan test senaryolarını kolayca yazmaya başlayabilirsin.
|
||||
Basit Bir Test Örneği
|
||||
### Basit E2E Senaryosu
|
||||
|
||||
Cypress ile test yazmak için öncelikle test senaryonu belirlemen gerekiyor. Örneğin, bir web sayfasına erişip bir butona tıklayarak bir formu doldurmayı test edelim:
|
||||
|
||||
describe('Form Testi', () => {
|
||||
it('Formu doldurmalı ve göndermeli', () => {
|
||||
cy.visit('https://ornekwebsayfasi.com'); // Test edilecek web sayfasına git
|
||||
cy.get('input[name="isim"]').type('Ali'); // İsim alanına "Ali" yaz
|
||||
cy.get('input[name="email"]').type('ali@example.com'); // Email alanına söylediğimiz mailiyaz
|
||||
cy.get('button[type="submit"]').click(); // Gönder butonuna tıkla
|
||||
cy.get('.success-message').should('contain', 'Başarıyla gönderildi!'); // Başarı mesajını kontrol et
|
||||
```js
|
||||
describe("Form Testi", () => {
|
||||
it("Formu doldurmalı ve göndermeli", () => {
|
||||
cy.visit("https://ornekwebsayfasi.com");
|
||||
cy.get('input[name="isim"]').type("Ali");
|
||||
cy.get('input[name="email"]').type("ali@example.com");
|
||||
cy.get('button[type="submit"]').click();
|
||||
cy.get(".success-message").should("contain", "Başarıyla gönderildi!");
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
Yukarıdaki örnekte, bir formu doldurup gönderirken Cypress’in sağladığı basit komutları kullandık. cy.visit(), cy.get() ve cy.type() gibi komutlar ile kullanıcı etkileşimlerini simüle ettik.
|
||||
Cypress’in Sunduğu Avantajlar
|
||||
## Jest ve Cypress Farkı
|
||||
|
||||
Cypress’in en büyük avantajlarından biri, testleri yazarken anlık geri bildirim alabilmendir. Testler çalışırken, tarayıcıda hangi adımların gerçekleştiğini görüp hataları hemen tespit edebilirsin. Ayrıca, Cypress ile birlikte gelen görsel test aracı sayesinde, test sonuçlarını kolayca inceleyebilirsin.
|
||||
### Jest Ne Zaman?
|
||||
|
||||
Cypress, test ortamlarını yönetmekte de oldukça başarılıdır. Farklı ortamlar için ayarları yapılandırabilir, test verilerini kolayca oluşturabilirsin. Bu da, projeni test etme sürecini daha da verimli hale getirir.
|
||||
Jest ve Cypress Arasındaki Farklar
|
||||
- Fonksiyon ve component düzeyi testler
|
||||
- Mocking/snapshot ihtiyaçları
|
||||
- Hızlı geri bildirim
|
||||
|
||||
Jest ve Cypress, farklı test ihtiyaçlarını karşılamak için tasarlanmış iki güçlü araçtır. Ancak, hangi durumda hangisini kullanman gerektiğini bilmen önemli. İşte bu iki araç arasındaki temel farklar:
|
||||
Kullanım Alanları
|
||||
### Cypress Ne Zaman?
|
||||
|
||||
Jest: Jest, genellikle unit ve integration testler için kullanılır. JavaScript ve özellikle React projelerinde, componentlerin ve fonksiyonların bağımsız olarak test edilmesini sağlar. Jest, daha çok uygulamanın iç yapısını test ederken, dış bağımlılıklardan bağımsız bir şekilde çalışmanıza olanak tanır.
|
||||
Cypress: Cypress, end-to-end (E2E) testler için idealdir. Kullanıcı etkileşimlerini simüle ederek, uygulamanın tüm akışını test etmeni sağlar. Cypress ile, bir kullanıcının uygulamanı nasıl deneyimleyeceğini gerçek bir tarayıcı ortamında test edebilirsin.
|
||||
- Kullanıcı akışı testleri
|
||||
- Form, yönlendirme, auth gibi senaryolar
|
||||
- Gerçek tarayıcı davranışı doğrulama
|
||||
|
||||
Test Yazım Tarzı
|
||||
## Sonuç
|
||||
|
||||
Jest: Jest’te test yazarken, describe, it ve expect gibi yapıları kullanarak senaryoları belirli bir düzen içinde yazarsın. Mocking ve snapshot testing gibi özellikleri sayesinde, fonksiyonel testler yazmak oldukça kolaydır.
|
||||
Cypress: Cypress’te test yazarken, daha doğal bir kullanıcı akışı oluşturursun. cy.get(), cy.type(), ve cy.click() gibi komutlar ile kullanıcı etkileşimlerini simüle edersin. Bu, test yazımını daha basit hale getirir.
|
||||
|
||||
Geribildirim Süreci
|
||||
|
||||
Jest: Jest testlerini çalıştırırken sonuçları terminal üzerinden görürsün. Eğer bir test başarısız olursa, hata mesajlarını inceleyerek sorunu bulabilirsin. Ancak, anlık görselleştirme imkanı sınırlıdır.
|
||||
Cypress: Cypress, testleri çalıştırırken bir tarayıcı penceresinde anlık sonuçları gösterir. Testlerin hangi adımda başarısız olduğunu görerek, hataları daha kolay tespit edebilirsin. Bu görsel geribildirim, debugging sürecini oldukça hızlandırır.
|
||||
|
||||
Hangi Aracı Ne Zaman Kullanmalısın?
|
||||
|
||||
Jest: Eğer uygulamanın iç yapısını test etmek istiyorsan, fonksiyonları ve componentleri ayrı ayrı değerlendirmek için Jest’i kullan. Bu, özellikle React bileşenlerinde unit test yazmak için gayet ideal.
|
||||
Cypress: Kullanıcı akışlarını, etkileşimlerini ve tüm uygulama işlevselliğini test etmek istiyorsan, Cypress mükemmel bir seçim olacaktır. E2E testlerin ile kullanıcı deneyimini en gerçekçi şekilde değerlendirebilirsin.
|
||||
|
||||
Sonuç
|
||||
|
||||
Test yazma pratiği, yazılım geliştirme sürecinin vazgeçilmez bir parçası. Hem Jest hem de Cypress, projelerinin kalitesini artırmak ve kullanıcı deneyimini iyileştirmek için güçlü araçlar sunuyor. Her iki aracın da kendine özgü avantajları ve kullanım alanları var, bu nedenle projenin ihtiyaçlarına göre en uygun olanı seçmek çok önemlidir. Ben de daha yeni yeni öğreniyorum ve bu süreçte öğrendiklerimi ise aktarmaya çalışyorum. Umarım bu yazımda anlattıklarım sana yardımcı olmuştur. İyi kodlamalar!
|
||||
Jest ve Cypress birbirinin alternatifi değil, tamamlayıcısıdır. Jest ile iç mantığı, Cypress ile gerçek kullanıcı deneyimini doğrulayarak daha güvenilir bir frontend geliştirme süreci kurulabilir.
|
||||
|
||||
@@ -4,46 +4,41 @@ category: "TypeScript"
|
||||
date: "2026-02-18"
|
||||
readTime: "8 min read"
|
||||
author: "Poyraz Avsever"
|
||||
excerpt: "Son zamanlarda JavaScript’ten TypeScript’e geçiş yapmak üzerine yoğun bir şekilde çalışıyorum ve bu süreçte yaşadıklarımı sizlerle paylaşmak istiyorum."
|
||||
coverImage: "/news/performance.svg"
|
||||
excerpt: "Bu yazida temel kavramlari, pratik ornekleri ve uygulayabileceginiz ipuclarini sade bir dille bulabilirsiniz."
|
||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*yRK5eL_pqabAhrn7"
|
||||
---
|
||||
|
||||
Merhaba arkadaşlar!
|
||||
JavaScript'ten TypeScript'e geçiş, özellikle React projelerinde kod kalitesini gözle görülür şekilde artırıyor. Bu yazıda JSX'ten TSX'e geçişte yaşadığım deneyimi, zorlukları ve kazançları paylaşıyorum.
|
||||
|
||||
|
||||
## Neden TypeScript?
|
||||
|
||||
Son zamanlarda JavaScript’ten TypeScript’e geçiş yapmak üzerine yoğun bir şekilde çalışıyorum ve bu süreçte yaşadıklarımı sizlerle paylaşmak istiyorum. TypeScript, JavaScript’in sunduğu dinamik yapının üzerine statik tiplerin eklenmesiyle kod yazım sürecini bir adım ileriye taşıyor. Peki ben neden geçiyorum? Şuan bir ekiple beraber bir proje üzerinde çalışıyoruz. Ve buna karar kaldık. Bu geçişin benim için nasıl bir yolculuk olduğunu anlatmak, belki sizlere de bu konuda yardımcı olabilir.
|
||||
Başlangıç: Neden TypeScript?
|
||||
Geçiş kararının temel nedeni daha güvenli ve öngörülebilir kod yazabilmekti. Dinamik tip yapısı bazı durumlarda hızlı başlatma sağlasa da, proje büyüdükçe hata ayıklama maliyetini artırabiliyor.
|
||||
|
||||
İlk olarak, TypeScript’e geçiş yapma kararımızın arkasında daha sağlam ve hatasız bir kod yazma isteğimiz vardı. JavaScript’te dinamik tipler bazen kafa karıştırıcı olabiliyor ve bu, büyük projelerde hata ayıklama sürecini zorlaştırıyor. TypeScript, bu sorunları çözmek için tip güvenliği ve geliştirilmiş hata ayıklama yetenekleri sunuyor.
|
||||
İlk Adımlar: JS’den TSX’e
|
||||
## Geçiş Sürecinde İzlediğim Yol
|
||||
|
||||
Geçiş süreci, özellikle JSX’ten TSX’e geçerken bazı zorluklar getirdi. İlk başta, tip tanımlamaları ve interface’lerle ilgili kafam karışmadı değil. Ancak, bu süreçte birkaç önemli adım izlemeye başladım:
|
||||
- Temel `props` ve `state` tiplerini netleştirdim.
|
||||
- Bileşenleri tek seferde değil, kademeli şekilde TSX'e taşıdım.
|
||||
- Hata mesajlarını rehber gibi kullanıp tip sistemini adım adım oturttum.
|
||||
|
||||
Temel Tip Tanımlamaları: Öncelikle, projedeki temel tipleri tanımlamaya başladım. Bu, özellikle props ve state gibi yapılar için çok faydalı oldu. TypeScript ile, her bir prop ve state’in türünü belirleyerek, olası hataları erkenden yakalayabiliyorum.
|
||||
TSX ile JSX’yi Anlama: JSX’ten TSX’e geçişte en önemli şeylerden biri, type checking (tip kontrolü) özelliğinden yararlanmak. Bu, bileşenlerin doğru tipteki verilerle çalışıp çalışmadığını kontrol etmeme yardımcı oldu.
|
||||
Gradual Migration (Aşamalı Geçiş): Geçiş sürecini bir anda yapmadım. Bunun yerine, projeyi kademeli olarak TypeScript’e taşıdım. Bu sayede, karşılaştığım sorunları daha kolay çözebildim ve büyük değişiklikler yapmadan önce küçük parçalar üzerinde çalışabildim.
|
||||
## JSX ve TSX Karşılaştırması
|
||||
|
||||
Gelin küçük bir karşılaştırma yapalım.
|
||||
JSX (JavaScript XML)
|
||||
### JSX Örneği
|
||||
|
||||
JSX, React bileşenlerinde JavaScript kodunu HTML benzeri bir sözdizimi ile yazmamıza olanak tanır. Ancak, JSX’te tip kontrolü yapılmıyor.
|
||||
|
||||
import React from 'react';
|
||||
```jsx
|
||||
import React from "react";
|
||||
|
||||
const Greeting = ({ name }) => {
|
||||
return <h1>Hello, {name}!</h1>;
|
||||
};
|
||||
|
||||
export default Greeting;
|
||||
```
|
||||
|
||||
TSX (TypeScript XML)
|
||||
### TSX Örneği
|
||||
|
||||
TSX ise, JSX’in TypeScript ile birleştirilmiş hali olup, tip kontrolü ve daha iyi hata ayıklama özellikleri sunuyor. Tip güvenliği sağlıyor ve bu, bileşenlerin beklenmedik hatalara karşı korunmasına yardımcı oluyor.
|
||||
```tsx
|
||||
import React from "react";
|
||||
|
||||
import React from 'react';
|
||||
|
||||
// Props için TypeScript ile tip tanımlaması
|
||||
interface GreetingProps {
|
||||
name: string;
|
||||
}
|
||||
@@ -53,38 +48,37 @@ const Greeting: React.FC<GreetingProps> = ({ name }) => {
|
||||
};
|
||||
|
||||
export default Greeting;
|
||||
```
|
||||
|
||||
Karşılaştırma
|
||||
## Farklar
|
||||
|
||||
Tip Kontrolü:
|
||||
### Tip Kontrolü
|
||||
|
||||
JSX: Tip kontrolü yoktur.
|
||||
TSX: Props ve state için tip tanımlamaları yapılabilir.
|
||||
- JSX: Yerleşik tip güvenliği yoktur.
|
||||
- TSX: `props` ve `state` açıkça tiplenebilir.
|
||||
|
||||
2. Geliştirici Deneyimi:
|
||||
### Geliştirici Deneyimi
|
||||
|
||||
JSX: Kod tamamlama ve hata ayıklama sınırlıdır.
|
||||
TSX: Daha iyi kod tamamlama ve erken hata tespiti sağlar.
|
||||
- JSX: IDE desteği daha sınırlı olabilir.
|
||||
- TSX: Otomatik tamamlama ve erken hata yakalama daha güçlüdür.
|
||||
|
||||
3. Kod Güvenliği:
|
||||
### Kod Güvenliği
|
||||
|
||||
JSX: Tip hatalarına karşı koruma yoktur.
|
||||
TSX: Tip hatalarını önlemeye yardımcı olur ve daha güvenli kod sağlar.
|
||||
- JSX: Runtime'da hata görme ihtimali daha yüksektir.
|
||||
- TSX: Hataların önemli kısmı derleme aşamasında yakalanır.
|
||||
|
||||
Bu örnekler, JSX ve TSX arasındaki temel farkları gösteriyor sanırım. Kısaca TypeScript kullanarak daha sağlam ve güvenli bir kod yazabilirsiniz arkadaşlar.
|
||||
Yaşadığım Zorluklar
|
||||
## Karşılaştığım Zorluklar
|
||||
|
||||
TypeScript’e geçiş yaparken karşılaştığım bazı zorluklar oldu. En büyük sorunlardan biri, eski JavaScript kodunun TypeScript’e uyumlu hale getirilmesiydi. Özellikle, mevcut kodlarda eksik tip tanımlamaları ve uyumsuzluklar bulmak bazen zaman alabiliyor. Düzeltiyorum, çok zaman alıyor. Ayrıca, bazı kütüphaneler ve araçlar TypeScript ile tam uyumlu olmayabiliyor, bu da ekstra uyum sorunlarına neden olabiliyor. Fakat daha sonra dönüp baktığım zaman bunlara değdini görüyorum.
|
||||
Faydalar
|
||||
- Eski JavaScript kodunu tip sistemine uyarlamak zaman aldı.
|
||||
- Bazı bağımlılıklarda ek tip tanımları gerekebildi.
|
||||
- Başlangıçta tip kuralları yavaşlatıyor gibi görünse de, orta vadede geliştirme hızını artırdı.
|
||||
|
||||
Ancak, TypeScript’in avantajları bu zorlukları gölgede bırakıyor. İşte bu geçişten elde ettiğim bazı önemli faydalar:
|
||||
## Elde Ettiğim Kazanımlar
|
||||
|
||||
Daha Güvenli Kod: TypeScript sayesinde, kodumda hata yapma olasılığım azaldı. Tip güvenliği, hataları daha erken aşamada tespit etmemi sağlıyor.
|
||||
Daha İyi Geliştirici Deneyimi: TypeScript, editörde daha iyi kod tamamlama ve hata ayıklama araçları sunuyor. Bu, geliştirme sürecimi daha verimli hale getiriyor.
|
||||
Daha Kolay Bakım: Tip tanımlamaları ve interface’ler, kodun bakımını ve genişletilmesini kolaylaştırıyor. Bu, özellikle büyük projelerde büyük bir avantaj.
|
||||
- Daha güvenli kod tabanı
|
||||
- Daha güçlü IDE desteği
|
||||
- Daha kolay bakım ve refactor
|
||||
|
||||
Sonuç
|
||||
## Sonuç
|
||||
|
||||
TypeScript’e geçiş yapmak, benim için zorlu ama öğretici bir süreç oldu. Bu geçiş, uzun vadede daha sağlam ve sürdürülebilir kod yazmama yardımcı oldu. Eğer siz de JavaScript’ten TypeScript’e geçmeyi düşünüyorsanız, başlangıçta bazı zorluklar yaşayabilirsiniz ama bu çabanın karşılığını eminim uzun vadede göreceksiniz.
|
||||
|
||||
Umarım bu yazı, TypeScript’e geçiş yapmayı düşünenler için faydalı olur. Siz de deneyimlerinizi veya sorularınızı paylaşmak isterseniz, yorumlarda buluşalım!
|
||||
JSX'ten TSX'e geçiş ilk etapta zahmetli görünse de, uzun vadede proje kalitesini artıran önemli bir yatırım. Özellikle ekipli geliştirmede TypeScript, ortak bir kalite standardı oluşturuyor.
|
||||
|
||||
@@ -4,19 +4,19 @@ category: "UX"
|
||||
date: "2026-02-05"
|
||||
readTime: "6 min read"
|
||||
author: "Poyraz Avsever"
|
||||
excerpt: "Tasarım dünyasında, ürünlerimizin kullanıcılarımızın ihtiyaçlarını en iyi şekilde karşılamasını istemek, hepimizin ortak amacı..."
|
||||
coverImage: "/news/design.svg"
|
||||
excerpt: "Bu yazida temel kavramlari, pratik ornekleri ve uygulayabileceginiz ipuclarini sade bir dille bulabilirsiniz."
|
||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*BEVhh2Et54wytkaA.jpg"
|
||||
---
|
||||
|
||||
Tasarım dünyasında, ürünlerimizin kullanıcılarımızın ihtiyaçlarını en iyi şekilde karşılamasını istemek, hepimizin ortak amacı. Ancak bu hedefe ulaşmak için bazen en temel adımları gözden kaçırabiliyoruz. Bu adımlardan biri de kullanıcı araştırması ve personas oluşturma. Gelin, bu iki önemli adımı nasıl gerçekleştirebileceğimizi ve tasarım sürecindeki kritik rollerini birlikte keşfedelim.
|
||||
Kullanıcı Araştırması: “Yolu Aydınlatan Işık”
|
||||
|
||||
## Kullanıcı Araştırması: “Yolu Aydınlatan Işık”
|
||||
|
||||
Kullanıcı araştırması, tasarım sürecinin temel taşlarından biridir. Ancak ne yazık ki, bu adım sıklıkla atlanabiliyor veya yeterince önemsenmiyor. Peki, neden bu kadar önemli?
|
||||
|
||||
|
||||
|
||||
Kullanıcı araştırması, gerçek kullanıcıların ihtiyaçlarını, beklentilerini ve zorluklarını anlamamıza yardımcı olur. Yani, tasarımımızın doğru yolda olup olmadığını bilmek için bir tür GPS cihazı gibi düşünün. Anketler, mülakatlar, gözlem ve kullanım testleri gibi yöntemlerle toplanan veriler, tasarım kararlarımızı şekillendirir. Bu veriler olmadan, tasarım sürecimiz kısa bir yolculuk olurdu; hem kullanıcı hem de tasarımcı için tatmin edici olmayan bir yolculuk.
|
||||
Personas Oluşturma: Kullanıcılarımızı Tanıyalım
|
||||
|
||||
## Personas Oluşturma: Kullanıcılarımızı Tanıyalım
|
||||
|
||||
Kullanıcı araştırmasından elde ettiğimiz verileri, personas adı verilen karakterlere dönüştürürüz. Persona, gerçek kullanıcıların temsilcisi olan hayali bir karakterdir. Bu karakterler, tasarım sürecinde karar alırken göz önünde bulundurmamız gereken “ideal” kullanıcılarımızı temsil eder.
|
||||
|
||||
@@ -24,15 +24,16 @@ Kullanıcı araştırmasından elde ettiğimiz verileri, personas adı verilen k
|
||||
|
||||
Bir persona oluştururken, demografik bilgilerden tutun, kullanıcıların hedeflerine, ihtiyaçlarına ve acı noktalarına kadar birçok ayrıntıyı dikkate alırız. Örneğin, “Mert”, 28 yaşında bir yazılım geliştirici olabilir. Mert, verimliliği artırmak isteyen bir teknoloji meraklısıdır ve kullanıcı dostu ara yüzler arar. Mert’in bu özellikleri, tasarım sürecinde ihtiyaçlarını karşılamak için nelere dikkat etmemiz gerektiğini anlamamıza yardımcı olur.
|
||||
|
||||
Personas’ın Gücü: Empati ve Odaklanma
|
||||
## Personas’ın Gücü: Empati ve Odaklanma
|
||||
|
||||
Personalar oluşturmanın bir başka avantajı da, ekibinizin kullanıcılarla daha empatik bir bağ kurmasına yardımcı olmasıdır. Persona karakterlerinizle sohbet ederken, onların ihtiyaçlarını ve beklentilerini anlamak daha kolay hale gelir. Bu empati, tasarım kararlarınızda daha bilinçli ve kullanıcı merkezli bir yaklaşım benimsemenizi sağlar.
|
||||
|
||||
Ayrıca personas oluşturmak, ekip içindeki tüm paydaşların aynı hedefe odaklanmasına yardımcı olur. Herkesin aynı “Mert”i, “Elif”i veya “Ahmet”i tanıması, tasarım sürecinde daha tutarlı ve uyumlu bir yaklaşım sergilenmesine olanak tanır.
|
||||
Sonuç: Kullanıcılarınızı Tanıyın, Onlara Uygun Tasarımlar Yapın
|
||||
|
||||
## Sonuç: Kullanıcılarınızı Tanıyın, Onlara Uygun Tasarımlar Yapın
|
||||
|
||||
Kullanıcı araştırması ve personas oluşturma, sadece tasarım sürecinin bir parçası değil, aynı zamanda başarılı bir UX (Kullanıcı Deneyimi) tasarımı için vazgeçilmez adımlardır. Bu adımlar, tasarım sürecinizi bilgiyle donatır ve gerçek kullanıcıların ihtiyaçlarını karşılamanıza yardımcı olur.
|
||||
|
||||
Sonuç olarak, kullanıcınızı tanıdığınızda ve onların beklentilerine uygun çözümler sunduğunuzda, sadece daha etkili bir tasarım değil, aynı zamanda daha tatmin edici bir kullanıcı deneyimi elde edersiniz. Tasarım dünyasında başarılı olmak için bu adımları asla atlamayın; çünkü kullanıcılarınızı anlamak, başarılı tasarımların sırrıdır.
|
||||
|
||||
“Tasarım sadece nasıl göründüğü ya da nasıl hissettirdiği ile ilgili bir şey değildir. Tasarım nasıl çalıştığı ile ilgilidir.” — Steve Jobs
|
||||
> “Tasarım sadece nasıl göründüğü ya da nasıl hissettirdiği ile ilgili bir şey değildir. Tasarım nasıl çalıştığı ile ilgilidir.” — Steve Jobs
|
||||
|
||||
@@ -4,304 +4,201 @@ category: "Frontend"
|
||||
date: "2026-02-14"
|
||||
readTime: "11 min read"
|
||||
author: "Poyraz Avsever"
|
||||
excerpt: "Öncellikle herkese merhaba. Bildiğiniz gibi frontend dünyasında çeşitli frameworkler ve kütüphanelerle tanışmak her geliştiricinin geçtiği bir süreçtir. React, Vue ve Angular gi..."
|
||||
coverImage: "/news/design.svg"
|
||||
excerpt: "Bu yazida temel kavramlari, pratik ornekleri ve uygulayabileceginiz ipuclarini sade bir dille bulabilirsiniz."
|
||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*Dx04pr9plejiCcWI.png"
|
||||
---
|
||||
|
||||
Öncellikle herkese merhaba. Bildiğiniz gibi frontend dünyasında çeşitli frameworkler ve kütüphanelerle tanışmak her geliştiricinin geçtiği bir süreçtir. React, Vue ve Angular gibi devlerin arasına yeni bir oyuncu olarak giren Svelte, son dönemde popülerliğini artırdı. Peki, Svelte’i diğerlerinden ayıran temel farklar neler ve neden daha hızlı? Bu yazımda, Svelte’in yapısını, performans avantajlarını ve React ile Vue’ya karşı neden daha hızlı olduğunu inceleyelim.
|
||||
Frontend dünyasında React, Vue ve Angular gibi güçlü seçenekler var. Son yıllarda bu listeye güçlü bir alternatif olarak Svelte de eklendi. Peki Svelte'i farklı yapan ne ve neden çoğu senaryoda daha hızlı hissediliyor?
|
||||
|
||||
|
||||
## Svelte Nedir?
|
||||
|
||||
Svelte Nedir ve Nasıl Çalışır?
|
||||
Svelte, geleneksel anlamda sadece bir runtime framework değil; derleme (compile-time) odaklı bir yaklaşıma sahip. Uygulama çalışmadan önce bileşenleri optimize edip tarayıcıya daha sade JavaScript gönderir.
|
||||
|
||||
Svelte, 2016 yılında Rich Harris tarafından geliştirilmiş, modern web uygulamaları oluşturmak için kullanılan bir framework’tür. Ancak Svelte’i diğer frameworklerden ayıran temel fark, bir framework değil, bir compiler (derleyici) olmasıdır. Bu, Svelte’in çalışma zamanı kütüphanesi olmadan doğrudan tarayıcıda çalıştığı anlamına gelir.
|
||||
## Svelte'i Hızlı Yapan Unsurlar
|
||||
|
||||
React ve Vue, tarayıcıda bir sanal DOM (Virtual DOM) kullanarak bileşenleri yönetir. Herhangi bir değişiklik olduğunda, sanal DOM ile gerçek DOM karşılaştırılır ve güncellenir. Bu işlem, her ne kadar optimize edilse de, tarayıcı üzerinde ekstra bir yük oluşturur. Svelte ise sanal DOM kullanmaz. Bunun yerine, bileşenlerin oluşturulma anında, doğrudan etkin ve optimize edilmiş JavaScript kodu üretir. Bu da onlara göre minimal bşr hız dahi olsa avantaj kazandırır.
|
||||
Svelte’i Neden Daha Hızlı Yapan Unsurlar?
|
||||
- **Compile-time optimizasyon**: İşin büyük kısmı build aşamasında çözülür.
|
||||
- **Virtual DOM yok**: Ara katman maliyetini azaltır.
|
||||
- **Daha küçük bundle**: Runtime yükü azalır.
|
||||
- **Doğal reaktivite**: Basit state güncellemeleri için ek soyutlamalara daha az ihtiyaç duyulur.
|
||||
|
||||
Compile-time Optimizasyonlar
|
||||
Svelte’in en büyük avantajlarından biri, değişikliklerin compile-time’da optimize edilmesidir. Diğer frameworkler, tarayıcıda çalışma zamanı sırasında gerekli işlemleri yaparken, Svelte bu işlemleri geliştirme aşamasında yapar ve tarayıcıya doğrudan optimize edilmiş, minimal kod sunar.
|
||||
Sanal DOM Yok
|
||||
Svelte, sanal DOM kullanmadığı için performans kaybı yaşamaz. React ve Vue, değişiklikleri sanal DOM’da işleyip ardından gerçek DOM’a yansıtırken, Svelte bu adımı atlar ve direkt olarak gerçek DOM üzerinde çalışır. Bu da uygulamanın daha hızlı tepki vermesini sağlar.
|
||||
Daha Küçük Bundle Boyutları
|
||||
Svelte, framework kütüphanesini projeye dahil etmez. Bunun yerine, sadece bileşenlerde kullanılan kod derlenir ve çıktı dosyası oluşturulur. Bu sayede final bundle boyutu küçülür ve sayfa yükleme süreleri hızlanır.
|
||||
Reaktif Yapı
|
||||
Svelte, reaktiviteyi bir dil özelliği gibi ele alır. Bir değişkenin değerini güncellediğinizde, Svelte otomatik olarak bu değişkenin kullanıldığı bileşenleri yeniden render eder. Bu, React ve Vue’da kullanılan state management yapılarından daha hafif ve hızlıdır.
|
||||
## React ve Svelte Karşılaştırması
|
||||
|
||||
Svelte mi, React/Vue mu?
|
||||
### 1. State Yönetimi
|
||||
|
||||
Tabii ki de her framework’ün kendine has avantajları ve kullanım alanları vardır. React ve Vue, geniş topluluk desteği, zengin ekosistem ve olgunlaşmış bir yapıya sahiptir. Ancak performans, küçük boyutlu projeler ve basitlik öncelikli olduğunda, Svelte dikkat çeken bir seçenek haline gelir.
|
||||
React örneği:
|
||||
|
||||
Svelte, özellikle performansın kritik olduğu projelerde (örneğin düşük performanslı cihazlarda çalışacak uygulamalarda) önemli bir fark yaratabilir. Ayrıca, minimal yapısı sayesinde öğrenmesi de oldukça kolaydır. Bu yüzden yeni başlayanlar için de ideal bir tercih olabilir. Gelin örnek olarak react ve svelte yazımında ki farklara da göz atalım.
|
||||
```jsx
|
||||
import React, { useState } from "react";
|
||||
|
||||
|
||||
|
||||
React vs Svelte: Bileşen Oluşturma ve State Yönetimi
|
||||
React’ta Bir Bileşen ve State Yönetimi
|
||||
|
||||
React’ta bir bileşen oluşturmak ve state yönetmek için genellikle useState hook'u kullanılır. İşte basit bir sayaç bileşeni örneği:
|
||||
|
||||
// React'ta sayaç bileşeni
|
||||
import React, { useState } from 'react';
|
||||
function Counter() {
|
||||
const [count, setCount] = useState(0);
|
||||
return (
|
||||
|
||||
return (
|
||||
<div>
|
||||
<p>Count: {count}</p>
|
||||
<button onClick={() => setCount(count + 1)}>
|
||||
Increase
|
||||
</button>
|
||||
<button onClick={() => setCount(count + 1)}>Increase</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
export default Counter;
|
||||
```
|
||||
|
||||
Burada React’in useState hook'u ile state yönetimi sağlanır. onClick olayında state güncellenir ve bileşen yeniden render edilir. Peki bunu svelte ile nasıl yapıyoruz?
|
||||
Svelte’te Aynı Bileşen
|
||||
Svelte örneği:
|
||||
|
||||
Svelte’de aynı işlevselliği elde etmek çok daha basit ve doğrudan olur. State yönetimi doğrudan JavaScript değişkenleri üzerinden yapılır ve Svelte reaktif yapısı sayesinde değişiklikler otomatik olarak bileşenleri yeniden render eder:
|
||||
|
||||
<!-- Svelte'te sayaç bileşeni -->
|
||||
```svelte
|
||||
<script>
|
||||
let count = 0;
|
||||
</script>
|
||||
|
||||
<div>
|
||||
<p>Count: {count}</p>
|
||||
<button on:click={() => count += 1}>
|
||||
Increase
|
||||
</button>
|
||||
<button on:click={() => (count += 1)}>Increase</button>
|
||||
</div>
|
||||
```
|
||||
|
||||
Bu daha büyük projelerde dez avantaj yaratabilir fakat küçük çaplı projelerde sürecin hızlanmasına olanak tanır.
|
||||
React vs Svelte: Props Kullanımı
|
||||
React’ta Props Kullanımı
|
||||
### 2. Props Kullanımı
|
||||
|
||||
React’ta bir bileşene props geçirerek veri aktarımı şu şekilde yapılır:
|
||||
React:
|
||||
|
||||
// React'ta parent bileşen
|
||||
import React from 'react';
|
||||
import Greeting from './Greeting';
|
||||
|
||||
function App() {
|
||||
return <Greeting name="Svelte" />;
|
||||
}
|
||||
|
||||
export default App;
|
||||
|
||||
// React'ta child bileşen
|
||||
```jsx
|
||||
function Greeting({ name }) {
|
||||
return <p>Hello, {name}!</p>;
|
||||
}
|
||||
```
|
||||
|
||||
export default Greeting;
|
||||
Svelte:
|
||||
|
||||
Burada Greeting bileşenine props olarak name değerini geçiyoruz ve bu props'u child bileşende kullanıyoruz.
|
||||
Svelte’te Props Kullanımı
|
||||
|
||||
Svelte’de props kullanımı ise daha basit ve doğrudandır:
|
||||
|
||||
<!-- Svelte'te parent bileşen -->
|
||||
<script>
|
||||
import Greeting from './Greeting.svelte';
|
||||
</script>
|
||||
|
||||
<Greeting name="Svelte" />
|
||||
|
||||
<!-- Svelte'te child bileşen -->
|
||||
```svelte
|
||||
<script>
|
||||
export let name;
|
||||
</script>
|
||||
|
||||
<p>Hello, {name}!</p>
|
||||
```
|
||||
|
||||
Svelte’de bir değişkeni export ederek dışarıdan bileşene veri aktarılabilir. Bu, React'taki props yapısına karşılık gelir ve çok daha sade bir kullanım sunar. Aslında yine aynı yere varıyoruz. Daha komplike projelerde tercih edilmeyebilir.
|
||||
React vs Svelte: Form ve Event Yönetimi
|
||||
React’ta Form ve Event Yönetimi
|
||||
### 3. Form Yönetimi
|
||||
|
||||
React’ta formlarda state yönetimi ve event handling biraz daha karmaşık olabilir:
|
||||
React:
|
||||
|
||||
import React, { useState } from 'react';
|
||||
```jsx
|
||||
import React, { useState } from "react";
|
||||
|
||||
function Form() {
|
||||
const [inputValue, setInputValue] = useState('');
|
||||
|
||||
const handleChange = (e) => {
|
||||
setInputValue(e.target.value);
|
||||
};
|
||||
const [inputValue, setInputValue] = useState("");
|
||||
|
||||
return (
|
||||
<div>
|
||||
<input type="text" value={inputValue} onChange={handleChange} />
|
||||
<input
|
||||
type="text"
|
||||
value={inputValue}
|
||||
onChange={(e) => setInputValue(e.target.value)}
|
||||
/>
|
||||
<p>Input: {inputValue}</p>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
export default Form;
|
||||
|
||||
Her input değişikliğinde state güncellenir ve render tetiklenir.
|
||||
Svelte’te Form ve Event Yönetimi
|
||||
|
||||
Svelte’de form kontrolü ve event yönetimi ise çok daha basit:
|
||||
Svelte:
|
||||
|
||||
```svelte
|
||||
<script>
|
||||
let inputValue = '';
|
||||
let inputValue = "";
|
||||
</script>
|
||||
|
||||
<div>
|
||||
<input type="text" bind:value={inputValue} />
|
||||
<p>Input: {inputValue}</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
Svelte’de bind ifadesi ile bir input elemanını doğrudan bir değişkene bağlayabilirsiniz. Bu, iki yönlü veri bağlamayı (two-way binding) çok basit hale getirir. Gelin burada ki ana mantığı anladığımıza göre biraz daha Svelte’e odaklanalım ve Svelte’in özelliklerini daha derinlemesine inceleyelim.
|
||||
Svelte’de Lifecycle Metotları
|
||||
## Lifecycle Metotları
|
||||
|
||||
Svelte’de lifecycle metotları, bileşenlerin yaşam döngüsü içinde belirli anlarda çalıştırmak istediğimiz kodları tanımlamamıza olanak tanır. Svelte, bu amaçla birkaç temel fonksiyon sunar:
|
||||
Svelte tarafında en sık kullanılan lifecycle fonksiyonları:
|
||||
|
||||
onMount: Bileşen DOM'a yerleştirildiğinde çalışır.
|
||||
beforeUpdate: DOM güncellenmeden hemen önce çalışır.
|
||||
afterUpdate: DOM güncellendikten hemen sonra çalışır.
|
||||
onDestroy: Bileşen DOM'dan kaldırıldığında çalışır.
|
||||
- `onMount`
|
||||
- `beforeUpdate`
|
||||
- `afterUpdate`
|
||||
- `onDestroy`
|
||||
|
||||
onMount Örneği:
|
||||
|
||||
Svelte’de bir bileşenin DOM’a eklenmesiyle birlikte yapılacak işlemleri onMount fonksiyonu ile tanımlayabilirsiniz:
|
||||
`onMount` örneği:
|
||||
|
||||
```svelte
|
||||
<script>
|
||||
import { onMount } from 'svelte';
|
||||
import { onMount } from "svelte";
|
||||
|
||||
let data;
|
||||
|
||||
onMount(async () => {
|
||||
const res = await fetch('https://jsonplaceholder.typicode.com/todos/1');
|
||||
const res = await fetch("https://jsonplaceholder.typicode.com/todos/1");
|
||||
data = await res.json();
|
||||
});
|
||||
</script>
|
||||
|
||||
<div>
|
||||
{#if data}
|
||||
{#if data}
|
||||
<p>{data.title}</p>
|
||||
{/if}
|
||||
</div>
|
||||
{/if}
|
||||
```
|
||||
|
||||
Bu örnekte onMount, bileşen DOM’a yerleştiği anda bir API çağrısı yapar ve sonuçları ekranda görüntüler.
|
||||
Svelte’de Reaktivite
|
||||
## Reaktivite
|
||||
|
||||
Svelte’in en güçlü özelliklerinden biri reaktiviteyi doğal olarak ele almasıdır. Bir değişkenin değerinde bir değişiklik olduğunda, Svelte bu değişikliği otomatik olarak takip eder ve ilgili bileşeni yeniden render eder.
|
||||
|
||||
Svelte’de reaktiviteyi tetiklemek için sadece bir değişkenin değerini güncellemek yeterlidir. Reaktif ifadeler let anahtar kelimesiyle tanımlanır ve herhangi bir ek kod yazılmasına gerek kalmaz.
|
||||
|
||||
Reaktif İfadeler:
|
||||
Svelte'in en güçlü taraflarından biri, reaktif ifadeleri dil seviyesinde desteklemesi:
|
||||
|
||||
```svelte
|
||||
<script>
|
||||
let count = 0;
|
||||
let doubled;
|
||||
|
||||
// $: ifadesi, reaktif bir bloğu işaretler
|
||||
$: doubled = count * 2;
|
||||
</script>
|
||||
|
||||
<p>Count: {count}</p>
|
||||
<p>Doubled: {doubled}</p>
|
||||
<button on:click={() => count++}>Increase</button>
|
||||
```
|
||||
|
||||
Bu örnekte, count değişkeni her arttığında doubled reaktif olarak güncellenir ve bu değişiklik ekrana yansır.
|
||||
## Store Kullanımı
|
||||
|
||||
|
||||
Bileşenler arası state paylaşımı için `store` yapısı çok kullanışlıdır.
|
||||
|
||||
Svelte’de Store Kullanımı
|
||||
`store.js`:
|
||||
|
||||
Svelte, küçük projeler için bileşenler arası veri paylaşımı amacıyla oldukça basit bir state yönetim sistemi sunar. Bunun için store adı verilen bir yapı kullanılır. Svelte, 3 tür store sağlar: writable, readable ve derived store’lar.
|
||||
Writable Store Örneği:
|
||||
|
||||
Writable store, bileşenler arasında güncellenebilir bir veri paylaşımı sağlar. Aşağıda bir sayaç uygulaması için writable store kullanımını görebilirsiniz:
|
||||
|
||||
<!-- store.js -->
|
||||
import { writable } from 'svelte/store';
|
||||
```js
|
||||
import { writable } from "svelte/store";
|
||||
|
||||
export const count = writable(0);
|
||||
```
|
||||
|
||||
<!-- App.svelte -->
|
||||
`App.svelte`:
|
||||
|
||||
```svelte
|
||||
<script>
|
||||
import { count } from './store';
|
||||
import { count } from "./store";
|
||||
</script>
|
||||
|
||||
<p>Count: {$count}</p>
|
||||
<button on:click={() => count.update(n => n + 1)}>Increase</button>
|
||||
<button on:click={() => count.update((n) => n + 1)}>Increase</button>
|
||||
```
|
||||
|
||||
Store değerine erişmek için $ işaretini kullanarak reaktif bir bağlama yapabilirsiniz. Ayrıca, count.update() ile store değerini güncelleyebilirsiniz. Gördüğünüz gibi oldukça basit.
|
||||
SvelteKit: Modern Web Uygulamaları İçin Güçlü Bir Araç
|
||||
|
||||
|
||||
Svelte’in yanı sıra, SvelteKit de güçlü bir araç olarak ön plana çıkıyor. SvelteKit, Svelte’in üzerine inşa edilmiş bir framework’tür ve özellikle modern web uygulamaları geliştirmek için tasarlanmıştır. SSR (Sunucu Tarafı Rendering), statik site oluşturma, rotalama (routing) ve çok daha fazlasını kolayca entegre edebilmenizi sağlar.
|
||||
SvelteKit’in Temel Özellikleri:
|
||||
## SvelteKit Neden Önemli?
|
||||
|
||||
Sunucu Tarafı Rendering (SSR): SvelteKit, uygulamanın sunucu tarafında render edilmesine olanak tanır, bu da SEO dostu sayfalar ve hızlı ilk render süreleri anlamına gelir.
|
||||
Statik Site Üretimi: Dinamik verileri çekip statik HTML dosyaları oluşturmak için kullanılabilir. Bu, SvelteKit’i hem dinamik hem de statik siteler için mükemmel bir seçim haline getirir.
|
||||
API Route’ları: SvelteKit ile kendi API’larınızı oluşturabilirsiniz. Bu, tam anlamıyla bir full-stack uygulama geliştirmeyi mümkün kılar.
|
||||
SvelteKit, Svelte üzerine kurulu modern bir framework'tür. Özellikle şu konularda güçlüdür:
|
||||
|
||||
Svelte’in sunduğu sadelik, reaktivite ve performans avantajları ile özellikle küçük ve orta ölçekli projeler için harika bir çözüm sunar. Sonraki adım olarak SvelteKit kullanarak, daha geniş kapsamlı projelere yönelik işlevsellikler ekleyebilirsiniz.
|
||||
Sonuç
|
||||
- SSR (Server-Side Rendering)
|
||||
- Statik site üretimi
|
||||
- Dosya tabanlı routing
|
||||
- API endpoint tanımları
|
||||
|
||||
Svelte, modern web geliştirme dünyasında performans ve sadelik arayanlar için mükemmel bir çözüm sunuyor. React ve Vue gibi popüler framework’lere kıyasla daha basit bir yapıya sahiptir Svelte.
|
||||
Bu yapı, Svelte'i küçük projelerden ürün seviyesine taşımayı kolaylaştırır.
|
||||
|
||||
Svelte’in en büyük avantajlarından biri, öğrenmesi kolay ve reaktif yapısının doğal olarak sade olmasıdır. Bir değişkenin değerini güncellemek bile bileşenleri yeniden render etmek için yeterli olurken, lifecycle metodları ve store yönetimi de basit ve sezgiseldir. Ayrıca, animasyonlar ve geçiş efektleri gibi işlevler için de dahili destek sunarak, harici kütüphanelere olan ihtiyacı ortadan kaldırır.
|
||||
## Sonuç
|
||||
|
||||
Özellikle küçük ve performansın kritik olduğu projelerde, düşük bellek tüketimi ve hızlı çalışma süreleri sayesinde Svelte, dikkat çeken bir seçenek haline gelir. Ancak daha büyük projeler ve geniş ekosistem desteği gereken durumlarda React ve Vue gibi framework’ler hâlâ güçlü birer alternatif olabilir.
|
||||
Svelte, performans ve sadelik odaklı bir geliştirme deneyimi sunuyor. Küçük ve orta ölçekli projelerde çok hızlı sonuç verir; büyük projelerde ise SvelteKit ile birlikte oldukça güçlü bir seçenek haline gelir.
|
||||
|
||||
Svelte, hem yeni başlayanlar hem de deneyimli geliştiriciler için güçlü bir araç sunarken, performans ve basitlikten ödün vermeyen bir çözüm arayanların radarında olmayı hak ediyor. Gelin şimdi “Svelte’i nasıl daha derinlemesine öğrenebiliriz bir bakalım.”
|
||||
Kaynaklar
|
||||
## Kaynaklar
|
||||
|
||||
Svelte’i öğrenmek için birçok ücretsiz ve kaliteli kaynak bulunuyor. Aşağıda benim de kaynak olarak aldığım hem videolar hem de yazılar ile Svelte’i derinlemesine öğrenebilirsiniz.
|
||||
YouTube Videoları
|
||||
|
||||
Svelte Crash Course (Traversy Media)
|
||||
|
||||
Svelte Crash Course
|
||||
Bu video, Svelte’in temellerini anlamak ve basit bir proje oluşturmak için mükemmel bir başlangıç noktası. React ve Vue gibi popüler framework’lere aşina olanlar için Svelte’in farklılıkları net bir şekilde açıklanıyor.
|
||||
|
||||
2. Learn Svelte in 5 Minutes (Web Dev Simplified)
|
||||
|
||||
Learn Svelte in 5 Minutes
|
||||
Svelte’in temel yapısını hızlıca öğrenmek isteyenler için kısa ve etkili bir video.
|
||||
|
||||
3. SvelteKit Crash Course (Net Ninja)
|
||||
|
||||
SvelteKit Crash Course
|
||||
Svelte’in modern web uygulamaları için geliştirilmiş framework’ü olan SvelteKit’i detaylıca incelemek ve ilk projeni geliştirmek için bu video rehber olacaktır.
|
||||
|
||||
Yazılı Kaynaklar ve Makaleler
|
||||
|
||||
Svelte Resmi Dokümantasyon
|
||||
|
||||
Svelte Documentation
|
||||
Svelte’in dökümanyasyonu, framework’ün her yönünü detaylıca açıklayan, başlangıç seviyesinden ileri seviyeye kadar her geliştiriciye hitap eden kapsamlı bir kaynak. Dökümanyasyon okumayı seviyorsanız başka bir kaynağa ihtiyacınız kalacağını düşünmüyorum.
|
||||
|
||||
2. Svelte for Beginners: A Hands-On Guide (Smashing Magazine)
|
||||
|
||||
Svelte for Beginners
|
||||
Smashing Magazine’in hazırladığı bu rehber, Svelte ile çalışmaya başlamak isteyenler için adım adım bir yol haritası sunuyor. Kesinlikle göz atmalısınız.
|
||||
|
||||
3. Understanding Svelte Reactivity (Dev.to)
|
||||
|
||||
Understanding Svelte Reactivity
|
||||
Svelte’in reaktif yapısını derinlemesine anlamak isteyenler için harika bir makale. Reaktiviteyi diğer framework’lerle karşılaştırarak Svelte’in farkını anlatıyor.
|
||||
|
||||
4. Svelte vs React: What’s The Difference? (LogRocket Blog)
|
||||
|
||||
Svelte vs React
|
||||
Svelte ve React arasındaki farkları daha ayrıntılı bir şekilde incelemek için bu makale, framework’lerin avantajlarını ve kullanım alanlarını karşılaştırıyor. Ben de bu yazıda ki karşılaştırmalarımda kaynak olarak burayı kullandım.
|
||||
|
||||
Online Kurslar
|
||||
|
||||
Svelte.js — The Complete Guide (Udemy)
|
||||
|
||||
Svelte.js — The Complete Guide
|
||||
Udemy’de yer alan bu kapsamlı kurs, Svelte’in temellerini ve ileri düzey özelliklerini öğrenmek isteyen geliştiriciler için ideal.
|
||||
|
||||
2. Learn Svelte and Sapper from Scratch (Frontend Masters)
|
||||
|
||||
Learn Svelte from Scratch
|
||||
Frontend Masters tarafından sunulan bu kurs, Svelte ve onun eski framework’ü olan Sapper üzerinde yoğunlaşarak modern uygulama geliştirmeye odaklanıyor. Bakmanızı tavsiye ederim.
|
||||
- [Svelte Documentation](https://svelte.dev/docs)
|
||||
- [Svelte Tutorial](https://svelte.dev/tutorial)
|
||||
- [SvelteKit Documentation](https://kit.svelte.dev/docs)
|
||||
- [LogRocket - Svelte vs React](https://blog.logrocket.com/svelte-vs-react/)
|
||||
|
||||
|
||||
|
||||
@@ -4,123 +4,122 @@ category: "Frontend"
|
||||
date: "2026-02-10"
|
||||
readTime: "10 min read"
|
||||
author: "Poyraz Avsever"
|
||||
excerpt: "Tailwind CSS, son dönemde frontend geliştiricilerin gözdesi haline geldi. Klasik CSS yazımına göre daha oldukça hızlı ve esnek bir yapı sunması, özellikle hızlı prototipleme ve ..."
|
||||
excerpt: "Bu yazida temel kavramlari, pratik ornekleri ve uygulayabileceginiz ipuclarini sade bir dille bulabilirsiniz."
|
||||
coverImage: "/news/performance.svg"
|
||||
---
|
||||
|
||||
Tailwind CSS, son dönemde front-end geliştiricilerin gözdesi haline geldi. Klasik CSS yazımına göre daha oldukça hızlı ve esnek bir yapı sunması, özellikle hızlı prototipleme ve özelleştirilmiş tasarımlar oluşturma süreçlerinde büyük avantaj sağlıyor. Bu yazıda, Tailwind CSS ile nasıl daha hızlı ve verimli bir tasarım süreci yaratabileceğinizi adım adım ele alacağız. Her şeyden önce gelin “tailwind css nedir ve neden kullanmalıyız?” diye bir soralım.
|
||||
Tailwind CSS, son dönemde front-end geliştiriciler arasında çok popüler hale geldi. Klasik CSS yaklaşımına göre daha hızlı prototipleme imkanı sunması ve esnek yapısı, özellikle ürün geliştirme süreçlerinde ciddi zaman kazandırıyor.
|
||||
|
||||
|
||||
|
||||
Tailwind CSS Nedir ve Neden Kullanmalıyız?
|
||||
## Tailwind CSS Nedir?
|
||||
|
||||
Tailwind CSS, klasik CSS yazımında alışık olduğumuz “class tanımla, sonra stilleri yaz” yöntemine alternatif olarak ortaya çıkmış, utility-first (yardımcı sınıf temelli) bir CSS framework’ü. Yani, önceden tanımlanmış küçük stil sınıflarını doğrudan HTML elementlerine ekleyerek stil verebiliyorsun. Örneğin, bir buton için bg-blue-500, text-white, p-4 gibi sınıfları ekleyerek, doğrudan istediğin görünüme hızlıca ulaşabilirsin.
|
||||
Neden Tailwind Kullanmalıyız?
|
||||
Tailwind CSS, utility-first yaklaşımını benimseyen bir CSS framework'üdür. Yani özel class isimleri üretmek yerine, hazır utility class'ları doğrudan bileşen üzerinde kullanırsın.
|
||||
|
||||
1. Hızlı ve Kolay
|
||||
CSS de her yeni stil için bir class yazman gerekiyor. Örneğin, bir butonun arka plan rengi, yazı rengi ve padding gibi özelliklerini tanımlamak için stil dosyana şöyle bir kod yazıyorsun:,
|
||||
## Neden Tailwind CSS Kullanmalıyız?
|
||||
|
||||
### 1. Hızlı ve Kolay Stil Geliştirme
|
||||
|
||||
Klasik CSS ile:
|
||||
|
||||
```css
|
||||
.btn {
|
||||
background-color: #3490dc;
|
||||
color: #fff;
|
||||
padding: 1rem;
|
||||
}
|
||||
```
|
||||
|
||||
Tailwind de ise aynı butonu şu şekilde oluşturabilirsin:
|
||||
Tailwind ile:
|
||||
|
||||
<button class="bg-blue-500 text-white p-4">Click Me</button>h
|
||||
```html
|
||||
<button class="bg-blue-500 text-white p-4">Click Me</button>
|
||||
```
|
||||
|
||||
Yani, her şey HTML içerisinde çok daha hızlı bir şekilde yönetilebiliyor. Bu da stili hızlıca oluşturmanı ve üzerinde anında değişiklik yapmanı sağlıyor. Üstelik terimler daha basite indirgendiği için kafa karışıklığından da kurtuluyoruz.
|
||||
### 2. Daha Az CSS Karmaşası
|
||||
|
||||
2. CSS Dosyası Karmasından Kurtul
|
||||
Büyük projelerde CSS dosyaları büyüdükçe sınıf yönetimi zorlaşır. Tailwind ile stil kararları bileşen seviyesinde alınır; bu da dağınıklığı azaltır.
|
||||
|
||||
CSS’de büyük projelerde zamanla stil dosyaları karmaşık hale gelebilir. Sınıf isimlerini organize etmek ve tutarlı bir sistem oturtmak zor olabilir. Tailwind ile ise her stil bileşeni için yeniden sınıf yazmak yerine, utility sınıflarını kullanarak kod tekrarını ve karmaşayı azaltıyorsun. Yani, tek bir dosya içinde “hangi sınıf hangi stili uyguluyor” derdine girmiyorsun.
|
||||
|
||||
3. Responsive Tasarım Kolaylığı
|
||||
CSS de her ekran boyutu için ayrı media query yazman gerekiyor fakat Tailwind’de bu iş çok daha kolay. Örneğin:
|
||||
### 3. Responsive Tasarım Daha Basit
|
||||
|
||||
```html
|
||||
<div class="text-sm md:text-lg lg:text-xl">
|
||||
Responsive Metin
|
||||
</div>
|
||||
```
|
||||
|
||||
Bu kod, küçük ekranlarda text-sm, orta ekranlarda text-lg, büyük ekranlarda text-xl sınıflarını uygular. Media query yazmaya gerek yok. Bana kalırsa Tailwind’in sağladığı en büyük avantajlardan birisi de bu.
|
||||
Tailwind CSS’i Daha Verimli Kullanmanın Yolları
|
||||
Tek satırda farklı kırılımlar için tipografi kontrolü yapabilirsin.
|
||||
|
||||
Tailwind CSS’in gücünü tam anlamıyla kullanmak için bazı ipuçları işini hızlandırabilir ve kodunu daha temiz hale getirebilir:
|
||||
## Tailwind'i Daha Verimli Kullanma İpuçları
|
||||
|
||||
Config Dosyasını Özelleştir
|
||||
|
||||
Tailwind’in sunduğu yapı taşlarını kendi projen için optimize edebilirsin. tailwind.config.js dosyasını kullanarak renk paletlerini, fontları ve spacing değerlerini özelleştirmen, projende tutarlı bir tasarım sistemi oluşturmanı sağlar. Örneğin:
|
||||
### 1. `tailwind.config.js` Dosyasını Özelleştir
|
||||
|
||||
```js
|
||||
module.exports = {
|
||||
theme: {
|
||||
extend: {
|
||||
colors: {
|
||||
customBlue: '#1e3a8a',
|
||||
customBlue: "#1e3a8a",
|
||||
},
|
||||
spacing: {
|
||||
'128': '32rem',
|
||||
128: "32rem",
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
2. @apply Direktifini Kullan
|
||||
|
||||
Aynı stilleri tekrar tekrar yazmak yerine Tailwind’in @apply direktifini kullanarak ortak stilleri bir araya getiren sınıflar oluşturabilirsin. Böylece hem kodun daha temiz olur hem de yönetimi kolaylaşır. Örneği bir butonu projende onlarca defa kullanacaksan @applyile tanımlayabilirsin.
|
||||
### 2. `@apply` ile Tekrarları Azalt
|
||||
|
||||
```css
|
||||
.btn-primary {
|
||||
@apply bg-blue-500 text-white font-bold py-2 px-4 rounded;
|
||||
}
|
||||
```
|
||||
|
||||
3. PurgeCSS ile Dosya Boyutunu Küçült
|
||||
|
||||
Tailwind projelerde kullanılmayan stiller de oluşturur. Bu yüzden dosya boyutunu optimize etmek için üretim aşamasında purge özelliğini kullanarak kullanılmayan stilleri kaldırabilirsin. Bu, özellikle büyük projelerde performansı artırır.
|
||||
### 3. Üretimde Kullanılmayan Stilleri Temizle
|
||||
|
||||
```js
|
||||
module.exports = {
|
||||
purge: ['./src/**/*.html', './src/**/*.js']
|
||||
}
|
||||
purge: ["./src/**/*.html", "./src/**/*.js"],
|
||||
};
|
||||
```
|
||||
|
||||
4. Tailwind JIT Modunu Etkinleştir
|
||||
|
||||
Tailwind’in Just-In-Time (JIT) modunu kullanarak, yazdığın sınıfların anında oluşturulmasını ve CSS dosyasının minimum seviyede tutulmasını sağlayabilirsin. Bu mod, Tailwind’in en güncel ve dinamik şekilde çalışmasını sağlar.
|
||||
### 4. JIT Modunu Kullan
|
||||
|
||||
```js
|
||||
module.exports = {
|
||||
mode: 'jit'
|
||||
}
|
||||
mode: "jit",
|
||||
};
|
||||
```
|
||||
|
||||
5. Responsive Tasarımı Kolaylaştır
|
||||
|
||||
Tailwind ile responsive tasarımlar oluşturmak çok basittir. Sınıfların başına sm:, md:, lg: gibi prefix'ler ekleyerek farklı ekran boyutlarına göre stilleri kolayca tanımlayabilirsin. Bu, mobil uyumluluğu hızla sağlamanın en etkili yollarından biri. Web sitesini tasarlamaya başlarken mobil versiyonlardan başlarsan daha rahat edersin. Küçükten büyüğe
|
||||
### 5. Mobile-first Düşün
|
||||
|
||||
```html
|
||||
<div class="text-sm md:text-lg lg:text-xl">
|
||||
Responsive Metin
|
||||
</div>
|
||||
```
|
||||
|
||||
6. Tailwind Eklentilerini Keşfet
|
||||
Önce küçük ekranlardan başlayıp yukarı doğru ölçeklemek genelde daha temiz sonuç verir.
|
||||
|
||||
Tailwind’in ekosisteminde birçok faydalı eklenti mevcut. Özellikle form bileşenleri, tipografi veya animasyonlar için Tailwind eklentileri işini daha da kolaylaştırabilir. Örneğin, @tailwindcss/formseklentisi ile form stillerini güzelleştirebilirsin. @tailwind-scrollbareklentisi ile scrollbar’larını özelleştirebilirsin. İnternetten detaylı bir aramayla işine yarayanları bulabilir, projelerine kolay bir şekilde entegre edebilirsin.
|
||||
### 6. Eklenti Ekosisteminden Yararlan
|
||||
|
||||
- `@tailwindcss/forms`
|
||||
- `@tailwindcss/typography`
|
||||
- `tailwind-scrollbar`
|
||||
|
||||
Bu eklentilerle ortak UI ihtiyaçlarını daha hızlı çözebilirsin.
|
||||
|
||||
|
||||
|
||||
Bu ipuçlarıyla, Tailwind CSS’i daha verimli kullanabilir ve projelerinde daha temiz, düzenli bir kod yapısına ulaşabilirsin! Kendi projelerinde Tailwind’i kullanarak, hem zaman kazanmaya başlayacak hem de bu alan da daha özgür olacaksın. Bu yazıda sunduğum ipuçları ile Tailwind CSS’i daha verimli kullanabilir, projelerinde fark yaratabilirsin. Hemen dene, iş akışını nasıl dönüştürdüğünü gör!
|
||||
Başarılar ve keyifli kodlamalar!
|
||||
Kaynaklar
|
||||
## Sonuç
|
||||
|
||||
Tailwind CSS Resmi Dokümantasyonu
|
||||
Tailwind’in utility-first yapısına dair tüm detaylar ve kullanım örneklerini burada bulabilirsin:
|
||||
[https://tailwindcss.com/docs](https://tailwindcss.com/docs)
|
||||
Tailwind CSS Konfigürasyon Rehberi
|
||||
Tailwind’in tailwind.config.js dosyasını nasıl özelleştirebileceğin hakkında daha fazla bilgi için:
|
||||
[https://tailwindcss.com/docs/configuration](https://tailwindcss.com/docs/configuration)
|
||||
PurgeCSS ile Optimizasyon
|
||||
Tailwind ile kullanılan PurgeCSS hakkında detaylı rehber için:
|
||||
[https://tailwindcss.com/docs/optimizing-for-production](https://tailwindcss.com/docs/optimizing-for-production)
|
||||
Tailwind CSS Just-In-Time (JIT) Modu
|
||||
Tailwind JIT modunun nasıl etkinleştirileceği ve faydaları hakkında daha fazla bilgi:
|
||||
[https://tailwindcss.com/docs/just-in-time-mode](https://tailwindcss.com/docs/just-in-time-mode)
|
||||
Tailwind CSS Eklentileri
|
||||
Forms, Typography gibi eklentilerin nasıl kullanılacağına dair rehberler:
|
||||
[https://tailwindcss.com/docs/plugins](https://tailwindcss.com/docs/plugins)
|
||||
Tailwind CSS, doğru kullanıldığında hem hız hem de bakım kolaylığı sağlar. Özellikle hızlı iterasyon gereken projelerde, utility-first yaklaşımı ciddi avantaj sunar.
|
||||
|
||||
Bu kaynaklar, Tailwind CSS’i daha derinlemesine öğrenmek ve projelerinde en iyi şekilde kullanmak için faydalı olacaktır.
|
||||
## Kaynaklar
|
||||
|
||||
- [Tailwind CSS Dokümantasyon](https://tailwindcss.com/docs)
|
||||
- [Configuration](https://tailwindcss.com/docs/configuration)
|
||||
- [Optimizing for Production](https://tailwindcss.com/docs/optimizing-for-production)
|
||||
- [JIT Mode](https://tailwindcss.com/docs/just-in-time-mode)
|
||||
- [Plugins](https://tailwindcss.com/docs/plugins)
|
||||
|
||||
@@ -4,104 +4,117 @@ category: "UX"
|
||||
date: "2026-02-26"
|
||||
readTime: "12 min read"
|
||||
author: "Poyraz Avsever"
|
||||
excerpt: "UX Kullanıcı Deneyimi tasarımı, teknolojiyle etkileşime geçen herkesin deneyimini iyileştirmeye yönelik bir disiplin. Web siteleri, mobil uygulamalar ve dijital ürünlerin, kulla..."
|
||||
coverImage: "/news/design.svg"
|
||||
excerpt: "Bu yazida temel kavramlari, pratik ornekleri ve uygulayabileceginiz ipuclarini sade bir dille bulabilirsiniz."
|
||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*5OUFz00g3w5ee2lV.jpg"
|
||||
---
|
||||
|
||||
|
||||
|
||||
UX (Kullanıcı Deneyimi) tasarımı, teknolojiyle etkileşime geçen herkesin deneyimini iyileştirmeye yönelik bir disiplin. Web siteleri, mobil uygulamalar ve dijital ürünlerin, kullanıcının ihtiyaçlarını hızlı ve etkili bir şekilde karşılayacak şekilde tasarlanması gerekiyor. İyi bir UX tasarımı, sadece estetik değil, aynı zamanda işlevsellik ve kullanılabilirlik üzerine de yoğunlaşıyor. Bu yazıda, UX tasarımında dikkate alınması gereken temel ilkeleri keşfedeceğiz. Gelin başlayalım.
|
||||
1. Kullanıcı Merkezli Yaklaşım
|
||||
|
||||
|
||||
## UX Tasarımında Temel İlkeler
|
||||
|
||||
### Kullanıcı Merkezli Yaklaşım
|
||||
|
||||
UX tasarımında en önemli kural, tasarımın tamamen kullanıcıya odaklanmasıdır. Ürün ya da hizmeti kullanacak kişilerin ihtiyaçlarını, beklentilerini ve sorunlarını anlamadan iyi bir kullanıcı deneyimi sunmak imkansızdır. Kullanıcı araştırmaları, anketler ve testler ile kullanıcıların nelerden hoşlandığını ve hangi sorunlarla karşılaştıklarını anlamak bu süreçte kritik rol oynar. Örneğin bir tasarıma başlamadan önce hedef kitlenizle enpati kurun arkadaşlar. Onların yolculuğunu anlamaya çalışın ve ardından tasarıma başlayın.
|
||||
2. Basitlik ve Anlaşılırlık
|
||||
### Basitlik ve Anlaşılırlık
|
||||
|
||||
Basitlik, kullanıcıların hızlıca istedikleri sonuca ulaşmalarını sağlar. Karmaşık arayüzler, kafa karıştırıcı ikonlar ya da gereksiz adımlar kullanıcıyı yavaşlatır ve deneyimi kötüleştirir. İyi bir UX tasarımı, sadece ihtiyaç duyulan özellikleri ön plana çıkararak gereksiz detayları yok etmeli. Yine bir örnek verelim. Kullanıcının hangi işlemleri yerine getirmek istediğine odaklanın. Ve onları en kısa ve kolay yol ile nasıl sağlarım diye düşünün. Elbet bir kaç çıkış yolu bulacaksınız.
|
||||
3. Tutarlılık
|
||||
### Tutarlılık
|
||||
|
||||
Tutarlılık, kullanıcının arayüzü daha hızlı ve kolay öğrenmesini sağlar. Web sitenizde ya da uygulamanızda butonların, menülerin ve diğer öğelerin tutarlı bir şekilde yerleştirilmesi, kullanıcıya tanıdık bir deneyim sunar. Yani her ikonunuz farklı bir ikon pakettinden olmasın. Ayrıca, farklı sayfalarda aynı etkileşim kalıplarını uygulamak, kullanıcıların rahat bir şekilde gezinti yapmalarını sağlar. Yani elinizden geldiğince tasarımda renk, tipografi ve ikon kullanımlarını koruyarak kullanıcıya bütün halinde bir deneyim sunun. Aksi taktirde kullanıcıyı tasarımınıza yabancılaştırabilirsiniz. Bunu kim ister, değil mi?
|
||||
4. Erişilebilirlik
|
||||
### Erişilebilirlik
|
||||
|
||||
İyi bir UX tasarımı, herkes tarafından erişilebilir olmalıdır. Farklı yeteneklere sahip kullanıcıların da ürün ya da hizmetinizi kullanabileceğini düşünmek zorundasınız. Bu, renk körü kullanıcılara uygun renk kontrastları sağlamaktan, ekran okuyucularına uyumlu içerik sunmaya kadar geniş bir alanı kapsar. Bir de buradan örnek verelim. Tasarımda sürekli olarak erişilebilirlik kurallarını takip etmelisiniz. Aynı zamanda ttasarımınızı farklı kullanıcı grupları için test edin.
|
||||
5. Geri Bildirim ve Etkileşim
|
||||
### Geri Bildirim ve Etkileşim
|
||||
|
||||
Kullanıcıların yaptıkları her eylemde, ara yüzden bir geri bildirim beklerler. Bir butona tıklamak, formu doldurmak ya da bir işlemi başlatmak gibi eylemlerde ara yüzün kullanıcıyı bilgilendirmesi gerekir. Geri bildirimler, yapılan işlemin başarıyla tamamlandığını ya da bir hata olduğunu gösterir ve bu, kullanıcıya güven verir. Örneğin bir işlemde bekleme süresi varsa, yükleme animasyonu ile kullanıcının beklemesi gerektiğini, arka planda bir işlem olduğunu söylemeniz gerekir. Aksi takdirke kullanıcı ne olduğunu anlayamaz. Ya da bir buton düşünelim. Bu buton kullanıcının gönderi paylaşmasını sağlayan “gönder” butonu olsun. Eğer siz kullanıcı gönder butonuna bastığı zaman bir geribildirim vermezseniz kullanıcı çalışmadığını zannedip defalarca kez butona basabilir. Bu ve bunlar gibi onlarca senaryodan kaçınmak için geri bildirimleri unutmayın!
|
||||
|
||||
|
||||
|
||||
İyi bir UX tasarımının temeli, kullanıcıyı merkeze alarak basit, tutarlı, erişilebilir ve etkileşimli bir deneyim sunmaktır. Bu ilkeleri uygulamak, ürününüzün sadece iyi görünmesini değil, aynı zamanda kullanılabilir ve kullanıcı dostu olmasını sağlar. Unutmayın, başarılı bir UX tasarımı, sadece tasarımın görselliğiyle değil, kullanıcının deneyimiyle ilgilidir. Gelin şimdi biraz daha spesifik konulara inelim.
|
||||
Renk Psikolojisi ve UX Tasarımı
|
||||
|
||||
## Renk Psikolojisi ve UX Tasarımı
|
||||
|
||||
|
||||
|
||||
Renkler, kullanıcıların bir ara yüzle nasıl etkileşime gireceğini ve onu nasıl algılayacağını doğrudan etkileyen güçlü bir araçtır. Renk psikolojisi, insanların renkler aracılığıyla duygusal tepkiler verdiğini gösterir. Bu tepkiler kullanıcı deneyimini önemli ölçüde etkileyebilir. İyi bir UX tasarımcısı, renklerin bu etkisini anlamalı ve kullanıcının hislerini, kararlarını ve genel deneyimini olumlu yönde etkileyen renk paletleri seçmelidir. Bakalım bu renkler içimizde nasıl hisler uyandırıyor?
|
||||
Kırmızı: Dikkat Çekici ve Uyarıcı
|
||||
|
||||
### Kırmızı: Dikkat Çekici ve Uyarıcı
|
||||
|
||||
Kırmızı renk, genellikle uyarı ya da aciliyet ifade eden durumlarda kullanılır. Hızlı dikkat çekmek, önemli bir eylemi öne çıkarmak ya da tehlike belirten bir uyarı vermek için idealdir. Ancak aşırı kullanımda kullanıcıyı rahatsız edebilir, bu yüzden stratejik olarak kullanılması önemlidir. Örneğin ödeme işlemi gibi kritik adımları vurgulmak ya da hata mesajlarını göstermek için kırmızıyı kullanabilirsin.
|
||||
Yeşil: Doğallık ve Güven
|
||||
### Yeşil: Doğallık ve Güven
|
||||
|
||||
Yeşil, genellikle doğa, huzur ve güven ile ilişkilendirilir. Aynı zamanda başarılı işlemleri işaret etmek için de yaygın olarak kullanılır. Yeşil renk, kullanıcıya güven ve rahatlık hissi verir, bu yüzden olumlu mesajlar ve işlemlerde tercih edilebilir. Örneğin “tamamlandı” mesajlarında yeşili kullanarak kullanıcıyı pozitif yönde bilgilendirebilirsiniz.
|
||||
Mavi: Güven ve Profesyonellik
|
||||
### Mavi: Güven ve Profesyonellik
|
||||
|
||||
Mavi, güven ve sadakati temsil eden bir renktir. Bu nedenle, bankacılık veya kurumsal siteler gibi güvenin önemli olduğu alanlarda sıklıkla tercih edilir. Aynı zamanda sakinlik ve dinginlik hissi verdiği için kullanıcının yoğun bilgiyle karşılaştığı ara yüzlerde dengeleyici bir unsur olabilir. Örneğin güvenlik işlemlerini, bilgilendirme mesajlarını, ve ya ana butonları vurgulamak için maviyi tercih edebilirsiniz.
|
||||
Sarı: Enerji ve Dikkat
|
||||
### Sarı: Enerji ve Dikkat
|
||||
|
||||
Sarı renk, genellikle enerji, neşe ve iyimserlik hissi uyandırır. Kullanıcının dikkatini çekmek için kullanılabilecek güçlü bir renktir. Ancak çok parlak sarı tonları dikkat dağınıklığına neden olabilir, bu yüzden dikkatli ve dengeli kullanılması gerekir.
|
||||
Turuncu: Canlılık ve Hareket
|
||||
### Turuncu: Canlılık ve Hareket
|
||||
|
||||
Turuncu renk, enerjik ve hareketli bir his uyandırır. Kırmızı gibi dikkat çekici olmasına rağmen, daha sıcak ve davetkar bir ton sunar. Kullanıcının harekete geçmesi gerektiği durumlarda turuncu, iyi bir yönlendirme aracı olabilir. Örneğin kampanya mesajları gibi teşvik edici öğelerde kullanabilirsiniz.
|
||||
|
||||
Renklerin Tutarlı Kullanımı
|
||||
### Renklerin Tutarlı Kullanımı
|
||||
Renklerin tutarlı bir şekilde kullanılması da kullanıcı deneyimi için önemlidir. Aynı renklerin sürekli olarak benzer işlevler için kullanılması, kullanıcıya bir tür zihinsel model oluşturur ve ara yüzde daha kolay gezinmesini sağlar.
|
||||
|
||||
Renklerin daha detaylı incelemek için internete renk teorisi yazarak yalnızca bu konu üzerinde yoğunlaşmış onlarca yazı ve video bulabilirsiniz. Ben UX tasarım üzerinde büyük bir rol oynayan renkleri detaylıca öğrenmenizi tavsiye ediyorum.
|
||||
|
||||
Kullanıcı Alışkanlıkları ve Davranış Kalıpları
|
||||
## Kullanıcı Alışkanlıkları ve Davranış Kalıpları
|
||||
|
||||
|
||||
|
||||
Kullanıcı alışkanlıkları ve davranış kalıpları, başarılı bir UX tasarımının temel taşlarından biridir. İnsanlar dijital ürünlerle etkileşim kurarken belirli bir düzen ve beklenti oluşturur, bu düzen tasarımcıların rehberi olmalıdır. Kullanıcıların nasıl düşündüğünü, nasıl hareket ettiğini ve ürünlerle nasıl etkileşime geçtiğini anlamak, UX tasarımında daha etkili çözümler sunmanı sağlar.
|
||||
F-Tarama Deseni
|
||||
|
||||
## F-Tarama Deseni
|
||||
|
||||
|
||||
|
||||
Kullanıcılar, genellikle bir sayfayı yukarıdan aşağıya ve soldan sağa doğru tararlar. Bu tarama davranışı, “F-tarama deseni” olarak bilinir ve birçok web sitesinde yaygın bir kullanıcı alışkanlığıdır. Kullanıcılar, ilk olarak sayfanın üst kısmına (başlık ve menü), ardından sol tarafa ve sayfanın en önemli kısımlarına dikkat ederler. Bu, bilgiyi en etkili şekilde sunmak ve kullanıcıların dikkatini çekmek için kullanabileceğiniz bir tasarım stratejisidir. Örneğin en önemli içerikleri ve eylemleri (CTA) sayfanın üst kısmında ve sol tarafa yakın konumlandırarak kullanıcıları doğru yönlendirebilirisiniz.
|
||||
Zihinsel Modeller ve Beklentiler
|
||||
|
||||
## Zihinsel Modeller ve Beklentiler
|
||||
|
||||
Kullanıcılar, daha önce deneyimledikleri benzer sistemlere dayanarak zihinsel modeller oluştururlar. Örneğin, bir e-ticaret sitesinde “sepet” ikonunu görmek, kullanıcının bir ürünü alışverişe ekleyebileceğini gösterir. Bu tür zihinsel modeller, kullanıcının ürününüzü nasıl kullanacağını ve ne bekleyeceğini tahmin eder. En basit tabirle kullanıcıların alışık olduğu ve rahat ettikleri kalıpları göz önünde bulundurarak, tanıdık ikonlar, yapılandırmalar ve etkileşimlerle tasarımınızı destekleyin.
|
||||
Bilgilere Hızlı Ulaşma İsteği
|
||||
|
||||
## Bilgilere Hızlı Ulaşma İsteği
|
||||
|
||||
Kullanıcılar dijital ortamda hızlı bilgi edinme eğilimindedir. Özellikle mobil cihazlarda gezinirken, bilgiye çabuk ve zahmetsiz bir şekilde ulaşmak isterler. Karmaşık bir navigasyon, yavaş yüklenen sayfalar ya da çok fazla tıklama gerektiren işlemler, kullanıcıyı yavaşlatır ve bu da memnuniyetsizlik yaratır. Peki ne yapmalısınız? Ara yüzünüzdeki gereksiz adımları ve karmaşıklığı ortadan kaldırmalı, kullanıcının ihtiyaç duyduğu bilgilere hızlıca ulaşmasını sağlayan basit ve sade bir yapı oluşturmalısınız.
|
||||
Eylem ve Sonuç İlişkisi
|
||||
|
||||
## Eylem ve Sonuç İlişkisi
|
||||
|
||||
Kullanıcılar, yaptıkları eylemlerin sonucunu hemen görmek isterler. Örneğin, bir form doldurulduğunda “gönder” butonuna basıldığında hemen bir geri bildirim beklerler. Eğer bir eylem gerçekleşmezse ya da geri bildirim gecikirse, kullanıcılar karışıklık ya da hayal kırıklığı yaşayabilirler. Kullanıcıların yaptıkları işlemlerin sonucunu anında bildiren geri bildirim mekanizmaları (yükleme animasyonları, başarı/hata mesajları) ekleyerek kullanıcıyı her aşamada bilgilendirin.
|
||||
|
||||
|
||||
|
||||
Kullanıcıların dijital ürünlerle etkileşim kurarken geliştirdiği alışkanlıkları ve davranış kalıplarını anlamak, onların beklentilerini karşılayan etkili UX tasarımları oluşturmanın anahtarıdır. Kullanıcı deneyimini geliştirmek için F-tarama deseni, zihinsel modeller ve hızlı bilgi edinme eğilimini göz önünde bulundurmalısın. Bu tür alışkanlıkları ve davranışları dikkate alan bir tasarım, kullanıcıyı ürünle daha uyumlu bir şekilde buluşturur.
|
||||
Duygusal Tasarım (Emotional Design)
|
||||
|
||||
## Duygusal Tasarım (Emotional Design)
|
||||
|
||||
|
||||
|
||||
Kullanıcı deneyimi (UX) tasarımında, duygusal tasarım, sadece işlevselliği değil, aynı zamanda kullanıcıların hislerini ve duygusal tepkilerini de dikkate alır. İnsanlar yalnızca mantıksal kararlar vermezler; duyguları da karar alma süreçlerinde önemli bir rol oynar. Bu nedenle, tasarımın hem kullanışlı hem de duygusal bir bağ kurabilen bir yapıya sahip olması, kullanıcıların ürünle daha derin ve kalıcı bir etkileşim kurmalarını sağlar.
|
||||
Duyguların UX’teki Rolü
|
||||
|
||||
## Duyguların UX’teki Rolü
|
||||
|
||||
Kullanıcıların bir ürünle olan etkileşimleri sırasında hissettikleri duygular, ürün hakkındaki genel düşüncelerini ve bağlılıklarını doğrudan etkiler. İyi bir duygusal tasarım, kullanıcıyı mutlu edebilir, güvende hissettirebilir veya onu motive edebilir. Öte yandan, kötü bir duygusal deneyim, kullanıcıyı hayal kırıklığına uğratabilir ve bu da üründen vazgeçmesine neden olabilir. Ne yapacağız peki? Kullanıcının belirli bir noktada nasıl hissetmesini istediğinizi düşünün. Örneğin, bir satın alma işlemi sırasında kullanıcıya güven vermek için samimi ve açık bir dil kullanabilir, işlemin sonunda “Teşekkürler, harika bir seçim yaptınız!” gibi mesajlarla kullanıcıyı memnun edebilirsiniz.
|
||||
Norman’ın Duygusal Tasarım Teorisi
|
||||
|
||||
## Norman’ın Duygusal Tasarım Teorisi
|
||||
|
||||
Gelin üst tarafta ki fotoğrafın ne olduğuna bakalım. Duygusal tasarım teorisinin öncülerinden olan Don Norman, insanların ürünlerle olan etkileşimlerinde üç farklı düzeyde tepki verdiklerini öne sürer: içgüdüsel (visceral), davranışsal (behavioral) ve yansıtıcı (reflective) tepkiler.
|
||||
|
||||
İçgüdüsel Düzey (Visceral): Kullanıcının ilk bakışta verdiği tepkidir. Ürünün görünüşü, renkleri ve şekli kullanıcıda hızlı bir duygusal tepki uyandırır. Tasarımın estetiği ve görsel unsurları bu aşamada önemlidir.
|
||||
Davranışsal Düzey (Behavioral): Ürünün kullanım kolaylığı ve işlevselliği ile ilgilidir. Kullanıcı, ürünü kullanırken ne kadar rahat hissettiğini değerlendirir. Bu, kullanıcının arayüzde gezinirken ne kadar rahat olduğuna ve ürünün işlevselliğine dayanır.
|
||||
Yansıtıcı Düzey (Reflective): Kullanıcının ürünü kullandıktan sonra verdiği bilinçli tepkiyi içerir. Kullanıcı, ürün hakkında ne düşündüğünü ve nasıl hissettiğini sorgular. Bu aşamada, kullanıcı ürünü bir bütün olarak değerlendirir ve bu ürünle uzun vadeli bir bağ kurup kurmayacağını belirler.
|
||||
- İçgüdüsel Düzey (Visceral): Kullanıcının ilk bakışta verdiği tepkidir. Ürünün görünüşü, renkleri ve şekli kullanıcıda hızlı bir duygusal tepki uyandırır. Tasarımın estetiği ve görsel unsurları bu aşamada önemlidir.
|
||||
- Davranışsal Düzey (Behavioral): Ürünün kullanım kolaylığı ve işlevselliği ile ilgilidir. Kullanıcı, ürünü kullanırken ne kadar rahat hissettiğini değerlendirir. Bu, kullanıcının arayüzde gezinirken ne kadar rahat olduğuna ve ürünün işlevselliğine dayanır.
|
||||
- Yansıtıcı Düzey (Reflective): Kullanıcının ürünü kullandıktan sonra verdiği bilinçli tepkiyi içerir. Kullanıcı, ürün hakkında ne düşündüğünü ve nasıl hissettiğini sorgular. Bu aşamada, kullanıcı ürünü bir bütün olarak değerlendirir ve bu ürünle uzun vadeli bir bağ kurup kurmayacağını belirler.
|
||||
|
||||
Öneri: Tasarımınızın bu üç düzeyde de kullanıcıya hitap ettiğinden emin olun. Görsel açıdan etkileyici, işlevsel açıdan kullanıcı dostu ve genel olarak pozitif bir deneyim sunan bir ara yüz oluşturun.
|
||||
|
||||
|
||||
|
||||
Görsel ve Metinsel İletişimin Duygusal Etkisi
|
||||
## Görsel ve Metinsel İletişimin Duygusal Etkisi
|
||||
|
||||
Görseller ve metinler, kullanıcıda duygusal bir etki yaratmanın en güçlü yollarından biridir. Renkler, yazı tipleri, ikonlar ve görseller kullanıcının duygusal tepkilerini şekillendirir. Aynı zamanda, kullanılan dil de kullanıcıyla duygusal bir bağ kurmanın bir başka önemli aracıdır. Dostane ve samimi bir dil, kullanıcının kendini daha rahat ve güvende hissetmesini sağlar. Yine birkaç tavsiye vermek istiyorum. Tasarımınızda ilham verici, güven veren ya da eğlenceli bir dil kullanarak kullanıcıyı daha iyi hissettirebilirsiniz. Ayrıca görsellerde insan yüzleri, gülen ifadeler gibi pozitif imgeler kullanarak kullanıcıların daha samimi bir bağ kurmasını sağlayabilirsiniz.
|
||||
Sonuç Olarak
|
||||
|
||||
## Sonuç Olarak
|
||||
|
||||
Kullanıcı deneyimi (UX) tasarımı, sadece bir ürünün işlevsel olmasını sağlamakla kalmaz; kullanıcıların ihtiyaçlarını anlamak, onların alışkanlıklarına ve duygusal tepkilerine hitap eden etkili çözümler sunmayı da içerir. Bu süreçte renklerin psikolojik etkisinden kullanıcı davranış kalıplarına, zihinsel modellerden duygusal tasarıma kadar pek çok unsuru göz önünde bulundurmak gerekir.
|
||||
|
||||
@@ -109,6 +122,6 @@ Başarılı bir UX tasarımı, kullanıcıyı merkeze alarak onların hedeflerin
|
||||
|
||||
Unutma, iyi bir kullanıcı deneyimi tasarımı, sadece bir ürünün kullanılabilirliğini artırmaz, aynı zamanda kullanıcıların o ürünü sevmelerini ve ona bağlı kalmalarını sağlar.
|
||||
|
||||
Tasarım sadece bir iş değil, bir hikaye anlatmaktır. Bu hikayede kullanıcıyı başrole koyduğun sürece başarıya ulaşman kaçınılmazdır.
|
||||
> Tasarım sadece bir iş değil, bir hikaye anlatmaktır. Bu hikayede kullanıcıyı başrole koyduğun sürece başarıya ulaşman kaçınılmazdır.
|
||||
|
||||
Okuduğunuz için teşekkür ederim. İyi tasarımlar!
|
||||
|
||||
Reference in New Issue
Block a user