<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*C0BjOjYjnuKo0yimqbas8w.png"><figcaption>Cover designed by <a href="https://medium.com/u/a59b94a9a014">Elif Yardımcı</a></figcaption></figure>Hi everyone!
In recent years, the web development world has witnessed the development of various server-oriented rendering models, in part following the widespread adoption of Single Page Applications (SPAs). In this article, we will discuss Streaming SSR, which aims to eliminate some of the disadvantages of Server Side Rendering (SSR), one of the most popular rendering patterns.
<blockquote>To better comprehend the impact of these rendering patterns, we will also often refer to Web Vitals metrics such as TTFB, TTI, FPC or CLS. You can revisit these metrics for a more comprehensive understanding at this link: <a href="https://web.dev/articles/user-centric-performance-metrics">https://web.dev/articles/user-centric-performance-metrics</a>
</blockquote>
So, what exactly is Streaming SSR, and how does it differentiate itself in the realm of web development? Let’s embark on a journey to explore this exciting new rendering pattern.
<h4>
What is Server-Side Rendering (SSR)?
</h4>
Server Side Rendering is one of the popular rendering patterns where web pages are initially rendered on the server before being sent to the client’s browser. In contrast to client-side rendering, where the browser handles most of the rendering work, SSR performs the rendering on the server.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*YeCRC1fFv5nOGrZ7"><figcaption>The working mechanism of SSR [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/server-side-rendering">Source</a>]</figcaption></figure>Here’s how it works:
<ol>
<li>A request is sent from the client to the server.</li>
<li>On the server, HTML is generated. The server has the ability to create new HTML content for each request. This HTML is then sent to the browser. (TTFB point)</li>
<li>The browser parses and renders this HTML. At this point, we have a UI that can be displayed to the user, but the user cannot interact with it because we need JavaScript.</li>
<li>The browser sends a request to fetch the necessary JavaScript bundle and downloads it.</li>
<li>The browser executes the JavaScript and performs hydration. (TTI Point)
</li>
</ol>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*wYxwDKlTZlm5p9gPCxP-SA.png"><figcaption>Web Vital Metrics for SSR [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/server-side-rendering">Source</a>]</figcaption></figure>Some key benefits of Server-Side Rendering are:
<ol>
<li>
Improved SEO: Search engines can easily crawl and index the content because the initial page load is fully rendered on the server. This can lead to better search engine rankings compared to purely client-side rendering, which search engines may have difficulty parsing.</li>
<li>
Accessibility: SSR can enhance accessibility because the initial HTML content is readily available, making it easier for screen readers and other assistive technologies to interpret the content.</li>
<li>
Better User Experience: Since users receive a fully rendered page, they can start consuming the content more quickly, providing a better user experience. Also no flicker UI issues or CLS problems.</li>
</ol>
Is everything about SSR so good? Unfortunately, no. Like any rendering pattern, SSR has strengths and weaknesses too. We will examine two potential drawbacks of Server-Side Rendering (SSR), which are Initial Waiting Time which is related Time to First Byte (TTFB) metric and The Interactive Delay which is related Time to Interactive (TTI) metric.
TTFB — The Initial Waiting Time: One downside of SSR is the prolonged Time to First Byte (TTFB), which is the time it takes for the first byte to reach the user’s browser. This delay occurs because SSR involves rendering all HTML on the server, including bundling JavaScript, which requires waiting for essential data requests and executing rendering logic. As a result, users may experience a blank screen during the initial loading process, which can impact the user experience.
TTI — The Interactive Delay: In the context of SSR, Time to Interactive (TTI) can be delayed. While the initial HTML may be visible, full interactivity is postponed as the browser loads and executes JavaScript. This delay can affect the overall user experience.
A new rendering pattern has entered our lives with React 18 to mitigate these two adverse effects: Streaming SSR.
<h3>What is the Streaming SSR?</h3>
Streaming SSR is a method that improves TTFB and TTI while performing server-side rendering. The logic behind streaming is that we have a concept called Node streams, which allows us to continuously transfer data in pieces.
In standard SSR, rendering all the HTML that makes up our page on the server and then transferring all the necessary JS for that HTML to the client via a bundle, as discussed in the previous section, revealed the disadvantages of TTFB and TTI. Streaming SSR provides a solution by rendering each component separately and creating JS bundles on a component-by-component basis, allowing us to stream everything in pieces (we called them chunks) that we will show on the page.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*jiYO-UiGVK2_0QTT"></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*XKnwBY1S7NqSW5Bg"><figcaption>Left: SSR | Right: Streaming SSR [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/streaming-ssr">Source</a>]</figcaption></figure>Let’s try to understand how it works by examining it step by step:
<ol>
<li>A request is sent from the client to the server.</li>
<li>The server now returns a mechanism for data transfer using node streams along with a basic HTML file to the browser. (This basic HTML file also contains the necessary data for SEO, so we don’t have any SEO disadvantage.)</li>
<li>The client receives this HTML and parses it just like it behaves in SSR. Node stream data flow also starts at this point.</li>
<li>The server transmits the UI of the completed rendering components and the necessary JS in chunks to the browser.</li>
<li>The browser executes and hydrates these chunks, making them ready.</li>
</ol>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*be4s9j9CGvJNUlPpdm26cg.png"><figcaption>Web Vital metrics for Streaming SSR [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/streaming-ssr">Source</a>]</figcaption></figure>One of the most notable benefits of this approach is the elimination of the need to wait for the entire server-rendered content to be generated. Consequently, the Time to First Byte (TTFB) is significantly reduced.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*J-4iAND-wXxj_8OY"><figcaption>Web Vitals Comparision for SSR vs Streaming SSR [<a href="https://www.patterns.dev/posts/streaming-ssr">Source</a>]</figcaption></figure>Another noteworthy advantage pertains to the process of hydration. In traditional Server-Side Rendering (SSR), the entire execution of a substantial JavaScript bundle was required. This bundle encompassed code for all the elements on the page. However, with the new approach, we can selectively execute only the necessary code for a specific portion, leading to a vastly improved Time to Interactive (TTI).
As a result, the moment the hydration of the initial chunk is completed, the Time to Interactive (TTI) becomes nearly instantaneous. This signifies that the browser becomes interactive at this very point.
<h3>Streaming SSR Implementation w/NextJs 13</h3>
We have completed the theoretical part. Now let’s learn how to implement this new pattern with Next.js.
With NextJS 13, data fetching methods have changed a bit from previous versions. Now, with default server components, you can fetch data directly within a component without using any effect hooks or server-side props such as getServerSideProps.
For example, you can see a standard SSR page structure below:
<pre> export default async function Page() { /** * To shorten the TTFB time, requests are optimized by parallelizing them. */ const productsPromise = getProducts(); const personsPromise = getPersons(); const plansPromise = getPlans(); const [productData, personsData, plansData] = await Promise.allSettled([ productsPromise, personsPromise, plansPromise ]); return ( &lt;div&gt; &lt;Products data={productData} /&gt; &lt;Persons data={personsData} /&gt; &lt;Plans data={plansData} /&gt; &lt;/div&gt; ); }</pre>
In this structure, before the user can view the page, all requests must first be completed, and then all components on the page must be created on the server side using this data. The HTML and JS resulting from this process are sent to the browser.
<h4>So how do we implement streaming SSR in this structure?</h4>
<ol><li>Component-Specific Data Fetching</li></ol>
Each component should be in charge of getting its own data. The main idea is to separate the rendering of components and make sure that any component with its data ready can be shown on its own. So, we need to start splitting up our data requests for each component.
2. React Suspense
We need to wrap Component with Suspense to tell React that this component can be rendered with streaming SSR.
We already knew the Suspense and were used for Code Splitting. With React 18, Suspense allows us to create streamable components. For more detail look at this <a href="https://react.dev/reference/react-dom/server/renderToReadableStream#streaming-more-content-as-it-loads">React Doc</a>.
Let’s look below implementation closely:
<pre>export default function Page() { return ( &lt;div&gt; &lt;Suspense fallback={&lt;Skeleton/&gt;}&gt; &lt;Persons /&gt; &lt;/Suspense&gt; &lt;Suspense fallback={&lt;Skeleton/&gt;}&gt; &lt;Plans /&gt; &lt;/Suspense&gt; &lt;Suspense fallback={&lt;Skeleton/&gt;}&gt; &lt;Products /&gt; &lt;/Suspense&gt; &lt;/div&gt; ); }</pre>
In Streaming SSR, every component wrapped with Suspense completes its own rendering after completing its own fetching and is then streamed to the browser. This means that we don’t need to wait for all three requests to complete and the entire page rendering to finish, as we would in a standard SSR example. Also after the first hydration (it means TTI point) browser becomes user-interactive. So that the user doesn't have to wait for other components that are still rendering.
Another advantage of streaming is that you can even use it externally for a child component on your page. There is no limitation to this. Thus, you can apply this method even to the bottom child of nested components.
In addition to these, Next.js 13 also provides a Loading UI feature that relies on streaming. This helps improve the user experience by displaying skeletons or what you want to display in the content section of your page until the Time To First Byte (TTFB) is completed. This way, users can see a loading indicator or placeholders until the actual content is ready, enhancing the overall UX. For more details follow <a href="https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming">the link</a>.
<blockquote>Also, I created a basic demo that includes standard SSR page, SSR + Loading UI page and Streaming SSR page.</blockquote>
<blockquote>
You can review the <a href="https://streaming-ssr-demo.vercel.app/">live demo</a> here and reach out source code <a href="https://github.com/Ogzhnsfgl/streaming-ssr-demo">here.</a>
</blockquote>
<h3>Conclusion</h3>
In this article, we have dived into the fascinating world of Streaming Server-Side Rendering (SSR), an exciting new rendering pattern that has emerged in the ever-evolving landscape of web development.
Streaming SSR comes as a promising solution to address some of the longstanding challenges associated with traditional Server-Side Rendering (SSR), namely Time to First Byte (TTFB) and Time to Interactive (TTI) delays. In addition, streaming SSR brings brand new options to hybrid structures such as CSR + SSR, which we use to optimize performance. This is really exciting.
As <a href="https://medium.com/u/ef0a84cf7f9d">ÇSTech</a>, we closely follow and care about innovations such as Streaming SSR for a better UX and DX, and try to implement them in our current applications.
As I always say, you can always reach me at the addresses below for your questions or suggestions.
Until we meet again, stay in tech.
Oğuzhan Sofuoğlu
Frontend Developer @<a href="https://medium.com/u/ef0a84cf7f9d">ÇSTech</a>
<a href="https://github.com/Ogzhnsfgl">Github</a> | <a href="https://www.linkedin.com/in/oguzhan-sofuoglu/">Linkedin</a> | <a href="http://osofuoglu.vercel.app/">Personal Website</a>
References:
<ul>
<li><a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/streaming-ssr">Streaming Server-Side Rendering | JavaScript Patterns</a></li>
<li><a href="https://www.patterns.dev/posts/streaming-ssr">Streaming Server-Side Rendering</a></li>
<li><a href="https://react.dev/blog/2021/12/17/react-conf-2021-recap#streaming-server-rendering-with-suspense">React Conf 2021 Recap - React</a></li>
<li><a href="https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming">Routing: Loading UI and Streaming | Next.js</a></li>
<li><a href="https://web.dev/articles/user-centric-performance-metrics">User-centric performance metrics | Articles | web.dev</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=800735e37bad" width="1" height="1" alt=""><hr>
<a href="https://medium.com/cstech/server-side-rendering-evolved-unlocking-faster-ttfb-and-tti-with-streaming-ssr-800735e37bad">Server-Side Rendering Evolved: Unlocking Faster TTFB and TTI with Streaming SSR</a> was originally published in <a href="https://medium.com/cstech">ÇSTech</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Server-Side Rendering Evolved: Unlocking Faster TTFB and TTI with Streaming SSR

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*xBwzBreTue2carOrk1Yamg.png"><figcaption>Kapak tasarımı <a href="https://medium.com/u/a59b94a9a014">Elif Yardımcı</a></figcaption></figure>Herkese selam!
Son yıllarda, web geliştirme dünyası, Single Page Application (SPA)’ların yaygın kabulünü takıben, çeşitli server odaklı işleme modellerinin gelişimini gördü. Bu makalede, en popüler rendering patternlerden biri olan Server Side Rendering’in (SSR) bazı dezavantajlarını ortadan kaldırmayı amaçlayan Streaming SSR’ı konuşacağız.
<blockquote>Bu rendering patternleri daha iyi anlamak için genellikle TTFB, TTI, FPC veya CLS gibi Web Vitals metriklerine başvuracağız. Konuyu daha iyi anlamak için aşağıdaki linkten bu metrikleri tekrar inceleyebilirsiniz: <a href="https://web.dev/articles/user-centric-performance-metrics">https://web.dev/articles/user-centric-performance-metrics</a>
</blockquote>
Peki, Streaming SSR tam olarak nedir ve web geliştirme alanına bir yenilik getiriyor? Hadi, bu heyecan verici yeni rendering pattern hakkında keşfe çıkalım.
<h4>Server-Side Rendering (SSR) nedir?</h4>
Server Side Rendering, web sayfalarının öncelikle sunucuda render edildiği ve ardından istemciye (browser) gönderildiği popüler rendering patternlerden biridir. Client Side Rendering’in (CSR) aksine, burada çoğu rendering işi, tarayıcı yerine sunucuda gerçekleştirilir.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*YeCRC1fFv5nOGrZ7"><figcaption>SSR’in calisma mekanizmasi [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/server-side-rendering">Source</a>]</figcaption></figure>Peki, SSR nasıl çalışır?
<ol>
<li>Tarayıcıdan sunucuya istek atılır.</li>
<li>Serverda bir HTML oluşturulur. Bu server her istekte yeni bir HTML oluşturma yeteneğine sahiptir. Oluşturulan HTML tarayıcıya gönderilir. (TTFB anı)</li>
<li>Tarayıcı gelen bu HTML’i parse edip renderlar. Bu noktada, kullanıcıya gösterilebilecek bir kullanıcı arayüzümüz var, ancak kullanıcıyla etkileşimde bulunabilmesi için JavaScript’e ihtiyacımız var.</li>
<li>Tarayıcı, gerekli JavaScript paketini almak için bir istek gönderir ve onu indirir.</li>
<li>Tarayıcı, JavaScript’i yürütür ve hydration yapar. (TTI anı)</li>
</ol>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*wYxwDKlTZlm5p9gPCxP-SA.png"><figcaption>SSR icin Web Vital Metrikleri [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/server-side-rendering">Source</a>]</figcaption></figure>Server-Side Rendering’in bazı temel faydaları şunlar olarak sıralanabilir:
<ol>
<li>
Geliştirilmiş SEO: Arama motorları, başlangıç sayfasının tamamen sunucuda render edildiği için içeriği kolayca tarayabilir ve dizine ekleyebilir. Bu, Client Side Rendering’e (CSR) kıyasla daha iyi arama motoru sıralamalarına imkan verir.</li>
<li>
Erişilebilirlik: Server Side Rendering, başlangıçtaki HTML içeriğinin hemen kullanılabilir olmasından dolayı erişilebilirliği artırabilir. Bu, ekran okuyucularının ve diğer yardımcı teknolojilerin içeriği yorumlamasını daha kolay hale getirir.</li>
<li>
Daha İyi Kullanıcı Deneyimi (UX): Kullanıcılar tamamen render edilmiş bir sayfa aldıkları için içeriği daha hızlı kullanmaya başlayabilirler, bu da daha iyi bir kullanıcı deneyimi sağlar. Ayrıca Cumulative Layout Shift (CLS) problemlerinin de önüne geçerek, kullanıcıya yüklendiği ilk andan itibaren stabil bir UI sağlar.</li>
</ol>
Peki SSR ile ilgili her şey çok mu iyi? Ne yazık ki hayır. Her rendering patternde oldugu gibi, SSR’da kendi avantajları ve dezavantajlarına sahiptir. Bu yazıda iki potansiyel dezavantajını inceleyeceğiz; İlk Bekleme Süresi, bu TTFB (Time to First Byte) metriği ile ilişkilidir ve Etkileşim Gecikmesi, bu da TTI ( Time to Interactive) metriği ile ilişkilidir.
TTFB — Ilk Bekleme Suresi: SSR’ın dezavantajlarından biri, kullanıcının tarayıcısına ilk byte’in ulaşması için gereken zamanı temsil eden TTFB’nin uzamasıdır. Bu gecikme, SSR’ın tüm HTML’i sunucuda render etme sürecini içerdiği için ortaya çıkar. Tüm HTML’i renderlamak, o sayfa için gerekli tüm veri isteklerini beklemeyi ve sayfayı oluşturan tüm logical kodların yürütülmesini gerektirir. Sonuç olarak, kullanıcılar bu yükleme süreci sırasında boş bir ekran deneyimleyebilir, bu da kullanıcı deneyimini olumsuz yönde etkileyebilir.
TTI — Etkileşim Gecikmesi: SSR ile TTI anı gecikebilir. Sunucuda renderlanan HTML, TTFB anı sonrasında görünür olabilirken, tarayıcı bu sayfayı etkileşimli hale getirebilmek için JS Bundle’ı indirir ve yürütürken etkileşim ertelenir. Bu gecikme genel kullanıcı deneyimini yine kötü etkileyebilir.
Bu iki olumsuz etkiyi hafifletmek için React 18 ile hayatımıza yeni bir rendering pattern girdi: Streaming SSR.
<h3>What is the Streaming SSR?</h3>
Streaming SSR, Server Side Render (SSR) kullanırken TTFB ve TTI metriklerimizi iyileştirmeye yarayan yeni bir yöntemdir. Streaming SSR’in arkasındaki mantık, veriyi parça parça ve sürekli olarak aktarmamızı sağlayan Node Streams adını verdiğimiz bir kavrama dayanır.
Standart SSR’da, sayfamızı oluşturan tüm HTML’i sunucuda renderlamak ve ardından bu HTML için gerekli olan tüm Bundle JS’ı istemciye aktarmak, önceki bölümde tartışıldığı gibi TTFB ve TTI dezavantajlarını ortaya çıkarıyordu. Streaming SSR, sayfada bulunan her bileşeni (component) ayrı ayrı renderleyarak ve component bazında JS bundlelar oluşturarak bir çözüm sunar. Bu, sayfada göstereceğimiz her şeyi parça parça (her bir parçayachunks diyoruz) istemciye aktarmamıza olanak tanır.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*jiYO-UiGVK2_0QTT"></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*XKnwBY1S7NqSW5Bg"><figcaption>Left: SSR | Right: Streaming SSR [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/streaming-ssr">Source</a>]</figcaption></figure>Streaming SSR mekanizmasını adım adım inceleyerek nasıl çalıştığını anlamaya çalışalım:
<ol>
<li>İstemciden sunucuya bir istek gönderilir.</li>
<li>Artık sunucu temel bir HTML dosyası ile birlikte veri transferi için node streams’a izin veren bir yapıyı tarayıcıya döndürür. (Bu temel HTML dosyası, SEO için gerekli veriyi içerir, bu nedenle SEO dezavantajımız olmaz.)</li>
<li>İstemci bu HTML’yi alır ve SSR’da olduğu gibi aynı şekilde işler. Node Streaming de bu noktada başlar.</li>
<li>Sunucu, renderi tamamlanan bileşenlerinin HTML ve JS Bundle’ını parçalar halinde browsera aktarır.</li>
<li>Tarayıcı bu parçaları işler ve hydrate ederek kullanıma hazır hale getirir.</li>
</ol>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*be4s9j9CGvJNUlPpdm26cg.png"><figcaption>Web Vital metrics for Streaming SSR [<a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/streaming-ssr">Source</a>]</figcaption></figure>Bu yaklaşımın en dikkat çeken faydalarından biri, sunucu tarafında render edilen içeriğin tamamlanmasını beklemeye gerek olmamasıdır. Sonuç olarak, Time To First Byte (TTFB) önemli ölçüde azalır.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*J-4iAND-wXxj_8OY"><figcaption>Web Vitals Comparision for SSR vs Streaming SSR [<a href="https://www.patterns.dev/posts/streaming-ssr">Source</a>]</figcaption></figure>Başka dikkate değer bir avantaj, hydration süreciyle ilgilidir. Standart Server Side Rendering (SSR) kullaniminda, sayfadaki tüm öğelere ait kodu içeren büyük bir Js Bundle’in çalıştırılması gerekiyordu. Ancak yeni yaklaşım ile yalnızca belirli bir bölüm (chunk) için gereken kodu çalıştırabiliriz, bu da Time to Interactive (TTI) açısından büyük bir iyileşmeye yol açar.
Sonuç olarak, ilk chunk’a ait hydration işlemi tamamlandığında, Time to Interactive (TTI) gerceklesmis olur. Bu, tarayıcının bu andan itibaren etkileşimli hale geldiği anlamına gelir.
<h3>NextJs 13 ile Streaming SSR Implementasyonu</h3>
Teorik kısmı tamamladık. Şimdi bu yeni patterni Next.js ile nasıl uygulayacağımızı öğrenelim.
Next.js 13 ile data-fetching yöntemleri önceki sürümlere gore farklılaştı. Artık varsayılan olarak gelen Server Components’ler ile birlikte Component içinde herhangi bir effect hook’u veya getServerSideProps gibi sunucu tarafı özellikleri kullanmadan doğrudan veri çekebiliyoruz.
Örneğin, aşağıda standart SSR kullanan bir sayfa yapısı görebilirsiniz:
<pre>export default async function Page() { /** * Daha dusuk TTFB icin, sayfada gereken tum * istekler paralellestirilmistir. */ const productsPromise = getProducts(); const personsPromise = getPersons(); const plansPromise = getPlans(); const [productData, personsData, plansData] = await Promise.allSettled([ productsPromise, personsPromise, plansPromise ]); return ( &lt;div&gt; &lt;Products data={productData} /&gt; &lt;Persons data={personsData} /&gt; &lt;Plans data={plansData} /&gt; &lt;/div&gt; ); }</pre>
Bu yapının içinde, kullanıcıya sayfayı göstermeden önce tüm istekler tamamlanmalı ve ardından bu elde edilen veriler kullanarak sayfadaki tüm bileşenler sunucu tarafında oluşturulmalıdır. Sonrasında, bu tüm işlemlerin sonucu olarak oluşturulan HTML ve JS tarayıcıya gönderilir.
<h4>Peki, Streaming SSR nasıl uygulanır?</h4>
<ol><li>Component Bazlı Data-Fetching</li></ol>
Her component kendi isteklerini atmaktan sorumlu olmalıdır. Streaming SSR’da temel fikir, bileşenlerin render mekanizmasını ayırmak ve herhangi bir bileşenin kendi verileri hazır olduğunda kendi başına gösterilebilmesini sağlamaktır. Bu nedenle, her bileşen için veri isteklerimizi ayırmaya başlamamız gerekiyor.
2. React Suspense
Component’in, Streaming SSR ile render edilebileceğini React’e bildirmek için Suspense ile sarmalamamız gerekiyor.
Suspense zaten hali hazirda Code Splitting için bildiğimiz ve kullandığımız bir yapıydı. Artık React 18 ile birlikte , Suspense SSR Streaming kullanılan Component oluşturmamıza imkan sağlıyor. Daha fazla detay için <a href="https://react.dev/reference/react-dom/server/renderToReadableStream#streaming-more-content-as-it-loads">React dokümantasyonuna</a> bakabilirsiniz.
Benzer sayfanın SSR Streaming implementasyonu görelim:
<pre>export default function Page() { return ( &lt;div&gt; &lt;Suspense fallback={&lt;Skeleton/&gt;}&gt; &lt;Persons /&gt; &lt;/Suspense&gt; &lt;Suspense fallback={&lt;Skeleton/&gt;}&gt; &lt;Plans /&gt; &lt;/Suspense&gt; &lt;Suspense fallback={&lt;Skeleton/&gt;}&gt; &lt;Products /&gt; &lt;/Suspense&gt; &lt;/div&gt; ); }</pre>
Streaming SSR’da, Suspense ile sarılan her bileşen, kendi istekleri tamamlandıktan sonra kendi render işlemini tamamlar ve ardından tarayıcıya aktarılır. Bu, standart bir SSR örneğinde olduğu gibi tüm isteklerin tamamlanmasını ve tüm sayfa render işleminin tamamlanmasını beklememize gerek olmadığı anlamına gelir. Ayrıca, ilk hydration işleminden sonra (yani TTI anı), tarayıcı kullanıcı etkileşimine hazır hale gelir. Bu nedenle, kullanıcı hala render işlemi devam eden diğer bileşenleri beklemek zorunda kalmaz.
Streaming SSR’ın başka bir avantajı da, bunu sayfanızdaki herhangi bir alt bileşen (child component) için de kullanabilmenizdir. Bu konuda bir sınırlama yoktur. Bu nedenle, iç içe geçmiş bileşenlerin en altındaki bileşenler de dahil olmak üzere istediginiz bileşeni Suspense ile sarıp streaming’in faydalarından yararlanabilirsiniz. Bu sayede sayfanın oluşma süresini ve kullanıcının sayfayla etkileşiminin kesilmesinin önüne geçebilirsiniz.
Bunlara ek olarak, Next.js 13 Streaming SSR’a dayanan bir Loading UI özelliği sunuyor. Bu, Time to First Byte (TTFB) anına kadar sayfanızda içerik alanında skeleton, spinner vb. istediğiniz şeyleri göstererek kullanıcı deneyimini geliştirmeye yardımcı olur. Bu sayede kullanıcılar boş bir sayfa yerine layout ile birlikte tanımladığınız placeholder’i görebilir. Daha fazla detay için <a href="https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming">linki</a> inceleyebilirsiniz.
<blockquote>Bütün bu konuştuklarımızı daha iyi anlamak için Standart SSR, SSR + Loading UI ve Streaming SSR yöntemlerini içeren küçük bir demo hazırladım.</blockquote>
<blockquote>
Live demo’yu <a href="https://streaming-ssr-demo.vercel.app/">buradan</a> inceleyebilir, kaynak kodlarına <a href="https://github.com/Ogzhnsfgl/streaming-ssr-demo">buradan</a> ulaşabilirsiniz.
</blockquote>
<h3>Sonuç</h3>
Bu makalede, web geliştirmenin sürekli değişen dünyasında ortaya çıkan heyecan verici yeni bir rendering pattern olan Streaming SSR’ı inceledik.
Streaming SSR, geleneksel Server Side Rendering (SSR) ile uzun zamandır ilişkilendirilen Time to First Byte (TTFB) ve Time to İnteractive (TTI) gibi bazı sorunları çözmek için umut verici bir çözüm olarak karşımıza çıkıyor. Ayrıca, Streming SSR, performansı optimize etmek için kullandığımız CSR + SSR gibi hybrid yapılar için yeni seçeneklerin de önünü açıyor. Bu gelişmeler gerçekten heyecan verici.
Biz <a href="https://medium.com/u/ef0a84cf7f9d">ÇSTech</a> olarak, daha iyi bir Kullanıcı Deneyimi (UX) ve Geliştirici Deneyimi (DX) için Streaming SSR gibi yenilikleri yakından takip ediyor ve mevcut uygulamalarımıza uygulamaya çalışıyoruz.
Sorularınız veya önerileriniz için aşağıdaki adreslerden bana ulaşabilirsiniz.
Tekrar görüşmek üzere, hoşça kalın.
Oğuzhan Sofuoğlu
Frontend Developer @<a href="https://medium.com/u/ef0a84cf7f9d">ÇSTech</a>
<a href="https://github.com/Ogzhnsfgl">Github</a> | <a href="https://www.linkedin.com/in/oguzhan-sofuoglu/">Linkedin</a> | <a href="http://osofuoglu.vercel.app/">Personal Website</a>
References:
<ul>
<li><a href="https://javascriptpatterns.vercel.app/patterns/rendering-patterns/streaming-ssr">Streaming Server-Side Rendering | JavaScript Patterns</a></li>
<li><a href="https://www.patterns.dev/posts/streaming-ssr">Streaming Server-Side Rendering</a></li>
<li><a href="https://react.dev/blog/2021/12/17/react-conf-2021-recap#streaming-server-rendering-with-suspense">React Conf 2021 Recap - React</a></li>
<li><a href="https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming">Routing: Loading UI and Streaming | Next.js</a></li>
<li><a href="https://web.dev/articles/user-centric-performance-metrics">User-centric performance metrics | Articles | web.dev</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=584eaaa85b36" width="1" height="1" alt=""><hr>
<a href="https://medium.com/cstech/server-side-rendering-evrimi-streaming-ssr-ile-ttfb-ve-tti-s%C4%B1n%C4%B1rlar%C4%B1n%C4%B1-kald%C4%B1r%C4%B1n-584eaaa85b36">Server-Side Rendering Evrimi: Streaming SSR ile TTFB ve TTI Sınırlarını Kaldırın</a> was originally published in <a href="https://medium.com/cstech">ÇSTech</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Server-Side Rendering Evrimi: Streaming SSR ile TTFB ve TTI Sınırlarını Kaldırın

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*oy7gtS4O4wluw0siQTiDGg.png"></figure>Hi everyone!
While developing applications using React, forms can sometimes pose significant challenges. In this article, I will share the essential features of React related to form handling and the points to consider when developing forms.
Forms are essential tools for user input and data collection in web applications. Proper management of forms is crucial for a good user experience and app performance. In this article, we will discuss the fundamental features of React related to forms and the necessary tools for developing efficient forms.
The flow of the article will be as follows:
<ol><li>Form Handling w/Traditional Way (Client Side)</li></ol>
<ul>
<li>Controlled / Uncontrolled Inputs</li>
<li>Creating High-Performance Forms in Traditional Way</li>
<li>Form Management Libraries</li>
</ul>
2. The New Age: Server Actions
<ul>
<li>What Are Server Actions?</li>
<li>Form Handling with Server Action</li>
</ul>
<h3>Form Handling w/Traditional Way (Client Side)</h3>
Until React 18, there is no chance to run our code outside the client. In this way, we should consider rendering, state management of forms and etc. for our app performance and UX.
This section will show you the essential fundamentals and best approaches for creating and handling performant forms in React Universe.
Before I continue, there is one point I want to make clear, rendering is not a beast; it is the backbone of React. However, redundant render is indeed a monstrous issue. As web developers, rendering is an essential aspect of our work, and when necessary, we should utilize it. Nonetheless, we must also safeguard our applications from unnecessary rendering to enhance performance. Therefore, this article does not advocate against rendering but rather focuses on optimizing the handling of web forms for improved performance.
<h4>Controlled / Uncontrolled Inputs</h4>
We can define the inputs we use in our forms in two ways. Let us learn from the below snippet:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1018/1*UmQnP8uk7Nr2haEPnEnRLg.png"></figure>These inputs do the same job as a result, but according to the chosen method, they directly affect the form management and app performance. If we compare them to understand their effects, we can write the following pros/cons table:
Controlled Component:
Pros:
<ul>
<li>Maximum flexibility and customization.</li>
<li>Easy data validation and error management.</li>
</ul>
Cons:
<ul><li>Potential performance issues with large datasets or fast interactions.</li></ul>
Uncontrolled Component:
Pros
<ul>
<li>Less configuration and easier to use.</li>
<li>Performance advantage with large datasets or fast interactions.</li>
</ul>
Cons
<ul><li>Sometimes increased code complexity with direct DOM manipulation and out-of-state data processing.</li></ul>
<h3>Creating High-Performance Forms in Traditional Way</h3>
As we have examined above, both approaches have advantages and disadvantages. While controlled components provide more flexibility and easier data validation, they have disadvantages such as performance issues and code complexity. Uncontrolled components, on the other hand, offer fewer configuration and performance advantages, while they can create disadvantages such as code complexity.
However, for creating performant forms, it is recommended to opt for the uncontrolled approach, which directly accesses DOM elements. By using uncontrolled components, there is no need to rely on React state or synchronize with it, allowing users to enter data directly into pure HTML inputs. This eliminates the need for state updates and UI re-renders, resulting in improved performance.
Let’s compare these two methods with a simple example without using any external library and examine the results.
The properties of the simple form we will use as an example:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/512/1*vA0QJy82-s0LYQ9kM5ajsQ.png"><figcaption>Basic Login Form Inputs</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*SlHsLg4ZIfi_SGjMzl_tgQ.png"></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TDdIFHMVkew5Tf-D502aUA.png"><figcaption>Controlled vs Uncontrolled Forms Code Snippets</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/640/1*9nfS8OItFvndBHUt7PUNGA.gif"></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/640/1*k6m0U6XEl99j5soUJoTJPw.gif"><figcaption>Controlled vs Uncontrolled Forms Renders</figcaption></figure>In a controlled form, every user interaction triggers a re-render as the React state is updated. In a simple login form, even typing a single character can result in more than 25 renders until the form is complete.
In an uncontrolled form, there is no need for React re-rendering while inputting data. Instead, we instantly connect to the inputs using refs. The form data is accessed and validated only when the LOGIN button is clicked. If there are any errors, they are shown; otherwise, the submit operation is performed successfully.
In real-world scenarios, it’s common to use external libraries for handling form data, validating inputs, and other form-related tasks. To simplify form handling and tackle these challenges, popular React form libraries like Formik, React Hook Form, and Redux Form are available. These libraries expedite development, simplify form handling, and contribute to an improved form experience.
<h3>Form Management Libraries</h3>
The top 3 popular form libraries mentioned above offer advanced features for form functionality such as form validation, data management, form status tracking, error handling and more. They also provide support for components specific to form fields, custom validation rules, form submission, and data manipulation. By using these libraries, we can make more complex form scenarios easier to manage and provide a better user experience.
However, there are some fundamental differences between these libraries. These differences are specified in the React Hook Form <a href="https://react-hook-form.com/faqs#ReactHookFormFormikorReduxForm">documentation</a> as follows:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/925/1*t-6ZSsisxXJBYdx3AlZYfA.png"><figcaption>Source: <a href="https://react-hook-form.com/faqs#ReactHookFormFormikorReduxForm">https://react-hook-form.com/faqs#ReactHookFormFormikorReduxForm</a></figcaption></figure>As can be seen from the table above, React Hook Form is the library that attaches the most importance to performance among these libraries. The most important feature of its good performance compared to other libraries is that it uses an uncontrolled component approach which we mentioned before as necessary to create a performant form. This makes the values and states of the form elements accessible via refs without directly binding them to the React state. This is very performance advantageous because it does not have to update the React state every time the user inputs or changes a value. I recommend you review the very well-prepared <a href="https://react-hook-form.com/get-started">documentation</a>.
In conclusion, when it comes to client-side forms, opting for an uncontrolled component approach can greatly enhance performance. You can create your forms as uncontrolled, leveraging the benefits of this approach for improved efficiency. However, if you have complex requirements such as form validations, advanced form handling logic, and seamless integration with validation libraries, you’ll need a reliable tool for managing client-side forms in React applications. In such cases, React Hook Form emerges as a powerful and efficient solution. It not only prioritizes performance but also provides comprehensive form-handling capabilities, including robust validations and seamless integration with popular validation libraries.
<h3>The New Age: Server Actions</h3>
Server actions are a powerful new feature in React that allows you to run asynchronous code on the server in response to user interaction. Even though it’s mostly a new feature, there’s no doubt it’ll be a game changer. NextJS currently (13.4) supports this feature experimentally.
<h4>So What Are Server Actions?</h4>
In the context of React, server actions are functions that are executed on the server before the page is rendered on the client. They can be used to perform a variety of tasks, such as:
<ul>
<li>Pre-validating form data</li>
<li>Saving form data to the server</li>
<li>Making API requests</li>
<li>Pre-rendering pages</li>
<li>Generating dynamic content</li>
<li>Caching data</li>
</ul>
In NextJS 13.4 this feature supports as an alpha feature. They offer a robust foundation for implementing server-side functionalities. Next.js API routes provide a way to create custom server endpoints that handle specific actions and data operations.
In order not to go beyond our topic, we will deal with the parts related to forms here.
<h4>Form Handling with Server Action</h4>
Server actions are defined through the action prop on &lt;form/&gt;. Typically, when building HTML forms, you pass a URL to the action prop. With server actions, Next now allows you to pass a function directly.
When a server action is triggered, the function is executed on the server and the result is returned to the client. This means that the form can be interactive before any client-side JavaScript has loaded. This is a great way to improve the performance of your applications.
Here is an example for better understanding:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*J_rwMBH8HWNr_BdFasEFMA.png"><figcaption>Server Component + Server Action</figcaption></figure>The above sample is a server component with server actions, which means that all of the logic is executed on the server. We use ‘use server’ keyword top of our action function scope to tell that Next.js should execute this function on the server.
This means that the form can be rendered and interacted with in the browser even if JavaScript is disabled. This is very important because it means that things like rendering, validation, form state and bundle size that we talked about in previous parts of the article, which we should consider for performance forms, are no longer important considerations.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/640/1*fFyJZ1CA9m6DT3fQ1SIOmQ.gif"></figure>You can keep all of the complex logic of forms on the server and manage the form on the server anymore. This feature is currently in the experimental stage but will be stable very soon. After that, we will have to completely rethink how we should handle our forms.
Since it is very new now, it is not entirely possible to handle forms with these features in the traditional way. In particular, we cannot do the validation strategy that we use as a sample before in this article with the server component + server action pair. However, NextJS allows server actions to be used with client components as well.
Let’s see how we can develop a validation closer to our needs with these new features with an example:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*e0rIJFAQHfCeM9uKIxvEkw.png"><figcaption>Client Component + Server Action</figcaption></figure>We used server action for form handling with minimum client JS which was able to render a success state and input errors.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/640/1*4cB2PtrnM6yEflDJa05gKA.gif"></figure>I have kept the examples simple like this for easy understanding, but you can add event listeners here and manipulate the error state according to your needs. But remember, every client-side code like onChange listener will require you to pay attention to the performance issues that we have explained in the above section of the article.
You can access all the examples you see in this article and more from the links below:
<a href="https://form-handling-demo.vercel.app/">Live demo</a> | <a href="https://github.com/Ogzhnsfgl/optimizing-form-handling-in-react">Github Repo</a> | <a href="https://codesandbox.io/p/github/Ogzhnsfgl/optimizing-form-handling-in-react/main?workspaceId=d715fb0b-f873-47d3-a7c1-5c1f6803e1c1">CodeSandbox</a>
<h3>Conclusion</h3>
In this article, we examined the points we should consider while developing with React/Next.js and the methods we can use for more performance forms.
Dealing with react-hook form seems to be the best solution at the moment due to the difficulties, flexibility and performance of forms on the client side. The new experimental feature server-action is very exciting and definitely looks like it will cause us to completely rethink/design the traditional methods we use.
Until we meet again, stay in tech.
Oğuzhan Sofuoğlu
Frontend Developer @<a href="https://medium.com/u/ef0a84cf7f9d">ÇSTech</a>
<a href="https://github.com/Ogzhnsfgl">Github</a> | <a href="https://www.linkedin.com/in/oguzhan-sofuoglu/">Linkedin</a> | <a href="http://osofuoglu.vercel.app/">Personal Website</a>
References:
<ol>
<li><a href="https://react-hook-form.com/get-started">https://react-hook-form.com/get-started</a></li>
<li><a href="https://react.dev/reference/react">https://react.dev/reference/react</a></li>
<li><a href="https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions">https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions</a></li>
</ol>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ee8904f33a99" width="1" height="1" alt=""><hr>
<a href="https://medium.com/cstech/optimizing-form-handling-in-react-maximizing-performance-ee8904f33a99">Optimizing Form Handling in React: Maximizing Performance</a> was originally published in <a href="https://medium.com/cstech">ÇSTech</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Optimizing Form Handling in React: Maximizing Performance

<h3>Cactus UI — Accessibility focused react component library</h3>
<figure><img alt="Cactus UI, is an accessibility focused, minimal styling React components library containing 13 components and various custom hooks developed in accordance with the Web Content Accessibility Guidelines (WCAG)." src="https://cdn-images-1.medium.com/max/1024/1*XqW5ZUFbXeZhyzYaz0figg.png"><figcaption>Cactus UI — Cover (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure>Türkçe version için: <a href="https://medium.com/@o-sofuoglu/cactus-ui-9a17cde0cf0b">tıklayın</a>
Hi there! In this article, I will try to introduce Cactus UI that accessibility focused react component library developed by us as CsTech.
Before I start explaining the library, the flow of the article will be as follows, along with a few issues that I would like to go over:
<ol>
<li>What’s web accessibility?</li>
<li>Why did we develop an accessibility focused component library?</li>
<li>Cactus UI Introduction</li>
</ol>
Let’s go…
<h3>
What’s web accessibility?</h3>
<figure><img alt="Web Erişilebilirliği — Kapak" src="https://cdn-images-1.medium.com/max/1024/1*CjoDC9rExCF58aoi0p_5rg.jpeg"><figcaption><a href="https://www.freepik.com/free-vector/diverse-people-set_6703775.htm#query=accessibility&amp;from_query=wcag&amp;position=4&amp;from_view=search&amp;track=sph">Image by pch.vector</a> on Freepik</figcaption></figure><blockquote>Accessibility means that any product or service is accessible and usable by everyone, including the disabled and the elderly.</blockquote>
According to the <a href="https://www.who.int/teams/noncommunicable-diseases/sensory-functions-disability-and-rehabilitation/world-report-on-disability">report</a> of the World Health Organization, approximately %15 of the world’s population (almost 1.2 billion people) continues to live with some kind of disability.
For this reason, as developers, we should take care to create products that everyone can easily access and use while developing a website.
In our scope, accessibility represents that all people can easily use the product we have developed and that any obstacle does not prevent the use of the product we have developed.
To achieve this, the World Wide Consortium’s (W3C) Web Accessibility Initiative (WAI) created the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines (WCAG)</a>. We, the developers, can ensure that people with disabilities can easily experience/use the product we have created by following these guidelines for web accessibility without any obstacles, with the help of the accessibility tools on their devices.
To reach more detail and different kind of perspectives, I recommend to you take a look at <a href="https://medium.com/cstech/huge-missing-part-web-accessibility-7951724158da">Huge Missing Part: Web Accessibility</a> article written by <a href="https://medium.com/@osmanakar_65575">Osman Akar</a> from CsTech.
<h3>Why did we develop an accessibility-oriented component library?</h3>
<figure><img alt="Why did we develop an accessibility-oriented component library? — Cover" src="https://cdn-images-1.medium.com/max/800/1*XZxIIukmXpLODfRjDsOzaQ.jpeg"><figcaption><a href="https://www.freepik.com/free-vector/illustration-web-design-template_2825770.htm#query=html&amp;position=20&amp;from_view=search&amp;track=sph">Image by rawpixel.com</a> on Freepik</figcaption></figure>In fact, as developers, we style and combine various HTML elements suitable for our purpose when creating a website. This is the main way of creating the websites we see/use.
That’s why when we develop, we use or create component libraries that collect these elements that are customized for certain purposes. While many of these libraries are developed/used for easy access to a consistent design guide and also rapid development, some libraries can be created for different purposes without any styling thought.
Our main aim and motivation when developing Cactus UI were to have a component library that we could use on all websites we developed as CsTech, which would allow us to create websites that comply with the necessary regulations regarding accessibility.
While developing the library that will meet our requirements, we made it open source because we want to contribute to the developer community. 🥳
<figure><img alt="-How much? + It’s open sorce." src="https://cdn-images-1.medium.com/max/250/1*XODA5Kr9Ihpm2el1Zeus9w.jpeg"><figcaption>Image from <a href="https://imgflip.com/user/gclough">Imgflip/gclough</a></figcaption></figure>Now let’s get to know Cactus UI more closely.
<h3>Cactus UI</h3>
<figure><img alt="Accessible Accessibility and behavior is implemented according to WAI-ARIA Authoring Practices, including full screen reader and keyboard navigation support. Adaptable All components are designed to work with mouse, touch, and keyboard interactions. They’re built with an accessibility first approach. Customizable Easy to customize with inline style, CSS files and libraries like styled-components." src="https://cdn-images-1.medium.com/max/1024/1*XogKgpNWrvkiHTHb_ZywAA.png"><figcaption>Cactus UI — Features (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure><a href="https://cactus-ui.ciceksepeti.dev/">Cactus UI</a>, is an accessibility focused, minimal styling React components library containing 13 components and various custom hooks developed in accordance with the Web Content Accessibility Guidelines (WCAG).
<figure><img alt="Components: Accordion Alert Alert Dialog Checkbox Dialog Focus Trap Listbox Popover Portal Radio Group Skip Nav Tabs Visually Hidden" src="https://cdn-images-1.medium.com/max/1024/1*Z8rJ4wONv7b0qG5etBIxJw.png"><figcaption>Cactus UI — Components (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure><figure><img alt="Hooks: useArray useIsCSR usePrevious useDebounce useLatestValue useForceUpdate useLocalStorage useCombinedRefs useEventListener useOnClickOutside useFindTabbableElements useFindFocusableElements useIsomorphicLayoutEffect" src="https://cdn-images-1.medium.com/max/1024/1*aSw8X_IvUgKVoc2QFyfCvg.png"><figcaption>Cactus UI — Hooks (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure>Since the main focus is to develop a library in accordance with the principles of accessibility, <a href="https://cactus-ui.ciceksepeti.dev/">Cactus UI</a> was developed in a way that without adopting a special design language only includes the necessary styling of components for proper work. However, the developer can easily style it according to the design she/he needs. Also, the developer can use it with different libraries (<a href="https://styled-components.com/">styled-components</a> etc.) or can style all components according to she/he design with the help of css.
<blockquote>You can review the <a href="https://cactus-ui.ciceksepeti.dev/">Cactus UI documentation</a> to learn how could you use all components and hooks. If you need any further information, do not hesitate to send your question to us on Github.</blockquote>
While we developing Cactus UI, we took care to ensure that it has a high DX, is easy to implement and is keep it as flexible as possible. Let’s see how easy it is to use a component from <a href="https://cactus-ui.ciceksepeti.dev/">Cactus UI</a> with an example.
Let’s implement the Cactus UI — Listbox component in our project together.
<ol><li>Install the Cactus UI to your project:</li></ol>
<pre>- Import the whole library // For Npm users: npm install @ciceksepeti/cui // For Yarn users: yarn add @ciceksepeti/cui - or import only the component you need // For Npm users: npm install @ciceksepeti/cui-listbox // For Yarn users: yarn add @ciceksepeti/cui-listbox</pre>
2. Import Listbox and ListboxItem in the relevant file:
<pre>import React from "react"; import { Listbox, ListboxItem } from "@ciceksepeti/cui-listbox"; // Base styles comes from Cactus UI import "@ciceksepeti/cui-listbox/styles.css"; // Custom css that will include our styles import "./listbox.css"; export function OurListbox() { return ( &lt;div style={{ height: "150px", padding: "30px" }} &gt; &lt;p className="title"&gt;CSTech Listbox&lt;/p&gt; &lt;Listbox aria-labelledby="example-listbox"&gt; &lt;ListboxItem value="listbox Item 1"&gt;Listbox Item 1&lt;/ListboxItem&gt; &lt;ListboxItem value="listbox Item 2"&gt;Listbox Item 2&lt;/ListboxItem&gt; &lt;ListboxItem value="listbox Item 3"&gt;Listbox Item 3&lt;/ListboxItem&gt; &lt;ListboxItem value="Listbox Item 4"&gt;Listbox Item 4&lt;/ListboxItem&gt; &lt;/Listbox&gt; &lt;/div&gt; ); } export default OurListbox;</pre>
Congratulations! Your Listbox component is ready to use and it looks like as below:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*GPDUDMXWFvvPVqgSVLmXPw.png"><figcaption>Cactus UI — Listbox default style</figcaption></figure>As I mentioned earlier, Cactus UI only includes the minimum styles needed for the component to work properly, so it does not look very delicious, but it has all the necessary features for accessibility. For example; you can navigate and select in the Listbox with the keyboard. These movements are detected by the screen reader, and the value of the focused element can be read aloud by the screen reader!
So how can we style this component according to the design we need? The answer to this is in the <a href="https://cactusui-documentation.vercel.app/docs/styling">styling section</a> on our documentation site. We provide you with many css-selectors for you to style all components easily, you can see selectors of the Listbox component below:
<figure><img alt="Cactus UI Listbox CSS Selectors Tablosu" src="https://cdn-images-1.medium.com/max/939/1*9nI4_Cgz01LaGGUNbTjkRg.png"><figcaption>Cactus UI — Listbox / CSS Selectors</figcaption></figure>With these selectors you can style your Listbox component as you wish through your .css fıle:
<pre>[data-cui-listbox-button] { width: 350px; height: 48px; font-size: 16px; font-weight: 600; color: #93b74d; background-color: #48625b; } [data-cui-listbox-arrow] { color: white; font-size: 16px; margin-right: 4px; } [data-cui-listbox-popover] { overflow: hidden; border-radius: 4px; background-color: #48625b; border: 1px solid rgb(171, 202, 171); } [data-cui-listbox-item] { color: #9bc14f; font-weight: 600; padding: 12px 10px; } [data-cui-listbox-item][data-active="true"] { color: #1c7450; background-color: #d6dfc3; }</pre>
After styling, the Listbox component looks like this:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*fKgrt26cdOHL2gJzWR1Lhw.png"><figcaption>Cactus UI — Listbox Styled with css</figcaption></figure>It’s that easy! You can find how to use a component in Cactus UI, styling details and examples on the relevant component’s <a href="https://cactus-ui.ciceksepeti.dev/">documentation page</a>.
Also, there is also a playground for each component page so you can play and test components easily.
<h4>Open Source — Contribution</h4>
Developed with an accessibility focus to create websites where everyone can benefit equally, Cactus UI aims to add value to the developer’s community and to grow its own value with your contributions.
In addition to questions about the issues you are experiencing, we also welcome your ideas and contributions about the areas you see lacking or want to improve.
Cactus UI — Github: <a href="https://github.com/ciceksepetitech/cactus-ui">https://github.com/ciceksepetitech/cactus-ui</a>
Until we meet again, stay in tech.
Oğuzhan Sofuoğlu
Frontend Developer
References:
<ol>
<li><a href="https://www.w3.org/WAI/standards-guidelines/wcag/">https://www.w3.org/TR/WCAG21/</a></li>
<li><a href="https://www.freecodecamp.org/news/web-accessibility-best-practices-and-checklist/">https://www.freecodecamp.org/news/web-accessibility-best-practices-and-checklist/</a></li>
<li><a href="https://medium.com/cstech/huge-missing-part-web-accessibility-7951724158da">https://medium.com/cstech/huge-missing-part-web-accessibility-7951724158da</a></li>
<li><a href="https://cactus-ui.ciceksepeti.dev/">https://cactus-ui.ciceksepeti.dev/</a></li>
</ol>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=4c934e906661" width="1" height="1" alt=""><hr>
<a href="https://medium.com/cstech/cactus-ui-4c934e906661">Cactus UI — Accessibility focused react component library</a> was originally published in <a href="https://medium.com/cstech">ÇSTech</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cactus UI — Accessibility focused react component library

<h3>Cactus UI — Erişilebilirlik Odaklı React Komponent Kütüphanesi</h3>
<figure><img alt="Cactus UI — Web İçeriği Erişilebilirlik Yönergeleri (WCAG)’ne uygun şekilde geliştirilmiş 13 komponent ile birlikte çeşitli custom-hook’lar içeren, minimum stillendirmeye sahip bir React kütüphanesidir." src="https://cdn-images-1.medium.com/max/1024/1*XqW5ZUFbXeZhyzYaz0figg.png"><figcaption>Cactus UI — Cover (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure>English version: <a href="https://medium.com/@o-sofuoglu/cactus-ui-4c934e906661">here</a>
Herkese selam, bu yazıda sizlere CsTech olarak geliştirdiğimiz erişilebilirlik odaklı react komponent kütüphanesi Cactus UI’ı tanıtacağım.
Kütüphaneyi anlatmaya başlamadan önce üstünden geçmek istediğim bir kaç konuyla birlikte yazının akışı şöyle olacak:
<ol>
<li>Web erişilebilirliği nedir?</li>
<li>Neden erişilebilirlik odaklı komponent kütüphanesi geliştirdik?</li>
<li>Cactus UI’ı tanıyalım.</li>
</ol>
Hadi başlayalım…
<h3>Web erişilebilirliği nedir?</h3>
<figure><img alt="Web Erişilebilirliği — Kapak" src="https://cdn-images-1.medium.com/max/1024/1*CjoDC9rExCF58aoi0p_5rg.jpeg"><figcaption><a href="https://www.freepik.com/free-vector/diverse-people-set_6703775.htm#query=accessibility&amp;from_query=wcag&amp;position=4&amp;from_view=search&amp;track=sph">Image by pch.vector</a> on Freepik</figcaption></figure><blockquote>Erişilebilirlik, herhangi bir ürünün, servisin, hizmetin engelliler ve yaşlılar dâhil olmak üzere herkes tarafından ulaşılabilir ve kullanılabilir olmasını ifade eder.</blockquote>
Dünya Sağlık Örgütü’nün <a href="https://www.who.int/teams/noncommunicable-diseases/sensory-functions-disability-and-rehabilitation/world-report-on-disability">raporuna</a> göre, dünya nüfusunun yaklaşık %15'inin (1,2 milyar insan) bir tür engel ile yaşamına devam etmektedir.
Bu sebeple biz geliştiriciler olarak, bir web sitesi geliştirirken herkesin rahatça ulaşabileceği ve kullanabileceği ürünler ortaya çıkarmaya özen göstermeliyiz.
Konumuz özelinde ise erişilebilirlik, tüm insanların geliştirdiğimiz ürünü rahatlıkla kullanabilmesini, sahip olunan herhangi bir engelin geliştirdiğimiz ürünün kullanımına engel teşkil etmemesini temsil etmektedir.
Bunu sağlayabilmek için World Wide Consortium’un (W3C) Web Erişilebilirlik Girişimi (WAI), <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web İçeriği Erişilebilirlik Yönergelerini (WCAG)</a> oluşturdu. Biz geliştiriciler, web erişilebilirliği icin bu yönergeleri takip ederek oluşturduğumuz ürünü engel sahibi insanların da herhangi bir sorun yaşamadan, cihazlarındaki erişilebilirlik araçlarının da yardımıyla, rahatça deneyimlemesini/kullanabilmesini sağlayabiliriz.
Web erişilebilirliği için daha detaylı ve farklı bilgiler için, CsTech ekibinden <a href="https://medium.com/@osmanakar_65575">Osman Akar</a>’in <a href="https://medium.com/cstech/huge-missing-part-web-accessibility-7951724158da">Huge Missing Part: Web Accessibility</a> makalesine de göz atmanızı tavsiye ederim.
<h3>Neden erişilebilirlik odaklı komponent kütüphanesi geliştirdik?</h3>
<figure><img alt="Neden erişebilirlik odaklı kütüphane geliştirdik? — Kapak" src="https://cdn-images-1.medium.com/max/800/1*XZxIIukmXpLODfRjDsOzaQ.jpeg"><figcaption><a href="https://www.freepik.com/free-vector/illustration-web-design-template_2825770.htm#query=html&amp;position=20&amp;from_view=search&amp;track=sph">Image by rawpixel.com</a> on Freepik</figcaption></figure>Aslında geliştiriciler olarak biz, bir internet sitesi oluştururken amacımıza uygun çeşitli HTML elemanlarını stillendirerek bir araya getiriyor, böylece gördüğümüz/kullandığımız internet sitelerini oluşturuyoruz.
Bu sebeple, geliştirme yaparken belli amaçlar için özelleştirilmiş bu elemanları bir araya toplayan komponent kütüphaneleri kullanıyor veya oluşturuyoruz. Bu kütüphanelerin birçoğu belirli bir tasarım diline kolayca ulaşmak ve hızlı geliştirme yapmak için kullanılıyor olsa da, bazı kütüphaneler farklı amaçlar için stillendirme içermeden oluşturulmuş olabiliyor.
Bizim de Cactus UI’ı oluştururken motivasyonumuz: CsTech olarak geliştirdiğimiz tüm web sitelerinde kullanabileceğimiz, erişilebilirlik konusunda gerekli yönetmeliklere uygun web siteleri ortaya çıkarmamıza olanak tanıyacak bir komponent kütüphanesine sahip olmaktı.
<figure><img alt="-How much? + It’s open sorce." src="https://cdn-images-1.medium.com/max/250/1*XODA5Kr9Ihpm2el1Zeus9w.jpeg"><figcaption>Image from <a href="https://imgflip.com/user/gclough">Imgflip/gclough</a></figcaption></figure>Bu ihtiyaclarımızı giderecek kütüphaneyi oluştururken geliştirici topluluğuna katkıda bulunmak istediğimiz için Cactus UI’ı açık kaynak olarak geliştirdik. 🥳
Şimdi bu amaçlarla geliştirdiğimiz Cactus UI’ı gelin daha yakından tanıyalım.
<h3>Cactus UI</h3>
<figure><img alt="Accessible Accessibility and behavior is implemented according to WAI-ARIA Authoring Practices, including full screen reader and keyboard navigation support. Adaptable All components are designed to work with mouse, touch, and keyboard interactions. They’re built with an accessibility first approach. Customizable Easy to customize with inline style, CSS files and libraries like styled-components." src="https://cdn-images-1.medium.com/max/1024/1*XogKgpNWrvkiHTHb_ZywAA.png"><figcaption>Cactus UI — Features (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure><a href="https://cactus-ui.ciceksepeti.dev/">Cactus UI</a>, Web İçeriği Erişilebilirlik Yönergeleri (WCAG)’ne uygun şekilde geliştirilmiş 13 komponent ile birlikte çeşitli custom-hook’lar içeren, minimum stillendirmeye sahip bir React kütüphanesidir.
<figure><img alt="Components: Accordion Alert Alert Dialog Checkbox Dialog Focus Trap Listbox Popover Portal Radio Group Skip Nav Tabs Visually Hidden" src="https://cdn-images-1.medium.com/max/1024/1*Z8rJ4wONv7b0qG5etBIxJw.png"><figcaption>Cactus UI — Components (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure><figure><img alt="Hooks: useArray useIsCSR usePrevious useDebounce useLatestValue useForceUpdate useLocalStorage useCombinedRefs useEventListener useOnClickOutside useFindTabbableElements useFindFocusableElements useIsomorphicLayoutEffect" src="https://cdn-images-1.medium.com/max/1024/1*aSw8X_IvUgKVoc2QFyfCvg.png"><figcaption>Cactus UI — Hooks (created by <a href="https://dribbble.com/elifyardimci">@elifyardimci</a>)</figcaption></figure>Temel odak, erişilebilirlik konusunda ilkelere uygun bir kütüphane geliştirmek olduğu için, <a href="https://cactus-ui.ciceksepeti.dev/">Cactus UI</a> komponentleri doğru çalışma için gerekli minimum stillendirmeler dışında özel bir tasarım dili benimsenmeden, kullanan geliştiricinin ihtiyacı olan tasarıma göre kolayca stillendirebileceği şekilde geliştirildi. İsterseniz farklı kütüphanelerle birlikte kullanarak (<a href="https://styled-components.com/">styled-components</a> vb.) isterseniz de CSS yardımıyla tüm komponentleri tasarımınıza göre stillendirebilirsiniz.
<blockquote>Tüm komponentlerin ve hookların kullanımı için <a href="https://cactus-ui.ciceksepeti.dev/">dökümantasyon</a>u inceleyebilir, herhangi bir sorunuzun olması durumunda <a href="https://github.com/ciceksepetitech/cactus-ui">Github</a> üzerinden sorularınızı bize iletebilirsiniz.</blockquote>
Cactus UI geliştirilirken geliştirici deneyimi yüksek, implementasyonu kolay ve mümkün olduğunca esnek olması için özen gösterildi. <a href="https://cactus-ui.ciceksepeti.dev/">Cactus UI</a>’a ait bir komponenti kullanmanın ne kadar kolay olduğunu hadi bir örnekle görelim.
Hadi birlikte <a href="https://cactus-ui.ciceksepeti.dev/Components/listbox">Cactus UI — Listbox</a> komponentini projemize implement edelim.
<ol><li>Cactus UI’i projenize ekleyin:</li></ol>
<pre>// Bütün kütüphaneyi import edebilirsiniz: // Npm kullanıcıları için: npm install @ciceksepeti/cui // Yarn kullanıcıları için: yarn add @ciceksepeti/cui // ya da sadece Listbox'ı import edebilirsiniz: // Npm kullanıcıları için: npm install @ciceksepeti/cui-listbox // Yarn kullanıcıları için: yarn add @ciceksepeti/cui-listbox</pre>
2. Projenizde ilgili yerde Listbox ve ListboxItem’i import edip, çağırın:
<pre>import React from "react"; import { Listbox, ListboxItem } from "@ciceksepeti/cui-listbox"; // CactusUI'dan gelen temel stillendirmeler: import "@ciceksepeti/cui-listbox/styles.css"; // Projemize ait, özel stillendirmelerimizi iceren css dosyasi: import "./styles.css"; export function OurListbox() { return ( &lt;div className="App"&gt; &lt;p className="title"&gt;Cactus UI Listbox&lt;/p&gt; &lt;Listbox aria-labelledby="listbox-example"&gt; &lt;ListboxItem value="listbox Item 1"&gt;Listbox Item 1&lt;/ListboxItem&gt; &lt;ListboxItem value="listbox Item 2"&gt;Listbox Item 2&lt;/ListboxItem&gt; &lt;ListboxItem value="listbox Item 3"&gt;Listbox Item 3&lt;/ListboxItem&gt; &lt;ListboxItem value="Listbox Item 4"&gt;Listbox Item 4&lt;/ListboxItem&gt; &lt;/Listbox&gt; &lt;/div&gt; ); } export default OurListbox;</pre>
Tebrikler! Listbox komponentiniz hazır ve su şekilde görünüyor:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*GPDUDMXWFvvPVqgSVLmXPw.png"><figcaption>Cactus UI — Listbox default görünüm</figcaption></figure>Daha önce bahsettiğim gibi, Cactus UI sadece komponentin çalışması için gerekli temel stilleri içerdiği için görünüşü çok güzel olmasa da erişilebilirlik için gerekli tüm özellikleri barındırıyor. Örnek olarak; klavyedeki yön tuşlarıyla listbox içinde gezinebilir, enter ile seçim yapabilirsiniz. Bu hareketleriniz ekran okuyucu tarafından algılanır, focus edilen elamanın değeri sesli olarak okunabilir!
Peki bu komponenti istediğimiz tasarıma göre nasıl stillendirebiliriz? Bunun cevabı dokümantasyon sitemizde bulunan <a href="https://cactusui-documentation.vercel.app/docs/styling">stillendirme başlığında</a> mevcut. Tüm komponentleri kolayca stillendirmeniz için size bir çok css-selector sunmaktayız, Listbox komponenti için <a href="https://cactus-ui.ciceksepeti.dev/Components/listbox#styling">bunlar:</a>
<figure><img alt="Cactus UI Listbox CSS Selectors Tablosu" src="https://cdn-images-1.medium.com/max/939/1*9nI4_Cgz01LaGGUNbTjkRg.png"><figcaption>Cactus UI — Listbox / CSS Selectors</figcaption></figure>Bu css-selector’leri kullanarak bir .css dosyası ile komponentimizi özelleştirelim:
<pre>[data-cui-listbox-button] { width: 350px; height: 48px; font-size: 16px; font-weight: 600; color: #93b74d; background-color: #48625b; } [data-cui-listbox-arrow] { color: white; font-size: 16px; margin-right: 4px; } [data-cui-listbox-popover] { overflow: hidden; border-radius: 4px; background-color: #48625b; border: 1px solid rgb(171, 202, 171); } [data-cui-listbox-item] { color: #9bc14f; font-weight: 600; padding: 12px 10px; } [data-cui-listbox-item][data-active="true"] { color: #1c7450; background-color: #d6dfc3; }</pre>
Css ile stillendirme sonrası komponentimizin son hali:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*fKgrt26cdOHL2gJzWR1Lhw.png"><figcaption>Cactus UI — Listbox Stillendirilmiş Görünüm</figcaption></figure>İşte bu kadar kolay! Cactus UI’da bulunan bir komponentin nasıl kullanılacağını, stillendirme ile ilgili detayları ve örnekleri ilgili komponentin <a href="https://cactus-ui.ciceksepeti.dev/">dokümantasyon</a> sayfasında bulabilirsiniz.
Komponente ait dokümantasyon sayfasında komponenti test etmeniz için bir test ortamı da bulunmakta!
<h4>Açık Kaynak Kod — Katkı</h4>
Herkesin eşit şekilde faydalanabildiği internet siteleri yaratmak için erişilebilirlik odaklı geliştirilen Cactus UI geliştirici topluluğuna değer katmayı, sizlerin katkılarıyla birlikte bu değeri büyütmeyi amaçlıyor.
Bu sebeple yaşadığınız problemlerle ilgili soruların yanısıra, fikirlerinizi, eksik gördüğünüz veya geliştirmek istediğiniz yerlerle ilgili katkılarınızı da bekliyoruz.
Cactus UI — Github: <a href="https://github.com/ciceksepetitech/cactus-ui">https://github.com/ciceksepetitech/cactus-ui</a>
Tekrar görüşünceye dek, teknoloji ile kalın.
Oğuzhan Sofuoğlu
Frontend Developer
Kaynaklar:
<ol>
<li><a href="https://www.w3.org/WAI/standards-guidelines/wcag/">https://www.w3.org/TR/WCAG21/</a></li>
<li><a href="https://www.freecodecamp.org/news/web-accessibility-best-practices-and-checklist/">https://www.freecodecamp.org/news/web-accessibility-best-practices-and-checklist/</a></li>
<li><a href="https://medium.com/cstech/huge-missing-part-web-accessibility-7951724158da">https://medium.com/cstech/huge-missing-part-web-accessibility-7951724158da</a></li>
<li><a href="https://cactus-ui.ciceksepeti.dev/">https://cactus-ui.ciceksepeti.dev/</a></li>
</ol>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9a17cde0cf0b" width="1" height="1" alt=""><hr>
<a href="https://medium.com/cstech/cactus-ui-9a17cde0cf0b">Cactus UI — Erişilebilirlik Odaklı React Komponent Kütüphanesi</a> was originally published in <a href="https://medium.com/cstech">ÇSTech</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cactus UI — Erişilebilirlik Odaklı React Komponent Kütüphanesi

<h3>Patika.dev &amp; Çiçeksepeti Bootcamp Deneyimlerim</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*4EoxVXP-g92XdFRdnyZbBA.png"><figcaption>Header</figcaption></figure>Herkese selamlar,
Bu yazımda katılmaya hak kazandığım ve çok güzel tecrübeler edindiğim ÇiçekSepeti &amp; Patika.dev React Bootcamp’i hakkında tecrübelerimi ve biraz da kendi hikayemi paylaşacağım.
Önce benden başlayalım; 27 yaşında, inşaat mühendisi ve yaklaşık 3 sene inşaat sektöründe çeşitli pozisyonlarda çalışmış birisiyim. Haziran 2021'de ise hayalim olan yazılım alanına geçmeye karar verip sektörden ayrıldım. Bu tarihten itibaren günde yaklaşık 15 saat çalışarak yazılım sektörünü tanımaya, kendimi geliştirmeye çalıştım. Yaklaşık 1 ay boyunca, yazılım alanı hakkında ufak tefek fikirler edinmişken Front-End tarafında kendimi geliştirmeye karar verdim.
Yoğun CSS, JavaScript ve React çalıştığım dönemde patika.dev’i keşfettim. Patika bu işe yeni girenler için deneyimlediğim en iyi rehberlerden biri, kendini geliştirmek isteyenler içinse muhteşem bir eğitim içeriği deposu. Aynı zamanda yazılımcı arayan şirketlerle birlikte bootcampler düzenleyen, onlara insan kaynakları hizmeti sağlayan bir oluşum. Bootcamp’ler, etkinlikler ve eğitimler ise tamamen ücretsiz. Bende Patika’da önce Front-End Patikasında ilerlemeye başladım. Bir çok şey öğrendim ve küçük çaplı bir çok proje geliştirdim. Patika’da eğitim içerikleri gerçekten kaliteli ve öğretici. Bolca ödevlerle, takıldığınız yerlerde destek alabileceğiniz bir Discord kanalı gibi muazzam şeyler sunuyor size.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*R-wTzpyiGIeY7j-QfWxs_w.png"><figcaption>Bootcamp İlanı</figcaption></figure>Çalışmaya devam ederken açılan Bootcampler’de ÇiçekSepeti React Bootcamp’ini görüp başvurdum. Online teknik mülakat ve ik görüşmesi sonrası kabul aldığımı öğrendim. Burada beni en çok mutlu eden şey ise ÇiçekSepeti’nin beklentisiydi; aslında bilgimi değil, isteğimi,ilgimi görmek istediler ve beni tanımaya çalıştılar. Bu yüzden tamemen sohbet havasında geçen, bugüne kadar katıldığım en keyifli mülakatı yaşadım.
Aslında bootcamp başlarken büyük endişelerim vardı. Sonuçta sektör dışından gelen ve ilk kodunu daha bir kaç ay önce yazan biri olarak yeterliliğim konusunda tereddütlerim vardı. Sonuçta katılımcı arkadaşların bir çoğu hem ilgili bölüm mezunu hem de sektörde çalışmakta olan insanlardı. Hem patika.dev ekibi (<a href="https://medium.com/u/d05af8bea99e">Özge Açık</a> ve <a href="https://medium.com/u/93db28ee1e27">Furkan Tolga Yüce</a>), hem bootcamp eğitmeni, hem Çiçeksepeti ekibi bootcamp’in ilk günü muhteşem bir enerji ile bizi karşıladı. Bootcamp’te görev alan insanları tanıyınca aslında endişelerim hafifledi ve 7 haftalık dolu dolu eğitim süreci başladı.
Sizlere yavaş yavaş içerideki ortamı anlatayım. Eğitmen <a href="https://medium.com/u/c5555b70e6ed">Çağlayan Yanıkoğlu</a>, hayatında ilk kez bootcamp eğitmenliği yapan, bunu kendisi söylemese kimsenin aklından geçmeyeceğine emin olduğum, enerjisi hiç bitmeyen, “7 haftada nasıl bitecek acaba ?” diye düşünülen müfredata bile ekstra konular eklemeyi başarmış muhteşem bir eğitmen. Asistanlar aslında gönüllü ve bootcamp mezunu arkadaşlar. Ama yaptıkları iş gönül işinden çok daha büyük. <a href="https://medium.com/u/e3fa644db42f">Ercüment Laçın</a> ilk ödevde kodumu satır satır okuyup yorumlar yapınca yaşadığım şaşkınlığı anlatamam. Hafta içleri düzenlenen Office Hour’larda katılımcıların eksik hissettiği, zorlandığı her konu asistan arkadaşlar tarafından tekrar işlendi, konuşuldu yol gösterildi. Ne zaman sıkışıp kalsanız yardıma koşan ve bunu gerçekten yürekten yapan bir ekip var içerde. Bootcamp’te görev alan herkes siz öğrenin diye sizden çok uğraşıyor, içerideki aura öğrenmek için o kadar güzel ki öğrenim hızınızın geldiği noktaya bazen inanamıyorsunuz. Bootcamp’e katılan 35 arkadaşım ise, özenle seçilmiş kişilerdi. Herkesin bilgi seviyesi aynı olmasa da muhteşem bir ortam oluştu içerde. Çok fazla insanla tanışmış oldum. Onlardan çok fazla şey öğrendim, bazılarına bir şeyler öğretmeye çalıştım. Başlarken sahip olduğum bütün şüpheler, eğitmen, asistanlar, patika ve ÇiçekSepeti ekibi ile geçirdiğim bir kaç hafta sonrasında ise tamamen yok oldu.
<a href="https://www.linkedin.com/feed/update/urn:li:activity:6843141220290576384/">CicekSepeti.com / Lolaflora.com on LinkedIn: Patika.dev işbirliği ile başlatmış olduğumuz Frontend Bootcamp'imizdeki</a>
Hafta sonları gerçekleşen yoğun 10 saat eğitimin ardından hafta içi işlenen konuları derinlemesine öğrenmek, takıldığım yerlerde destek alabilmek, ödevlerle projeler geliştirmek hem çok keyif verici hem de çok öğreticiydi.
Ve 7 hafta göz açıp kapayıncaya kadar geçti, şu sıralar bitirme projesi ile süreç devam ediyor. Bu 7 hafta hayatımın en verimli öğrenim süresini yaşadığım dönem oldu. O kadar çok şey öğrendim ki hala gerçek olduğuna inanamıyorum. Ve aynı zamanda o kadar çok eksiğimi gördüm ki to-do list’im artık hiç olmadığı kadar kabarık :)
ÇiçekSepeti ekibi (<a href="https://medium.com/u/ef0a84cf7f9d">ÇSTech</a>, <a href="https://medium.com/u/6ebd550442f4">Ciceksepeti</a>) tüm bu süreç boyunca Discord kanalında bulunarak, workshoplar düzenleyerek ve bazı office hourslara katılarak ve süreçle ilgili yanınızda olmaya devam ediyor. Çalışma ortamlarını, ekibi, ve yaptıkları işi öğreniyor, merak ettiğiniz noktaları sorabiliyorsunuz. Mottoları ‘Grow Together!’ ve bütün süreç gerçekten bu motto ışığında ilerliyor. Kariyerimin başında böyle bir deneyim elde edebildiğim için çok mutluyum. ÇiçekSepeti’ni daha yakından tanımak, bu tarz etkinliklerden haberdar olmak için <a href="https://www.linkedin.com/company/ciceksepeti-com/">LinkedIn’den takip edebilirsiniz</a>.
Şuan başvurusu aktif olan Test Otomasyon Bootcamp’ine de buradan ulaşabilirsiniz:
<a href="https://www.linkedin.com/embed/feed/update/urn:li:share:6853637448002613248">Patika.dev on LinkedIn: #patikadev #ciceksepeti</a>
<a href="https://medium.com/u/9ed172d44ff">Patika.dev</a> benim son zamanlarda yaptığı işten en çok etkilendiğim organizasyon. İnsanlara ücretsiz bir şekilde kaliteli eğitim içerikleri, bootcamp’ler ve çeşitli etkinlikler gerçekleştirerek destek olmaya devam ediyorlar. Hayatımı değiştirdiler ve değiştirmeye de devam ediyorlar. Eğer siz de kendinizi yazılım alanında geliştirmeye çalışıyorsanız mutlaka uğramanız gereken bir yer. Girip bakmanız için <a href="https://app.patika.dev/">siteyi </a>ve<a href="https://www.linkedin.com/company/patikadev/mycompany/"> LinkedIn hesabını</a> buraya bıraktım :)
Son olarak, eğer benim gibi daha yolun başındaysanız veya bu alanda kendinizi geliştirmeye çalışıyorsanız bootcampler size muhteşem deneyimler, muhteşem insanlar ve muhteşem bilgiler katacak. Eğer zaten kabul aldığınız bir bootcamp öncesi bunu okuyorsanız da muhteşem haftalar sizleri bekliyor. Her anından keyif almaya bakın :)
Bu süreçte emeği geçen herkese çok teşekkür ediyorum.
Zaman ayırıp okuduğunuz için teşekkürler.
Oğuzhan
İletişim için : <a href="http://o.sofuoglu@yahoo.com/">Mail </a>| <a href="https://www.linkedin.com/in/oguzhan-sofuoglu/">LinkedIn</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=7fcf83b220db" width="1" height="1" alt=""><hr>
<a href="https://medium.com/patika-dev/%C3%A7i%C3%A7eksepeti-bootcamp-deneyimlerim-7fcf83b220db">Çiçeksepeti Bootcamp Deneyimlerim</a> was originally published in <a href="https://medium.com/patika-dev">Patika.dev</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Çiçeksepeti Bootcamp Deneyimlerim

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cQdVSRohJTqAXiRRoGKKaQ.png"><figcaption>Header</figcaption></figure>Herkese selam ,
HTML’in makyajı ve bir front-end developer’ın olmazsa olmazı CSS. Yazılıma başladığım günden beri CSS’i öğrenmeye, kendimi geliştirmeye çabalıyorum. Bu yüzden takip ettiğim kaynakları, neler yaptığımı bu yazıda sizlerle paylaşıcam. Bende bu konuda hala öğrenci olduğum için bu yazının bir rehber değil tavsiyeler içeren ve kendi uyguladıklarımdan oluşan bir yol haritası olduğunu lütfen unutmayın. Öncelikle kesinlikle kullanmamız gereken 3 temel kaynağı, sonra izlediğim yolu en son olarak da ekstra takip ettiğim kaynakları sizlerle paylaşıcam. Keyifli okumalar 😊
<h3>Hadi başlayalım,</h3>
Öncelikle CSS yazan herkesin mutlaka takıldığı her konu için başvurması gereken iki adres var:
1) MDN Web Docs — <a href="https://developer.mozilla.org/en-US/">https://developer.mozilla.org/en-US/</a>
2) W3Schools — <a href="https://www.w3schools.com/css/">https://www.w3schools.com/css/</a>
MDN detaylı bir CSS dökümantasyonu içeriyor. CSS ile aklınıza gelen her şeyi içeren bir el kitapçığı da diyebiliriz. Bizim için en büyük ansiklopedi.
W3Schools ise aynı mantıkta çalışan ama daha basit örneklerle aradığınız şeyi size açıklayan/anlatan muhteşem bir kaynak.
Mesela CSS Transition ile ilgili bir şey takıldı aklınıza ve Google’a gidip “CSS Transition” yazdınız, karşınıza gelen ilk iki sonuç zaten bu iki site olacaktır.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/906/1*ocFRjQ1Jx3rld53CSz59SA.png"><figcaption>CSS Transition Google Result</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6UItr5zDxB6eqHwLxtMDuA.png"><figcaption>W3Schools Transitions</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/872/1*x1osvQrKyBf4etGl_i7-ZQ.png"><figcaption>MDN Transitions</figcaption></figure>Şimdi en önemli iki kaynağımızı cebimize koyduk. Sırada ise içinde gezmeyi en çok sevdiğim kaynak var: css-tricks.com.
CSS-TRICKS, diğerleri gibi CSS ile ilgili dökümantasyon konusunda aradığınız her şeyi size sunabilir ama daha fazlası var. Bu muhteşem kaynak içinde çok güzel guide’lar barındırıyor. Flexbox, Grid, MediaQueries gibi çok önemli konularda her şeyi açıklayan, örneklerle destekleyen çok güzel kaynaklar hazırlamışlar. Ben flex ile ilgili her şeyi buradan öğrendim, öğrenmeye devam ediyorum.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*rJJzJjGphYnC283OFKhFyg.png"><figcaption><a href="https://css-tricks.com/snippets/css/a-guide-to-flexbox/">A Complete Guide to Flexbox from CSS-Tricks</a></figcaption></figure><h3>Demirbaşlar tamam. Sırada uygulama var;</h3>
Tamamen sıfırdan başlayacaksak eğer gideceğimiz ilk yer <a href="http://patika.dev/">patika.dev</a> olmalı. Patika.dev içindeki Front-End Patikasında internette bulabileceğiniz en güzel CSS eğitimlerinden birini bulacaksınız. Önceliğimiz bunu ve eğitim ile ilgili verilen tüm ödevleri tamamlamak. Hemen ardından Youtube da Yazılım Bilimi kanalının hazırladığı çok güzel bir video var (<a href="https://www.youtube.com/watch?v=y745R3Lv9WI">buradan </a>ulaşabilirsiniz), Onu takip edip eğitmen ile birlikte yapmanızı tavsiye ederim. Bunlar bizim CSS’e ilk adımı atmamızı sağlayacaktır.
Temel eğitimimizi aldık fakat hala çok yeniyiz ve öğrenmemiz gereken hala çok şey var. Yazılım dünyasında izlediğimiz video, okuduğunuz kaynak (ne kadar kaliteli olursa olsun) biz onu kendimiz yeniden yazmadıkça anlamsız kalacaktır. Bu işin temelinde yazmak, denemek, yanılmak ve yılmadan uğraşmak var. Peki biz ne yazıcaz?
Ben tam bu noktadayken bir yer keşfettim adı -&gt; YOUTUBE 😊.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/480/1*bEeBuPIpQdwMlXyzPaE03g.gif"><figcaption><a href="https://giphy.com/gifs/theoffice-the-office-tv-episode-818-vKHKDIdvxvN7vTAEOM">Sorce</a></figcaption></figure>Youtube’da “CSS Clone” diye arama yaptığımızda karşımıza günlük olarak girdiğimiz çoğu uygulamanın CSS Clone Tutorial’larına erişebiliyoruz. Burada önemli olan nokta hazır kütüphane (bootstrap,antd, semantic UI gibi gibi…) kullanmayan videoları seçmek.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*wm-JD65ov9JhQZVv6thbTQ.png"><figcaption>Clone CSS Results on Youtube</figcaption></figure>Ben önce bunları izleyerek, eğitimci ile aynı anda yazmaya çalışıyorum. Bu sırada yazılımcının kullandığı araçları VS Code Eklentileri, Dev Tools (hani tarayıcıda f12'ye basılınca açılan şey)kullanımı, Tarayıcı eklentilerini de lütfen dikkate alın. Sonra ilk fırsatta videosuz şekilde tekrar aynı tasarımı ortaya çıkarmaya çalışıyorum. Takıldığım yerlerde de demirbaş listemizde ki 3 kaynak (MDN,W3Schools,CSS-Tricks) sorunumuzu muhakkak çözüyor. Böyle düşe kalka, araştıra araştıra öğrenmeye devam ediyoruz.
Peki neden neden ilk olarak hazır kütüphaneleri kullanarak başlamamalıyız?
Ben geliştirdiğim ilk projelerde hazır kütüphaneler kullandım, çünkü takip ettiğim eğitimlerde öyle yapılıyordu. Fakat iyi CSS bilmeden bu kütüphaneler ile çalışmak tam olarak ortaya çıkarmak istediğiniz tasarıma engel oluyor. Saf CSS kullanımı ile çok daha özgürüz. Hatta ne kadar iyi CSS biliyorsam hazır kütüphaneleri kullanırken de aynı ölçüde rahat ettiğimi hissediyorum. Bu yüzden CSS’de ilerledikçe hazır kütüphanelerden alacağımız verimi de arttırmış oluyoruz. Zaten ilerleyen süreçte bu kütüphaneleri ihtiyaçlarımız doğrultusunda kullanmaya başlayacağız.
<h3>Şimdi gelelim kullandığım ekstralara;</h3>
1) <a href="https://www.frontendmentor.io/challenges">FrontendMentor</a> : Bu sitede challenges kısmında yapmayı deneyebileceğiniz ilginç bir çok tasarım/proje var. Bunlarla uğraşmak hem çok öğretici hem çok zevkli.
2) <a href="https://colorhunt.co/">ColorHunt </a>: Bu site tasarımlarımızda kullanmamız için renk paletleri araştırmak, üretmek için faydalanabileceğimiz bir adres. Tasarımınızı güzelleştirmek için güzel renkler şart!
3)<a href="https://htmlreference.io/"> HtmlReference:</a> Bu site tüm HTML elementleri ile ilgili bilgileri barındırıyor. Neden kullanıyorum? Örneğin: “&lt;p&gt; elementinin display özelliği neydi yaa?” diye düşündüğüm zaman :).
4) <a href="https://www.google.com/search?client=firefox-b-d&amp;q=colorzilla">ColorZilla </a>: ColorZilla hem Firefox, hem Chrome için bir tarayıcı eklentisi. ColorZilla bulunduğunuz web sayfasında merak ettiğiniz bir rengin kodunu öğrenmenizi sağlıyor. Muhteşem!
5) <a href="https://yoksel.github.io/url-encoder/">SVG-URL Encoder </a>: CSS içinde inline SVG kullanacaksam (mesela search bar içine ikon yerleştirmek istediğimde) bu tool aracılığıyla hemen dönüşüm yapıp kullanabiliyorum.
Burada StackOverFlow’u yazmadım çünkü o yazılımla ilgili tüm konularda bizim elimiz,kolumuz olmalı :)
<h3>Son olarak,</h3>
Kısa tecrübelerimden çıkardığım sonuç şu: CSS’de gelişmek için tek yol yazmak. En azından kendim için işe yarayan tek şeyin bu olduğunu söyleyebilirim.
Kodla kalın,
Oğuzhan.
Bu yazıda bulunan kaynaklara ekleme yapmak, tavsiye vermek isteyenler için de iletişim adresim asağıda ve kapım hep açık!
Bana ulaşabileceğiniz iletişim adreslerim,
LinkedIn:<a href="https://www.linkedin.com/in/oguzhan-sofuoglu/">https://www.linkedin.com/in/oguzhan-sofuoglu/</a>
Email: o.sofuoglu@yahoo.com
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=c9a267411277" width="1" height="1" alt="">

CSS Yol Haritam

<h3>JavaScript Senkron — Asenkron Karmaşası</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*xKrJilh6on_rNPN3mmKWSQ.png"></figure><h3>Hadi başlayalım,</h3>
Herkese merhaba! Javascript öğrenmeye çalışırken en çok zorlandığım konulardan biri olan “Asynchronous” yani asenkron çalışmanın mantığını elimden geldiğince basitleştirip açıklamaya çalışacağım.
Javascript öğrenmeye başlayan herkes kullandığı kaynaklarda şöyle bir tanıma muhakkak denk gelmiştir: “ Javascript single-thread ve eş zamanlı (synchronous) bir yazılım dilidir…”. Bunu öğrenip devam ediyoruz ve sonra öğrenmenin ilerleyen süreçlerinde kullanmaya başladığımız async-await/promises-then gibi ifadeler ile akıllar karışmaya ve bu ilk tanım çoğu insan için anlamsızlaşmaya başlıyor.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/498/1*7LzKhY4wKRADFRyMFrLSBg.gif"></figure>Şimdi gelin hep birlikte Javascript’te bu karmaşaya ne sebep oluyor inceleyelim.Single-thread ve synchronous dedik, yani JS her yazdığımız kod bloğunu sırayla okuyor, birini tamamlamadan diğerine geçmiyor. Bunu anlamamız için küçük bir örnek aşağıda;
<a href="https://medium.com/media/4aaabad7687f48c03b7ad31877eb0286/href">https://medium.com/media/4aaabad7687f48c03b7ad31877eb0286/href</a>Bu kodun çıktısını birlikte inceleyelim, tarayıcımızı açtığımızda;
<figure><img alt="" src="https://cdn-images-1.medium.com/max/895/1*YSWfXZMtmNURYsZ_FsPOoA.png"><figcaption>Output 1</figcaption></figure>foo() fonskiyonumuz çalıştı konsola 2 satır logladı ve alert verdi. Biz “Tamam” butonuna basmadığımız sürece de sayfada veya konsolda herhangi bir değişiklik olmuyor. Hadi “Tamam” butonuna basalım;
<figure><img alt="" src="https://cdn-images-1.medium.com/max/861/1*OBhT_kOo8kT06X-yVoRdiw.png"><figcaption>Output 2</figcaption></figure>Tamam butonuna tıklamamızla birlikte foo() fonksiyonu tamamlandı ve ondan sonra gelen bar() fonksiyonumuz çalışıp konsola 2 satır logladı. Buradan JS’in aslında single-thread olduğunu net bir şekilde anlayabiliyoruz. Biz “Tamam” butonuna basmadan bar() fonksiyonumuz çalışmadı.
<h3>CallStack nedir?</h3>
Şimdi işleri biraz daha karmaşık hale getirelim;
<a href="https://medium.com/media/9ca32f9d16984f961cd47704be1eaa86/href">https://medium.com/media/9ca32f9d16984f961cd47704be1eaa86/href</a>Şimdi öncelikle bu kodun çıktısına bakalım, sonra da gelin birlikte anlamaya çalışalım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/647/1*12QLCYNndv8eRy25ADY4TA.png"><figcaption>CallStack 1</figcaption></figure>Biz foo() fonksiyonunu invoke ettik ve foo() içindeki ilk satır konsola “Foo” logladı. Hemen ardından ise sıradaki satırda ki bar() fonksiyonu çağrıldı ve bar() fonskiyonunun ilk satırı çalışıp konsola “Bar” yazdırdı. Ve bar() fonksiyonu 2. satırına geçip baz() fonksiyonunu çalıştırdı. Şuan JS runtime’da şöyle bir görüntü var:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/320/1*S0EuKEFCLEApItWVjwoJYA.png"><figcaption>CallStack 2</figcaption></figure>Şemada gördüğümüz “stack” alanını aslında bir konser sırası gibi düşünebiliriz. Ama stack mantığında işler biraz ters yürüyor ilk giren son çıkıyor :) Şimdi bizim programımızın tamamlanması için sırasıyla Baz() -&gt; Bar() -&gt; Foo() tamamlanmalı. Baz tamamlanmadan Bar, Bar tamamlanmadan da Foo tamamlanamaz. İşte tam olarak bu yüzden “ Javascript single-thread ve eş zamanlı (synchronous) bir yazılım dilidir…”. Peki o zaman javascript’te Asynchronous nedir? Bu işleyişi nasıl manipüle ediyoruz? Ve senkron olmayan işlemleri yaparken arkaplanda neler dönüyor? Gelin birlikte öğrenelim.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/931/1*kZzfHAE1mabXwbTrnmaFew.png"><figcaption>JavaScript Engine</figcaption></figure>Biz sonucunu almamızın uzun süreceğini bildiğimiz, veya bir sebeple sıraya sokmak istediğimiz işlemleri senkron olarak çalıştırmak isteriz. Örneğin fetch ile bir API’a istek gönderdiğimizde dönüşü beklerken programımızın devam etmesini ve data hazır olduğunda kullandığımız yere onu göndermesini isteriz. Bunu yapmamız için JS’in muhteşem bir sırası daha var CallBack Queue. Eğer biz kod yazarken JS’e yazdığımız fonksiyonun uzun süreceğini belirtebilirsek JS o fonksiyonu önce Web API’ya aktaracak orada işlem tamamlanırken kendisi stack’te bulunan işlerini yapmaya devam edecektir. Web API’da tamamlanan görev ise CallBack Queue’ya aktarılarak Stack’te ki işlemlerin tamamlanıp sıranın kendisine gelmesini bekler.
<h3>Son olarak,</h3>
Özet olarak son örneğimizi konuşalım ; konsola“ hello world” yazacak bir setTimeOut() fonksiyonu hayal edelim.
<a href="https://medium.com/media/2cbd0b6abaf1f369e8b9a66f0b69b023/href">https://medium.com/media/2cbd0b6abaf1f369e8b9a66f0b69b023/href</a>JS bu fonksiyonun sırası geldiğinde çalıştırıp Web API’ya aktarır ve stackte kalan işlemlerine devam eder. Web API kısmında setTimeout’a karşılık bir 2000ms’lik bir kronometre görevi oluşur. Bu zamanlayıcı görevini tamamlayıp sıfır olduğunda ise JS bunu CallStack’e aktarır. Stackte bulunan görevlerin tamamlanmasının ardından bu görev Stack’e alınarak taşıdığı “Hello World” komutunu konsola yazdırır.
Javascript’in bu özelliğini data çekerken, event yönetirken ve timerlarda kullanmaktayız.
Sonuç olarak Javascript hala “ …single-thread ve eş zamanlı (synchronous) bir yazılım dilidir…”. Ama biz çeşitli araçlarla onu manipüle edip istediğimiz şekilde çalışmasını sağlıyoruz.
Sevgilerimle,
Kodla kalın.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=38607d030d8f" width="1" height="1" alt="">

Posts