
# Trunk-based Development

In the earlier days of software development, tracking and managing changes to the code was not this efficient. Developers had two versions of the software, which they can track changes or reverse them.

As development environments matured, we now have two main development models to help development teams work more efficiently: Gitflow and trunk-based development.

![Trunk-based Development](trunk-based-development.png)

## What is trunk-based development?

Assuming you are familiar with the Git community, “trunk” actually corresponds to the “main” development branch, in the source control branching model.

In trunk based development, the trunk is assumed to be always ready to deploy and without issues. Developers make smaller and faster updates to the trunk. It has short-lived branches with smaller commits.

## Benefits of trunk-based development

In this version control management practice, developers merge smaller updates to the trunk. As a result, you can guess that this practice accelerates the continuous integration process. Because the branches with smaller commits will be integrated into the shared branch frequently. This makes it easy to deploy and fix the code quickly.

Code reviews will be easier, because the small changes will be easier to inspect. Complex merges and conflicts will be avoided as well.

Also, the codebase will always be releasable which results in continuous delivery. Since automated tests run after each time new code is merged into the trunk, the project will be ensured to work at all times without issues. So, the team has the ability to frequently deploy to production.

## Disadvantages of trunk-based development

You might already think that this approach could have some drawbacks, due to manual effort to maintain the trunk will be increased.

Yes, developers need to wait for the automated builds and tests before merging these small chunks.

And regression tests don’t happen on every merge.

## Introducing feature flags

Feature flags, also known as feature toggles, help us to enable turn features on or off. This is one of the parts that should be taken care of, that if some code is committed to the trunk which has not completely finished developing, the end user should not see this change on live. So, toggling this feature is crucial at this point, to hide the unfinished code in the deployment without users seeing it.

## Gitflow vs trunk-based development

In Gitflow, there are long-lived feature branches. Merging into the main branch is delayed. And there are more branches to manage, which increases the complexity.

It is suitable for teams who favor parallel development of the long-lived feature branches. If longer periods between the releases is tolerated, Gitlow could be adapted.

When you have a new application and you are trying to rapid the development, trunk-based development will be a better choice though. In order to make the application running with minimal changes and functionality, it makes more sense to allow the developers to integrate this functionality faster.

Another criteria to consider when choosing between version control management, is the experience of the development team. If you have a lot of junior developers in the team, consider the mentoring and reviewing process. But as much as the experience level is high, trunk-based development can be chosen.

## Conclusion

All in all, trunk-based development comes with a lot of advantages. It helps the development teams to iterate rapidly and improves collaboration in the team, because it speeds up the reviews and promotes faster integration. Thus, developers have more control in every step of the code change and how the software is delivered at the end.

---

## _Read This Article On Medium_

_[Trunk-based Development - Medium post by me](https://medium.com/@ilkyaz.arabaci/trunk-based-development-a8ec6b3abed0)_

_Cheers,_

_ilkyaz_


Trunk-based Development


# Rendering On The Web: CSR, SSR, SSG

There are different ways of how the web page can be rendered on the browser. App performance can be improved by selecting the right rendering method. This means, different rendering methods might be more suitable for different purposes. In order to have the best user experience, understanding the main differences between these rendering methods is crucial as a developer.

![Rendering On The Web](rendering-on-the-web.png)

## Client-Side Rendering (CSR)

With client-side rendering, web pages are generated on the browser. So, the **content of the page is prepared on the client**.

When a user visits the web page and makes a request to the server, server provides a fairly empty HTML with JavaScript links included. You can experiment this in your own React app. When you inspect the page which is rendered on the client-side, you will see that it is pretty empty first and it only has the basic HTML skeleton with an entry point, a div with id root typically, into which the app is loaded afterwards.

Then, the browser downloads JavaScript code and executes it. Executed code will be used for rendering the page that the client requested initially.

In this case, React does all that rendering on the client. Page is generated relying on the JavaScript code, which is processed before the content is visible.

**Until all the JavaScript code is fetched** and the browser compiled everything before rendering, **the content will not be ready**. This works well, with a reliable internet connection.

But, when could this be an issue?

Suppose that you are rendering a list with a lot of items. Since fetching the data only begins once the JavaScript code is executed on the client, user might see a loading or flickering page for a while. If you add seconds to the load time of these list items, it would be a poor user experience.

Or consider a public facing app with a lot of content that should be found through search engines. Some JavaScript content might be missed from the search engine crawlers with client-side rendering.

However, you should **use client-side rendering when you need to update data frequently or when you don’t want to pre-render the page**.

### CSR - Performance

Initial load time is increased and **client-side rendered pages can be slow to load**. Because, all of the JavaScript code should be fetched as mentioned above. Often, these JavaScript downloads are heavy.

### CSR - SEO

There is a **risk of partial indexing with client-side rendering**. _Indexing_ is the process of storing web pages in the search engine’s database. _Partial indexing_ is when some of your web pages have not been listed fully on the search engine.

## Server-Side Rendering (SSR)

With server-side rendering, the **content of the page is prepared on the server instead of the client**. So, the JavaScript code is rendered on the server.

When a user visits the web page and makes a request to the server, the server renders HTML with the updated content and the page is fully pieced on the server. Then, this fully rendered HTML page is sent back to the client.

![Server-Side Rendering](server-side-rendering.png)

_Server-Side Rendering: Diagram from [nextjs.org](https://nextjs.org/learn/basics/data-fetching/two-forms)_

Now, think about the cases mentioned above where client-side rendering could be problematic and realize how server-side rendering would be a better solution for these specific cases.

**Server-side rendering solves issues about initial load and it is great for search engine optimization**. SEO determines how high your site ranks in the search engine results and how accessible your content is. _Crawling_ in terms of SEO is the discovery process of pages and links that lead to more pages. Crawled content is eligible to appear in _Google’s index_, which is a large database that stores information on each website that has been scanned. Since JavaScript code is rendered on the server, it is beneficial for both search engine crawlers and for the users who will get a faster page experience, which will enhance the user experience.

Search engine crawlers won’t have to wait until requested resources become available before being able to view the whole page, but they will get a full rendered page from the very beginning instead. As a result, you can always be sure that you get the latest and the most recent content from the server.

But also realize that, the server has to do the work all over again at every request and that requires higher computing power. It can be resource intensive and expensive. When your users have less internet bandwidth, it could impact them more.

### SSR - Performance

It greatly improves performance and the user experience. Initial page load takes less time.

### SSR - SEO

Server-side rendering is more favorable for search engine optimization because rendering is done on the server. When we are talking about SEO, page loading speed is a factor. For Google, _Largest Contentful Paint (LCP)_ is an important metric, which measures the time the web page takes to display the largest ready and interactable content to the user. With SSR, _Largest Contentful Paint_ metric will be optimized, because the content will be already prepared on the server. It can make a significant difference to your web page’s ranking in the search engine results.

### SSR - Cost

There is an extra cost coming with the server-side rendering, because extra rendering is done on the server. That means **extra computing resources**.

## Static Site Generation (SSG)

With static site generation, the **data is pre-fetched once during build time**. It is important in terms of performance. Frameworks like Next.js provide _template engines_, which enables you to use template files in your app to build multiple static pages with one template. Therefore, it saves time.

![Static Site Generation](static-generation.png)

_Static Generation: Diagram from [nextjs.org](https://nextjs.org/learn/basics/data-fetching/two-forms)_

The key point here is that, the page will be rendered and generated during the build time, which is the main difference from CSR and SSR. Since the page is rendered during the build time and the hard work is done beforehand, we can refer static site generation as a **pre-rendering method**.

As it can be understood from the name itself, you might **consider it for the static web pages** where the content never changes or updated once in a while. A _static web page_ is rendered on the browser exactly as stored. So, the content does not change based on authentication or authorization.

As a result, this rendering method also should be preferred for some cases. Because it won’t work for a use case such as when you have dynamic pages. A dynamic page will display different content according to the results of the request coming from the user, due to it coming from an API, while retaining the same layout and design. However, **with SSG, you have to pre-generate every accessible URL for all possibilities**.

### SSG - Performance

Since rendering is not done on the browser and the content is generated at build time, it is relatively fast.

### SSG - SEO

Web pages can be crawled and indexed by search engines easily. Because static site generation will pre-render the content.

## Conclusion

You can stick to **client-side rendering** for the pages that have dynamic data and complex UI, when you expect high number of users. However, client-side rendering is often not enough. Especially for when you depend on SEO.

You can use **server-side rendering** to target SEO ranking and improve the user experience and performance. Initial load is faster and it is favorable for search engine optimization. But remember, HTML will be generated on each request, which requires high processing power on the server.

Consider **static site generation** to generate HTML at build time. Pre-rendered HTML is then reused on each request. It fits well when you have a lot of static content.

You should take the performance, cost and search engine optimization into account when choosing a rendering method for your web pages.

---

## _Read This Article On Medium_

_[Rendering On The Web: CSR, SSR, SSG - Medium post by me](https://medium.com/@ilkyaz.arabaci/rendering-on-the-web-csr-ssr-ssg-6ecfac6e0cd4)_

_Cheers,_

_ilkyaz_


Rendering On The Web: CSR, SSR, SSG


# What’s New in React 18

React v18.0 was released earlier this year. With the focus being on performance improvements, the major addition is Concurrent React. Also, new features were introduced such as Automatic Batching and Transitions. You should definitely check the new concepts from the [official release notes](https://tr.reactjs.org/blog/2022/03/29/react-v18.html)

## How To Update

All you have to do to upgrade to React 18 is simply:

```js
        npm install react@18 react-dom@18
```

And then, in your root entry file, typically index.js, update ReactDOM.render to ReactDOM.createRoot and render your app using root:

```js
        const root = ReactDOM.createRoot(document.getElementById(‘root’));
        root.render(<App />);
```

Note that, new features in React 18 don’t work without createRoot.

![React 18](react-18.png)

## Concurrency

The most important new concept is Concurrent React, which is a behind-the-scenes mechanism to help with **state update prioritization**. When you first upgrade to React 18, without adding any concurrent features, updates are rendered synchronously, as before. So, once an update starts rendering, it is interruptable. This means, if there is a lot of data to be processed, the UI can get slow, especially on slower devices. However, in concurrent rendering, it is not the case.

## Transitions

Urgent state updates can be prioritized over others. With Concurrent React, previously known as Async React, you can achieve this by using startTransition() method in places where hooks can’t be used. In functional components, you can use useTransition(), which is a hook that lets you access concurrent mode features. This is a way to inform React which updates are urgent and which may be handled with lower priority.

### Example: useTransition

useTransition hook returns an array with two elements. A boolean value that indicates the transition is pending or not, and startTransition function which allows you to mark UI updates as transitions. You could also import this function if you couldn’t use the hook. But we don’t need that in functional components.

State updates can be wrapped with startTransition(), if they should have lower priority.

```js
import { useTransition } from 'react';

function App() {
  const [isPending, startTransition] = useTransition();
  const [results, setResults] = useState([]);

  const someEventHandler = (event) => {
    startTransition(() => {
      setResults(event.target.value);
    });
  };

  return (
    <div>
      {isPending && <Spinner />}
      <MyComponent results={results} />
    </div>
  );
}
```

## New Hooks

With another new hook, useDeferredValue(), an older value can be displayed until the new one is ready, instead of waiting. So, you can defer re-rendering the non-urgent part. It is similar to startTransition(), but it can be used in cases like when you are receiving a stateful value as props, where you don’t have the full control over the state update.

### Example: useDeferredValue

Whereas useTransition() wraps the code that updates the state, useDeferredValue() wraps a value which is affected by the state update. But their goal is the same.

        const deferredValue = useDeferredValue(value);

All in all, useTransition() and useDeferredValue() can be considered if the component can’t be optimized with pagination, lazy loading etc. or if there is a complex UI.

## Automatic Batching

Besides these new hooks and functions, there are also some changes for existing features, like State Batching. It’s about grouping multiple state updating calls together, so that they can be executed as one, to not to re-evaluate the component unnecessarily.

In React 17, this feature worked inside of synchronous React event handler functions. Updates inside of promises, setTimeout and native event handlers were not batched. For example, the state updates were not batched together where you had a function which is triggered because a timer expired.

Now, it works no matter where you make your state updates. To see the updated state batch and behavior, you can disable strict mode by removing <React.StrictMode> from index.js. Because during development, Strict Mode can log extra warnings and double-invoke functions that are expected to be idempotent.

### Example: Automatic Batching

```js
function App() {
  const [count, setCount] = useState(0);
  const [clicked, setClicked] = useState(false);

  const handleClick = () => {
    setCount((count) => count + 1); // Does not re-render yet
    setClicked((clicked) => !clicked); // Does not re-render yet
    // Only re-render once at the end
  };

  const handleTimeOutClick = () => {
    setTimeout(() => {
      setClicked((clicked) => !clicked);
      setCount((count) => count + 1);
      // Only re-render once at the and
    });
  };
  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: clicked ? 'gray' : 'black' }}>{count}</h1>
      <button onClick={handleTimeoutClick}> Timeout Handler </button>
    </div>
  );
}
```

You might want to [check this discussion.](https://github.com/reactwg/react-18/discussions/21)

## New Strict Mode Behaviors

Starting from React 18, React does not suppress any logs. Also, a new development-only check is introduced, which will immediately unmount and re-mount the component. So, the component will mount, unmount and re-mount again. On the second mount, the state will be restored from the first mount by React. This will simulate the user tabbing away from a screen and back for example. As a result, it will ensure that the code can handle the state restoration properly.

## Suspense On The Server

Another important change is about the Suspense component. This component can be used to help with UI updates related to data fetching. You can delay the component rendering and show a fallback component while waiting, until the code for a lazily loaded component is downloaded. Previously, Suspense could only be used on the client with React.lazy API. With React 18, you can also use Suspense if you use server side rendering. Which means, you can use this component in Next.js for example.

```js
        function App() {
            return (
                <Suspense fallback={“Loading...”}>
                    <ComponentThatFetchesData />
                </Suspense>
            );
        }
```

## Conclusion

React 18 is a major release, that includes improvements to server-side rendering performance as well as improvements on the client-side. With the **new concurrent rendering mechanism**, you can prepare multiple versions of the UI at the same time. startTransition(), useTransition(), useDeferredValue() and Full Suspense Support are the new concurrent features. For basic applications, you can easily upgrade to React 18.

## Resources

[The Official Release Blog Post](https://tr.reactjs.org/blog/2022/03/29/react-v18.html)

[React 18 — What’s New, What Changed & Upgrade Guide by Maximillian Schwarzmüller on Academind](https://www.youtube.com/watch?v=N0DhCV_-Qbg&ab_channel=Academind)

[React 18 New Features — Concurrent Rendering, Automatic Batching, and More by Shruti Kapoor on freeCodeCamp](https://www.freecodecamp.org/news/react-18-new-features/)

---

## _Read This Article On Medium_

_[What's New in React 18 - Medium post by me](https://medium.com/@ilkyaz.arabaci/whats-new-in-react-18-b98c9c2b0f76)_

_Cheers,_

_ilkyaz_


Hello, world! I'm ilkyaz.

Featured Posts

Trunk-based Development

Rendering On The Web: CSR, SSR, SSG

What’s New in React 18