TypeScript projelerinizde opsiyonel \u00f6zellikler i\u00e7in s\u0131k\u00e7a kulland\u0131\u011f\u0131m\u0131z ‘?’ i\u015faretinin, zamanla beklenmedik hatalara ve karma\u015f\u0131k kodlara yol a\u00e7abilece\u011fini biliyor muydunuz? Bu makalede, ‘?’ kullan\u0131m\u0131n\u0131n neden riskli olabilece\u011fini derinlemesine inceleyecek, TypeScript’in g\u00fc\u00e7l\u00fc Utility Tiplerinden biri olan TypeScript’e yeni ba\u015flayanlar veya h\u0131zl\u0131 prototipleme yapanlar i\u00e7in ‘?’ operat\u00f6r\u00fc cazip bir kolayl\u0131k sunar. Bir \u00f6zelli\u011fin iste\u011fe ba\u011fl\u0131 oldu\u011funu belirtmek, \u00f6zellikle dinamik veri yap\u0131lar\u0131yla veya hen\u00fcz tam olarak olgunla\u015fmam\u0131\u015f API’lerle \u00e7al\u0131\u015f\u0131rken olduk\u00e7a pratik g\u00f6r\u00fcn\u00fcr. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n telefon numaras\u0131n\u0131n her zaman mevcut olmayabilece\u011fini d\u00fc\u015f\u00fcnelim. Bu durumda, <\/code><\/p>\n Ancak, bu kolayl\u0131\u011f\u0131n ard\u0131nda yatan gizli riskler, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k uygulamalarda zamanla ortaya \u00e7\u0131kabilir. Opsiyonel olarak i\u015faretledi\u011fimiz bir alan, kodun farkl\u0131 yerlerinde kullan\u0131ld\u0131\u011f\u0131nda Diyelim ki bir fonksiyon, <\/code><\/p>\n Bu \u00f6rnekte Ayr\u0131ca, Uzman \u0130pucu: Her '?' kullan\u0131m\u0131nda kendinize \"Bu alan ger\u00e7ekten her zaman opsiyonel mi, yoksa belirli bir ba\u011flamda m\u0131 opsiyonel olmal\u0131?\" diye sorun. Cevap ikincisiyse, muhtemelen yeni bir tip t\u00fcretme zaman\u0131 gelmi\u015ftir.<\/p>\n<\/blockquote>\n TypeScript, sadece statik tip denetimi sa\u011flamakla kalmaz, ayn\u0131 zamanda mevcut tiplerden yeni tipler t\u00fcretme konusunda da inan\u0131lmaz bir esneklik sunar. \u0130\u015fte bu noktada \"Utility Tipler\" devreye girer. Utility tipleri, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, mevcut tipleri belirli bir ihtiyaca g\u00f6re d\u00f6n\u00fc\u015ft\u00fcrmemize, de\u011fi\u015ftirmemize veya onlardan yeni tipler t\u00fcretmemize yarayan kullan\u0131\u015fl\u0131 ara\u00e7lard\u0131r. Bunlar, TypeScript'in g\u00fcc\u00fcn\u00fc tam anlam\u0131yla kullanmam\u0131z\u0131 sa\u011flayan y\u00fcksek seviyeli meta-programlama yetenekleri olarak d\u00fc\u015f\u00fcn\u00fclebilir.<\/p>\n Peki neden bu kadar \u00f6nemliler? Temel bir tip tan\u0131mlad\u0131ktan sonra, bu tipi farkl\u0131 senaryolarda k\u00fc\u00e7\u00fck de\u011fi\u015fikliklerle kullanma ihtiyac\u0131 s\u0131k\u00e7a do\u011far. \u00d6rne\u011fin, bir veritaban\u0131 kayd\u0131 i\u00e7in tam bir tipiniz varken, bu kayd\u0131n sadece belirli alanlar\u0131n\u0131 i\u00e7eren bir \"g\u00f6r\u00fcnt\u00fcleme\" tipi veya yeni bir kay\u0131t olu\u015ftururken ID alan\u0131 olmayan bir \"olu\u015fturma\" tipi isteyebilirsiniz. Bu t\u00fcr durumlar\u0131 her seferinde ba\u015ftan manuel olarak tan\u0131mlamak, hem zaman al\u0131c\u0131d\u0131r hem de hata yapma potansiyelini art\u0131r\u0131r. \u0130\u015fte Utility tipleri bu tekrarl\u0131l\u0131\u011f\u0131 ortadan kald\u0131r\u0131r ve kod taban\u0131n\u0131z\u0131n daha DRY (Don't Repeat Yourself - Kendini Tekrarlama) olmas\u0131n\u0131 sa\u011flar.<\/p>\n TypeScript'in sa\u011flad\u0131\u011f\u0131 baz\u0131 yayg\u0131n Utility Tipleri \u015funlard\u0131r:<\/p>\n Bu tiplerin her biri, belirli bir ihtiyaca y\u00f6nelik olarak tasarlanm\u0131\u015ft\u0131r ve birlikte kullan\u0131ld\u0131klar\u0131nda \u00e7ok g\u00fc\u00e7l\u00fc kombinasyonlar olu\u015fturabilirler. \u00d6rne\u011fin, bir API iste\u011fi i\u00e7in sadece belirli alanlar\u0131 g\u00f6ndermeniz gerekti\u011finde Bu makalede \u00f6zellikle odaklanaca\u011f\u0131m\u0131z TypeScript'in Utility Tipleri aras\u0131nda \u00f6ne \u00e7\u0131kan Temel sentaks\u0131 olduk\u00e7a basittir:<\/p>\n <\/code><\/p>\n Burada:<\/p>\n Gelin, basit bir \u00f6rnekle <\/code><\/p>\n Bu <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte Sonu\u00e7 olarak, Modern web uygulamalar\u0131nda, backend API'lerinden gelen veriler genellikle frontend'de do\u011frudan kullan\u0131landan \u00e7ok daha fazlas\u0131n\u0131 i\u00e7erir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n veritaban\u0131 kayd\u0131, g\u00fcvenlik hashi, i\u00e7 sistem zaman damgalar\u0131, hatta di\u011fer hassas ili\u015fkilendirmeler gibi front-end i\u00e7in gereksiz veya tehlikeli olabilecek bilgileri bar\u0131nd\u0131rabilir. Bu t\u00fcr verilerin, uygulaman\u0131z\u0131n farkl\u0131 katmanlar\u0131 aras\u0131nda uygun filtreleme yap\u0131lmadan do\u011frudan aktar\u0131lmas\u0131, g\u00fcvenlik a\u00e7\u0131klar\u0131 yaratabilece\u011fi gibi, gereksiz yere b\u00fcy\u00fck veri y\u00fcklerinin ta\u015f\u0131nmas\u0131na da neden olabilir.<\/p>\n Bu senaryoyu somutla\u015ft\u0131ral\u0131m: Bir e-ticaret uygulamas\u0131nda \"\u00dcr\u00fcn\" objemiz var. Backend taraf\u0131nda bu \u00fcr\u00fcn\u00fcn tam tipi \u015f\u00f6yle tan\u0131mlanm\u0131\u015f olsun:<\/p>\n <\/code><\/p>\n Bu Eskiden bu t\u00fcr durumlar\u0131 y\u00f6netmek i\u00e7in iki yayg\u0131n yakla\u015f\u0131m vard\u0131:<\/p>\n <\/code><\/p>\n Bu yakla\u015f\u0131m\u0131n avantajlar\u0131 \u015funlard\u0131r:<\/p>\n Bu vaka analizi, TypeScript'in iki \u00f6nemli Utility Tipi olan \u00d6ncelikle <\/code><\/p>\n \u00d6rnek:<\/p>\n <\/code><\/p>\n Peki, Hangi durumlarda hangisini se\u00e7ece\u011finize karar verirken a\u015fa\u011f\u0131daki basit kural\u0131 d\u00fc\u015f\u00fcnebilirsiniz:<\/p>\n \u00d6rne\u011fin, <\/code><\/p>\n Her iki Utility Tipi de TypeScript'in tip sistemini daha esnek ve g\u00fc\u00e7l\u00fc hale getirir. Do\u011fru yerde do\u011fru arac\u0131 se\u00e7mek, kodunuzun hem okunabilirli\u011fini hem de bak\u0131m kolayl\u0131\u011f\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131racakt\u0131r.<\/p>\n \u00d6ncelikle, temel bir <\/code><\/p>\n Yeni bir g\u00f6rev olu\u015ftururken, <\/code><\/p>\n Burada, \u00f6nce Bazen bir objeden baz\u0131 alanlar\u0131 \u00e7\u0131karmak isterken, kalan t\u00fcm alanlar\u0131n mutlaka doldurulmu\u015f olmas\u0131n\u0131 isteyebiliriz. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n profilini g\u00fcncellerken <\/code><\/p>\n Burada, Bazen \u00e7ok spesifik bir ihtiyaca y\u00f6nelik tip olu\u015fturman\u0131z gerekebilir. \u00d6rne\u011fin, bir objeden belirli alanlar\u0131 \u00e7\u0131kar\u0131p, kalanlardan da sadece belirli bir alt k\u00fcmeyi se\u00e7mek isteyebilirsiniz. Bu senaryo biraz nadir olsa da, karma\u015f\u0131k durumlarda esneklik sa\u011flar:<\/p>\nOmit<\/code> ile daha g\u00fcvenli, okunabilir ve bak\u0131m\u0131 kolay kod nas\u0131l yaz\u0131laca\u011f\u0131n\u0131 ad\u0131m ad\u0131m \u00f6\u011frenece\u011fiz. Gelin, tip g\u00fcvenli\u011fini bir sonraki seviyeye ta\u015f\u0131yarak geli\u015ftirici deneyiminizi nas\u0131l iyile\u015ftirebilece\u011finizi ke\u015ffedelim.<\/p>\ntelefonNumarasi?: string;<\/code> \u015feklinde bir tan\u0131m yapmak ilk bak\u0131\u015fta mant\u0131kl\u0131d\u0131r.<\/p>\n\ninterface Kullanici {\n id: string;\n ad: string;\n soyad: string;\n email: string;\n telefonNumarasi?: string; \/\/ Opsiyonel alan\n}\n\nconst kullanici1: Kullanici = {\n id: \"1\",\n ad: \"Can\",\n soyad: \"Y\u0131lmaz\",\n email: \"can@example.com\",\n};\n\nconst kullanici2: Kullanici = {\n id: \"2\",\n ad: \"Ay\u015fe\",\n soyad: \"Demir\",\n email: \"ayse@example.com\",\n telefonNumarasi: \"5551234567\",\n};\n\n<\/pre>\nundefined<\/code> de\u011ferine sahip olabilir. TypeScript, derleme zaman\u0131nda bu potansiyel undefined<\/code> durumunu bize hat\u0131rlatsa da, geli\u015ftiriciler genellikle bu uyar\u0131lar\u0131 ?.<\/code> (opsiyonel zincirleme) veya !<\/code> (kesin atama onay\u0131) gibi operat\u00f6rlerle ge\u00e7i\u015ftirmeyi tercih ederler. Bu durum, runtime hatalar\u0131na zemin haz\u0131rlayabilir.<\/p>\nKullanici<\/code> tipindeki bir objenin telefonNumarasi<\/code> \u00f6zelli\u011fini kullanarak bir SMS g\u00f6nderme i\u015flemi yapacak:<\/p>\n\nfunction smsGonder(kullanici: Kullanici, mesaj: string) {\n if (kullanici.telefonNumarasi) {\n console.log(${kullanici.telefonNumarasi} numaras\u0131na SMS g\u00f6nderildi: ${mesaj}<\/code>);\n } else {\n console.warn(${kullanici.ad} kullan\u0131c\u0131s\u0131n\u0131n telefon numaras\u0131 yok, SMS g\u00f6nderilemedi.<\/code>);\n }\n}\n\nsmsGonder(kullanici1, \"Merhaba!\"); \/\/ Uyar\u0131 verir\nsmsGonder(kullanici2, \"Toplant\u0131 hat\u0131rlatmas\u0131.\"); \/\/ SMS g\u00f6nderir\n\n<\/pre>\nif<\/code> kontrol\u00fc ile durumu ele almam\u0131z, kodu daha g\u00fcvenli hale getirir. Ancak ya her yerde bu kontrol\u00fc yapmay\u0131 unutursak? Veya, bir alan asl\u0131nda her zaman mevcut olmas\u0131 gereken bir ba\u011flamda opsiyonel olarak i\u015faretlenmi\u015fse ne olur? \u00d6rne\u011fin, bir sipari\u015f objesinde siparisKodu?: string;<\/code> \u015feklinde bir tan\u0131m, sipari\u015f olu\u015ftuktan sonra her sipari\u015fin bir kodunun olmas\u0131 gerekti\u011fi mant\u0131\u011f\u0131na ayk\u0131r\u0131 olabilir. Bu t\u00fcr durumlar, geli\u015ftirici niyetini belirsizle\u015ftirir ve hata ay\u0131klamay\u0131 zorla\u015ft\u0131r\u0131r.<\/p>\nundefined<\/code> ile \u00e7al\u0131\u015fmak, JavaScript'in gev\u015fek tip yap\u0131s\u0131ndan kaynaklanan tip d\u00f6n\u00fc\u015f\u00fcm\u00fc sorunlar\u0131na da yol a\u00e7abilir. \u00d6rne\u011fin, bir say\u0131 beklenen yerde undefined<\/code> gelirse, matematiksel i\u015flemler NaN (Not a Number) sonucunu verebilir veya beklenmedik davran\u0131\u015flar sergilenebilir. Bu t\u00fcr belirsizlikler, \u00f6zellikle b\u00fcy\u00fck ekiplerle \u00e7al\u0131\u015f\u0131rken veya uzun soluklu projelerde, teknik borcu art\u0131rarak projenin s\u00fcrd\u00fcr\u00fclebilirli\u011fini olumsuz etkiler. Bu nedenle, TypeScript'in sundu\u011fu tip sistemini maksimum d\u00fczeyde kullanarak, '?' yerine daha kesin ve niyetimizi a\u00e7\u0131k\u00e7a belirten yakla\u015f\u0131mlar benimsememiz b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r.<\/p>\n\n
G\u00fcvenli Tip Y\u00f6netimi \u0130\u00e7in Utility Tiplerini Tan\u0131yor Musunuz?<\/h2>\n
\n
PartialRequiredPartial<\/code>'\u0131n tam tersidir.<\/li>\nReadonlyPickT<\/code>) belirli \u00f6zelliklerini (K<\/code>) se\u00e7erek yeni bir tip olu\u015fturur.<\/li>\nExcludeRecordK<\/code>) ve de\u011fer (T<\/code>) tiplerine sahip bir nesne tipi olu\u015fturur.<\/li>\nReturnTypePick<\/code> kullanmak, veya bir form g\u00fcncellemesi yaparken sadece de\u011fi\u015fen alanlar\u0131 g\u00f6ndermek i\u00e7in Partial<\/code> kullanmak, tip g\u00fcvenli\u011fini korurken esneklik sa\u011flar. Utility tipleri, tip sistemini dinamik ve esnek bir \u015fekilde y\u00f6netmemizi sa\u011flayarak, kod kalitesini art\u0131r\u0131r, yeniden kullan\u0131labilirli\u011fi te\u015fvik eder ve geli\u015ftirme s\u00fcrecindeki hatalar\u0131 minimize eder.<\/p>\nOmitPick<\/code>'in bir nevi z\u0131t kutbu gibi \u00e7al\u0131\u015farak, bir tipten belirli \u00f6zellikleri \"\u00e7\u0131karmam\u0131z\u0131\" sa\u011flar. Bu sayede, ba\u015flang\u0131\u00e7ta \u00e7ok geni\u015f tan\u0131mlanm\u0131\u015f bir ana tipten, farkl\u0131 ba\u011flamlar i\u00e7in \u00f6zel, daralt\u0131lm\u0131\u015f tipler t\u00fcretebiliriz. B\u00f6ylece, gereksiz veya hassas verilerin yanl\u0131\u015f yerlerde kullan\u0131lmas\u0131n\u0131 engelleyerek hem tip g\u00fcvenli\u011fini hem de uygulama g\u00fcvenli\u011fini art\u0131rm\u0131\u015f oluruz.<\/p>\nOmit Utility Tipi Nedir ve Belirli \u00d6zellikleri Bir Tiplerden Nas\u0131l Kald\u0131r\u0131r\u0131z?<\/h2>\n
OmitT<\/code>) belirli \u00f6zellikleri (K<\/code>) \"\u00e7\u0131karmak\" veya \"atlamak\" i\u00e7in kullan\u0131l\u0131r. Bu, \u00f6zellikle bir objenin t\u00fcm \u00f6zelliklerine ihtiyac\u0131n\u0131z olmad\u0131\u011f\u0131 veya baz\u0131 hassas bilgileri belirli ba\u011flamlarda gizlemeniz gerekti\u011fi durumlarda son derece kullan\u0131\u015fl\u0131d\u0131r. Omit<\/code>, kodunuzu daha mod\u00fcler, okunabilir ve tip g\u00fcvenli\u011fi a\u00e7\u0131s\u0131ndan daha sa\u011flam hale getirir.<\/p>\n\ntype YeniTip = Omit\n
MevcutTip<\/code>: \u00d6zelliklerini \u00e7\u0131karmak istedi\u011finiz orijinal tiptir.<\/li>\n\"kaldirilacakOzellik1\" | \"kaldirilacakOzellik2\"<\/code>: Orijinal tipten \u00e7\u0131kar\u0131lacak \u00f6zelliklerin string literal birle\u015fimidir (union type). Bu k\u0131sma birden fazla \u00f6zellik ekleyebilirsiniz.<\/li>\n<\/ul>\nOmit<\/code>'in nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ad\u0131m ad\u0131m inceleyelim. Bir kullan\u0131c\u0131 y\u00f6netim sistemi i\u00e7in temel bir Kullanici<\/code> tipimiz olsun:<\/p>\n\ninterface Kullanici {\n id: string;\n ad: string;\n email: string;\n sifreHash: string; \/\/ Hassas bilgi\n createdAt: Date;\n updatedAt: Date;\n}\n\n<\/pre>\nKullanici<\/code> tipi, veritaban\u0131nda saklanan t\u00fcm bilgileri i\u00e7erir. Ancak, bir API'den kullan\u0131c\u0131 verilerini frontend'e g\u00f6nderirken veya bir kullan\u0131c\u0131n\u0131n herkese a\u00e7\u0131k profilini g\u00f6sterirken sifreHash<\/code> gibi hassas bilgileri veya createdAt<\/code>, updatedAt<\/code> gibi sadece backend i\u00e7in \u00f6nemli olan zaman damgalar\u0131n\u0131 g\u00f6ndermek istemeyiz. \u0130\u015fte bu noktada Omit<\/code> devreye girer:<\/p>\n\n\/\/ Frontend'e g\u00f6nderilecek g\u00fcvenli kullan\u0131c\u0131 tipi\ntype GuvenliKullanici = OmitGuvenliKullanici<\/code> tipi, orijinal Kullanici<\/code> tipinden sifreHash<\/code>, createdAt<\/code> ve updatedAt<\/code> \u00f6zelliklerini ba\u015far\u0131l\u0131 bir \u015fekilde \u00e7\u0131karm\u0131\u015ft\u0131r. Bu sayede, frontend'e gidecek veya herkese a\u00e7\u0131k bir ba\u011flamda kullan\u0131lacak verilerin sadece gerekli ve g\u00fcvenli alanlar\u0131 i\u00e7erdi\u011finden emin olabiliriz. Bu yakla\u015f\u0131m, yanl\u0131\u015fl\u0131kla hassas verilerin if\u015fa edilmesini \u00f6nler ve uygulaman\u0131z\u0131n genel g\u00fcvenlik post\u00fcr\u00fcn\u00fc art\u0131r\u0131r.<\/p>\nOmit<\/code> kullanman\u0131n avantajlar\u0131 \u015funlard\u0131r:<\/p>\n\n
Omit<\/code> ile tek sat\u0131rda yeni bir tip t\u00fcretebilirsiniz.<\/li>\nKullanici<\/code> tipinde yeni bir \u00f6zellik eklendi\u011finde veya \u00e7\u0131kar\u0131ld\u0131\u011f\u0131nda, Omit<\/code> kullanan t\u00fcretilmi\u015f tipler otomatik olarak g\u00fcncellenir (e\u011fer \u00e7\u0131kar\u0131lan \u00f6zellikler listesinde de\u011filse). Bu, manuel m\u00fcdahale ihtiyac\u0131n\u0131 azalt\u0131r.<\/li>\n<\/ul>\nOmit<\/code> utility tipi, TypeScript projelerinizde tip y\u00f6netimini daha sofistike ve g\u00fcvenli bir seviyeye ta\u015f\u0131yan g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. \u00d6zellikle farkl\u0131 katmanlar veya bile\u015fenler aras\u0131nda veri transferi yaparken, veri modellerinizin spesifik ihtiya\u00e7lara g\u00f6re uyarlanmas\u0131n\u0131 sa\u011flayarak gereksiz karma\u015f\u0131kl\u0131\u011f\u0131 ortadan kald\u0131r\u0131r ve olas\u0131 hatalar\u0131 \u00f6nler.<\/p>\nBir API Cevab\u0131n\u0131 Frontend \u0130\u00e7in G\u00fcvenli Hale Getirmek: Omit ile Pratik Bir Vaka Analizi<\/h2>\n
\ninterface UrunVT {\n id: string;\n ad: string;\n aciklama: string;\n fiyat: number;\n stokAdedi: number;\n tedarikciId: string; \/\/ \u0130\u00e7 sistem bilgisi\n createdAt: Date;\n updatedAt: Date;\n metaData: RecordUrunVT<\/code> (Veritaban\u0131 \u00dcr\u00fcn\u00fc) tipi, backend taraf\u0131nda her \u015feyi i\u00e7erir. Ancak, frontend'de bir \u00fcr\u00fcn listesini veya \u00fcr\u00fcn detay sayfas\u0131n\u0131 g\u00f6sterirken, tedarikciId<\/code>, createdAt<\/code>, updatedAt<\/code> ve \u00f6zellikle metaData<\/code> gibi bilgilerin g\u00f6sterilmesine gerek yoktur. Hatta, tedarikciId<\/code> gibi bilgilerin frontend'e s\u0131zmas\u0131, i\u015f mant\u0131\u011f\u0131na dair istemedi\u011fimiz bilgilerin if\u015fa olmas\u0131na neden olabilir.<\/p>\n\n
UrunVT<\/code> objesini al\u0131p, her bir \u00f6zelli\u011fini tek tek frontend i\u00e7in uygun bir objeye kopyalamak. Bu y\u00f6ntem, b\u00fcy\u00fck objelerde tekrarlay\u0131c\u0131 ve hataya a\u00e7\u0131k olabilir.<\/li>\nPartial<\/code> Yanl\u0131\u015f Kullan\u0131m\u0131:<\/strong> Bazen, \"sadece bu alanlar gerekli\" diyerek PartialOmit<\/code> ile bu problemi zarif ve tip g\u00fcvenli bir \u015fekilde \u00e7\u00f6zebiliriz. Frontend i\u00e7in bir UrunGorunumu<\/code> tipi olu\u015ftural\u0131m:<\/p>\n\n\/\/ Frontend'de \u00fcr\u00fcn g\u00f6stermek i\u00e7in g\u00fcvenli ve sadele\u015ftirilmi\u015f tip\ntype UrunGorunumu = Omit\n
UrunVT<\/code> tipi de\u011fi\u015fti\u011finde (\u00f6rne\u011fin yeni bir alan eklendi\u011finde), UrunGorunumu<\/code> tipi otomatik olarak g\u00fcncellenir ve manuel d\u00fczenlemeler yapman\u0131za gerek kalmaz (\u00e7\u0131kar\u0131lan alanlar listesi de\u011fi\u015fmedi\u011fi s\u00fcrece).<\/li>\nOmit<\/code>'in sadece teorik bir konsept olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda g\u00fcnl\u00fck geli\u015ftirme pratiklerinde kar\u015f\u0131la\u015f\u0131lan ger\u00e7ek d\u00fcnya problemlerini \u00e7\u00f6zmek i\u00e7in ne kadar g\u00fc\u00e7l\u00fc ve pratik bir ara\u00e7 oldu\u011funu g\u00f6stermektedir. Frontend ve backend aras\u0131ndaki veri k\u00f6pr\u00fcs\u00fcn\u00fc daha sa\u011flam ve g\u00fcvenli hale getirerek, daha kaliteli ve s\u00fcrd\u00fcr\u00fclebilir uygulamalar geli\u015ftirmenize olanak tan\u0131r.<\/p>\nOmit mi, Pick mi? Hangi Durumda Hangisini Tercih Etmelisiniz?<\/h3>\n
Omit<\/code> ve Pick<\/code>, her ikisi de mevcut bir tipten yeni tipler t\u00fcretmek i\u00e7in kullan\u0131l\u0131r, ancak farkl\u0131 yakla\u015f\u0131mlara sahiptirler ve farkl\u0131 senaryolarda daha uygun olabilirler. Bu iki g\u00fc\u00e7l\u00fc arac\u0131 do\u011fru bir \u015fekilde kullanmak, kodunuzun netli\u011fini ve tip g\u00fcvenli\u011fini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde art\u0131rabilir.<\/p>\nPickPick<\/code>, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, bir tipin (T<\/code>) belirli \u00f6zelliklerini (K<\/code>) se\u00e7erek yeni bir tip olu\u015fturur. Yani, \"bu tipten sadece bu \u00f6zellikleri istiyorum\" demek istedi\u011finizde Pick<\/code> kullan\u0131rs\u0131n\u0131z. Sentaks\u0131 \u015fu \u015fekildedir:<\/p>\n\ntype SecilenTip = Pick\ninterface Kitap {\n id: string;\n baslik: string;\n yazar: string;\n sayfaSayisi: number;\n isbn: string;\n yayinTarihi: Date;\n}\n\n\/\/ Bir kitap listesini g\u00f6sterirken sadece ba\u015fl\u0131k ve yazar yeterli olabilir\ntype KitapOzeti = PickOmit<\/code> ve Pick<\/code> aras\u0131ndaki temel fark nedir ve ne zaman hangisini kullanmal\u0131s\u0131n\u0131z?<\/p>\n\n
Pick<\/code>: Dahil Etme (Whitelist Yakla\u015f\u0131m\u0131)<\/strong><\/p>\n\n
Omit<\/code>: Hari\u00e7 Tutma (Blacklist Yakla\u015f\u0131m\u0131)<\/strong><\/p>\n\n
\n
Pick<\/code><\/strong> kullanmak daha mant\u0131kl\u0131d\u0131r. Daha az kod yazars\u0131n\u0131z ve niyetiniz daha net olur.<\/li>\nOmit<\/code><\/strong> kullanmak daha pratiktir.<\/li>\n<\/ul>\nKitap<\/code> tipimizden sadece id<\/code> ve isbn<\/code>'i \u00e7\u0131kar\u0131p geri kalan her \u015feyi isteseydik, Omit<\/code> kullanmak daha k\u0131sa ve okunabilir olurdu, \u00e7\u00fcnk\u00fc baslik<\/code>, yazar<\/code>, sayfaSayisi<\/code>, yayinTarihi<\/code>'ni tek tek Pick<\/code> ile listelemek yerine, sadece \u00e7\u0131kar\u0131lacak iki alan\u0131 belirtmek yeterli olurdu.<\/p>\n\n\/\/ id ve isbn hari\u00e7 t\u00fcm Kitap \u00f6zelliklerini i\u00e7eren bir tip\ntype KitapDetay = OmitDaha Karma\u015f\u0131k Senaryolar \u0130\u00e7in Omit'i Di\u011fer Utility Tipleriyle Nas\u0131l Birle\u015ftirebilirsiniz?<\/h2>\n
Omit<\/code> utility tipi tek ba\u015f\u0131na bile olduk\u00e7a g\u00fc\u00e7l\u00fcd\u00fcr, ancak TypeScript'in di\u011fer utility tipleriyle birle\u015ftirildi\u011finde ger\u00e7ek potansiyelini ortaya \u00e7\u0131kar\u0131r. Bu kombinasyonlar, daha karma\u015f\u0131k veri modelleri ve i\u015f mant\u0131\u011f\u0131 senaryolar\u0131nda tip g\u00fcvenli\u011fini korurken inan\u0131lmaz bir esneklik sunar. Geli\u015ftiricilerin, mevcut tipleri kullanarak farkl\u0131 ihtiya\u00e7lara y\u00f6nelik \u00f6zel tipler t\u00fcretmesini sa\u011flar.<\/p>\nGorev<\/code> tipini tan\u0131mlayal\u0131m:<\/p>\n\ninterface Gorev {\n id: string;\n baslik: string;\n aciklama: string;\n sonTeslimTarihi: Date;\n tamamlandiMi: boolean;\n atananKullaniciId: string;\n etiketler?: string[]; \/\/ Opsiyonel\n createdAt: Date;\n updatedAt: Date;\n}\n\n<\/pre>\n1. Omit ve Partial Kombinasyonu: Yeni Kay\u0131t Olu\u015fturma Senaryosu<\/h3>\n
id<\/code>, createdAt<\/code> ve updatedAt<\/code> gibi sistem taraf\u0131ndan otomatik olarak atanacak alanlara ihtiyac\u0131m\u0131z yoktur. Ayr\u0131ca, etiketler<\/code> zaten opsiyonel oldu\u011fu gibi, tamamlandiMi<\/code> gibi baz\u0131 alanlar da ba\u015flang\u0131\u00e7ta varsay\u0131lan bir de\u011fere sahip olabilir ve kullan\u0131c\u0131 taraf\u0131ndan girilmesi zorunlu olmayabilir. Bu durumda, Omit<\/code> ve Partial<\/code>'\u0131 birle\u015ftirebiliriz:<\/p>\n\n\/\/ Yeni g\u00f6rev olu\u015fturmak i\u00e7in gerekli tipler\ntype GorevOlusturmaTemel = OmitOmit<\/code> ile gereksiz alanlar\u0131 kald\u0131rd\u0131k, ard\u0131ndan kalan alanlar\u0131n tamam\u0131n\u0131 Partial<\/code> ile opsiyonel hale getirdik. Bu sayede, yeni g\u00f6rev olu\u015ftururken sadece zorunlu alanlar\u0131 girmemiz gerekti\u011fi, di\u011ferlerinin iste\u011fe ba\u011fl\u0131 oldu\u011fu netle\u015fti.<\/p>\n2. Omit ve Required Kombinasyonu: Form G\u00fcncelleme veya Validasyon Senaryosu<\/h3>\n
id<\/code> ve createdAt<\/code> gibi de\u011fi\u015fmeyen alanlar\u0131 \u00e7\u0131karmak ve kalan t\u00fcm alanlar\u0131n (ad<\/code>, email<\/code> vb.) zorunlu olmas\u0131n\u0131 sa\u011flamak isteyebiliriz. Bu, bir form validasyonunda veya bir g\u00fcncelleme DTO'sunda (Data Transfer Object) yayg\u0131n bir ihtiya\u00e7t\u0131r.<\/p>\n\n\/\/ Kullan\u0131c\u0131 profil g\u00fcncelleme tipleri\ninterface KullaniciProfil {\n id: string;\n ad: string;\n soyad: string;\n email: string;\n telefonNumarasi?: string; \/\/ Opsiyonel\n adres?: string; \/\/ Opsiyonel\n createdAt: Date;\n}\n\ntype KullaniciProfilGuncellemeDTO = Requiredid<\/code> ve createdAt<\/code> \u00e7\u0131kar\u0131ld\u0131ktan sonra, orijinal KullaniciProfil<\/code> tipindeki opsiyonel alanlar (telefonNumarasi<\/code>, adres<\/code>) dahil, kalan t\u00fcm alanlar Required<\/code> ile zorunlu hale getirildi.<\/p>\n3. Omit ve Pick ile Dinamik Tipler Olu\u015fturma<\/h3>\n
\ninterface UrunDetay {\n urunId: string;\n ad: string;\n aciklama: string;\n fiyat: number;\n stokAdedi: number;\n tedarikciAdi: string;\n kategori: string;\n createdAt: Date;\n updatedAt: Date;\n}\n\n\/\/ tedarikciAdi ve createdAt\/updatedAt'i \u00e7\u0131kar\u0131p, kalanlardan sadece ad, fiyat ve kategori'yi al.\ntype UrunKartOzellikleri = Pick