Storyly'de çok farklı iki React projemiz var; biri "pano", diğeri "stüdyo".

Bu iki proje, teknik zorlukların yanı sıra amaç bakımından da farklılık gösterir. Pano, kullanıcılarımızın uygulamalarını, bulut sunucularını, Öykü gruplarını, ayarlarını ve entegrasyonlarını yönettikleri ve analizlerini gördükleri bir CMS projesidir. Studio projesi ise bir tasarım aracıdır; kullanıcılarımızın önceden tanımlı öğelerimizi kullanarak hikayelerini boş bir tuval üzerinde tasarlamalarına olanak tanır.

Teknik düzeyde, sizin de tahmin edeceğiniz gibi, gösterge paneli ağırlıklı olarak sunucu tarafı verileridir ve stüdyo, öncelikle istemci tarafı verileridir. Bu nedenle, kategorize ederken, projelerin sadece teknik yönlerinden ziyade amaçlarına odaklanıyorum.

Front-end geliştiriciler olarak bizler, teknik kararları yalnızca teknik yönlere göre vermemeliyiz. Ekip, mevcut ve olası kullanıcılar, projenin amaçlanan geleceği ve şirket kültürü dahil olmak üzere dikkate alınması gereken pek çok başka husus vardır. Tüm bunlar karar alma sürecinde temel olarak teknik çözümlerinizi etkileyecektir.

Görevinizin projeniz için bir durum yönetimi çözümü seçmek olduğunu varsayalım. Dışarıda, farklı eksileri ve artıları olan çok ÇOK var. Frontend ekosisteminde durum yönetimi konusunun “çerçeveler” konusunun yanında en çok sayıda çözümle geldiğini söylemek yanlış olmaz.

Yalnızca teknik artıları ve eksileri, performans sayılarını, çözümün kullanım kolaylığını ve belki de çözümün taahhüt, yıldız ve sorunlarını göz önünde bulundurursanız, kontrol ettiğiniz şey olacaktır. Ve bunların hepsi bir kitaplık seçerken geçerli noktalardır.

Her iki kod tabanında da kullanılacak durum yönetimi çözümlerine teknik açıdan baktığımda, Zustand veya Jotai'yi kullanma eğilimindeyim. Bakımlı, kullanımı inanılmaz derecede kolay ve performanslıdırlar. Kolay bir karardı, değil mi?

Durumunu yönetmek için her iki kod tabanımızda da kudretli Redux'u kullanıyorduk ve olması gerekenden daha kapsamlı büyüdüğü için projenin bu bölümünü basitleştirmem gerekiyordu. Hatalarımızın çoğunun ana kaynağı buydu. Hemen "Harika, her iki proje için de Zustand kullanmalıyız çünkü bu harika!" diye düşündüm. ama sonra bir adım geri çekildim ve biraz daha düşündüm.

Geçiş Süreci

Başta da açıkladığım gibi, iki kod tabanımız çok farklı.

Pano, sunucu tarafı verilerini çok ince değişikliklerle ve sunucu tarafı verilerine yükseltmelerle kullanıcıya gösterir. Analitik verileri, listeleri ve hesaplanan istatistikleri içeren birçok sayfa var. Bu projenin geleceği de benzer olacak; birçok istatistik ve liste içeren CMS benzeri bir pano. Bu yüzden verileri önbelleğe almayı, önbelleği geçersiz kılmayı, ağ şelalelerini, gerçek zamanlı veri güncellemelerini, iyimser güncellemeleri vb. düşünmem gerekiyordu. Bu konuları göz önünde bulundurarak, durum yönetimi çözümümüzü (Redux) değiştirmemize gerek olmadığına karar verdim. ); herhangi bir durumu "yönetmemiz" gerekmediğinden, onu kontrol panelinden kaldırmamız gerekiyordu.

Sonra SWR , TanStack Query ve RTK Query gibi veri alma çözümlerine baktım .

SWR sabit bir mutasyon akışına sahip değildir ve RTK Sorgusu, Redux Toolkit ile çok bağlantılıdır, bu yüzden TanStack Sorgusu ile ilerledim.

TanStack Query, önbelleğe alma, geçersiz kılma ve mutasyon akışlarıyla sunucu tarafı verileri yönetme yükünü ortadan kaldırır. Her zaman yönetilecek bir durum vardır, ancak onu her zaman kendi başınıza yönetmenize gerek yoktur. Bu ağır işi TanStack Query'e verdik ve arkamıza bakmadık. Redux ve TanStack Query'yi paralel olarak kullanıyoruz ve Redux durumunda hiçbir şey kalmayana kadar Redux durumunu parça parça TanStack sorgusuna taşıyoruz ve güvenle yapabiliriz yarn remove.

React Hooks, bunları paralel olarak kullanmamıza ve mantığı aralarında aşamalı olarak taşımamıza olanak tanır:

Ancak stüdyoda, sunucuya gönderilmek üzere oluşturulmuş pek çok tamamen istemci tarafı verisi vardır. Tamamen önceden tanımlanmış öğelerle bir hikaye tasarlayabilirsiniz; onları kanvas içinde hareket ettirebilir, yeniden boyutlandırabilir, ihtiyaçlarınıza göre içeriklerini değiştirebilir, Hikaye arka plan görüntüsünü değiştirebilir ve hatta arka plana bir video koyabilirsiniz. Son verileri kaydetmek için sunucuya göndermeden önce olasılıklar sonsuzdur. Tüm bu özellikler, siz kaydedene kadar istemci tarafı verileridir. Bunları kaydettikten ve düzenlemek için geri döndükten sonra, bunlar yine sunucu tarafındaki verilerden türetilen istemci tarafı verileridir.

Olası özellikleri de düşünmemiz gerekiyor - değişiklikleri geri alma, serbest çizimler oluşturma, Hikayeler arasında geçişler tasarlama... Olasılıklar sonsuzdur, ancak tüm olası özellikler istemci tarafı ağır verilerdir. Dolayısıyla maksimum esneklik için burada durumumuzu “yönetmemiz” gerekiyor.

Studio için zaten bir durum yönetimi çözümü olan Redux kullanıyorduk. Ben de takım arkadaşlarıma şu soruyu sordum: “Devlet yönetimimizi düzeltmek için ne kullanmalıyız?”

Tüm yanıtlardan sonra yol açıktı: Redux Toolkit kullanacağız .

RTK (Redux Toolkit), geliştiricilerin yaşam kalitesini iyileştirmek için Redux ekibinden bir araç setidir. Dilimleri kullanarak mağazanın yapılandırmasını ve birden çok mağazanın yönetimini basitleştirir . Böylece eski Redux durumumuzu yeni RTK mimarisine taşıdık. Hem eski hem de yeni mimariyi yan yana çalıştırıyoruz ve refactoring yaparken durum parçalarını yeni mimariye taşıyoruz. Tüm bunlar, ürünün iş akışını engellemeden hızlı ve kademeli olarak hareket etmemizi sağlar.

Redux sağlayıcılarına özel bir React Context ileterek bu eski ve yeni mimariyi paralel olarak çalıştırıyoruz :

Redux Sağlayıcısına özel bir içerik ilettiğinizde, ilgili tüm Redux kancalarını sağlanan oluşturucularla oluşturmanız ve doğrudan paketten içe aktarmak yerine bunları kodunuzda kullanmanız gerektiğini unutmayın react-redux:

Uzun vadeli hedefimiz, Redux'u Dashboard projesinden tamamen kaldırmak ve "eski" Redux'u Studio projesinden kaldırmaktır. Yeni özellikler geliştirirken ve hataları düzeltirken dokunmamız gereken her dosyayı yeniden düzenleyerek bu hedefe doğru ilerliyoruz.

Bu önemli teknik geçişler, temel olarak iki nedenden dolayı sorunsuz ve aşamalı olmalıdır: Birincisi, ekibinizin günlük çalışma hayatını elden geçiriyorsunuz. Bu değişikliklerle çalışmaktan mutlu olmalılar, aksi takdirde performansları önemli ölçüde düşer. Öte yandan, inşa etmek için kullandıkları araçları severlerse ve söz konusu araçlar onları engellemek yerine onlara yardımcı olursa, performansları önemli ölçüde artacaktır. İkincisi, ürün inşa edilmeye devam edilmelidir . Şov devam etmeli. Yeni özellikler olmalı. İlerlemesi gerekiyor. Bu nedenle teknik geçişler ürünün gelişimini engellememelidir. Her değişiklik artımlı olmalıdır.

Özet

Geliştiriciler olarak teknik kararlar alırken, üzerinde çalıştığımız projenin her yönünü ve birlikte çalıştığımız ekibin ihtiyaçlarını dikkate almalıyız. Bunun nedeni, bu teknik kararların yalnızca geliştiricileri değil, ekibi ve proje üzerinde çalışan herkesi etkilemesidir.

Teknik değişiklikler her ne pahasına olursa olsun artımlı olmalıdır. Bu değişiklikler, ürünün ardışık düzenini ve dolayısıyla başarısını engellememelidir.

Ve bir geliştiricinin üretken olabilmesi için onlara onları mutlu eden araçları vermeniz gerektiğini her zaman unutmayın.