DEV Community: Muhammed Erdinç

JavaScript Closures: Understanding the Power of Functions

Muhammed Erdinç — Wed, 31 May 2023 13:06:42 +0000

JavaScript closures are constructs that allow nested functions to be written, allowing the inner function to access the outer function’s variables. In this way, data sharing between different functions is facilitated and changes in one function are reflected in other functions. Also, closures help make code more modular and scalable. In this article, we’ll take an in-depth look at JavaScript closures and learn about their use, advantages, and examples.

Before we deal with the subject in detail, we need to touch on Lexical scoping. In this way, it will be much easier to understand the subject.

Lexical Scoping

In JavaScript, Lexical scoping is used when determining the scope of a function. This means that a variable is scoped based on where it is defined. That is, a variable defined inside a function is valid inside that function and within the scope of functions defined within it. However, it cannot access the scope of outside functions. For example, let’s examine the following code:

function outerFunction() {
  let outerVariable = 'I am outside!';

  function innerFunction() {
    let innerVariable = 'I am inside!';
    console.log(innerVariable); // Output: "I am inside!"
    console.log(outerVariable); // Output: "I am outside!"
  }

  innerFunction();
}

outerFunction();

In this code, innerFunction function is defined inside outerFunction function. So the scope of innerFunction also includes the scope of outerFunction. Therefore, the variables innerFunction, innerVariable, and outerVariable are accessible. However, it is not possible to access these variables from outside the outerFunction.

Scoping in JavaScript: Let & Const

In JavaScript, var, let, and const keywords are used to declare variables.

Variables defined with var can be defined in function scope or global scope. However, they do not provide block coverage. That is, a var variable can be accessed outside the block in which it is defined. This can make the code less reliable and cause errors.

let and const are new keywords that come with ES6. Variables defined with let and const are defined at block scope. That is, a let or const variable cannot be accessed outside of the block in which it is defined. This makes the code more reliable.

The difference between let and const is whether the variable’s value is mutable or not. The values of variables defined with let can be changed, while the values of variables defined with const are fixed and cannot be changed later.

function sayHello() {
  var name = "John";

  if (true) {
    var name = "Jane";
    console.log(name); // "Jane"
  }

  console.log(name); // "Jane"
}

sayHello();

In the example above, a var variable named name is defined inside the sayHello function with an initial value of “John”. Later, another var variable named name is defined inside the if block with an initial value of “Jane”. However, the important point to note is that the name variable inside the if block changes the value of the name variable outside the function.

Let’s now examine the same example for let.

function sayHello() {
  let name = "John";

  if (true) {
    let name = "Jane";
    console.log(name); // "Jane"
  }

  console.log(name); // "John"
}

sayHello();

In the above example, the inner let variable name provides block scoping and is only valid within that block. The outer let name variable is valid within the function’s main scope. Thus, the first console.log statement returns the result “Jane”, while the second console.log statement returns the result “John”.

The topic of closures is closely related to lexical scoping. When closures are used, variables and functions defined within a function remain within the scope of that function and cannot be used elsewhere. This is one of the fundamental principles of lexical scoping. Now that we have briefly touched on the subject of lexical scoping, we can return to our main topic.

Closure

In JavaScript, functions can be assigned to variables like other data types, can be returned as the result of a function, and can be used inside other functions.

A variable defined inside a function is valid only within its scope. That is, code outside the function cannot access this variable.

Closure refers to the situation where the inner function can access the scope of the outer function and the variables defined in it can be used in this scope.

Also, after a closure is created, the values of these variables are retained until the end of the runtime of the functions called from outside to access the variables inside. In this way, variables defined within a function remain accessible even after the function has finished running.

function counter() {
  let count = 0;

  function incrementCount() {
    count++;
    console.log(count);
  }

  return incrementCount;
}

const myFunc = counter(); // Closure is created

myFunc(); // output: 1
myFunc(); // output: 2
myFunc(); // output: 3

In the example above, the counter() function returns a closure. This closure is the incrementCount() function that accesses the count variable defined in it. The counter() function we assign to the myFunc variable returns the incrementCount() function, creating a closure.

When myFunc()is called afterwards, the value of the count variable inside the closure is incremented and printed to the console. Since this function works in conjunction with the closure returned by the counter()function, it retains the final value of the count variable. This means that as long as myFunc()is called, the value of the count variable will be maintained and incremented.

Let’s continue with another example now.

function myFunc(x) {
  return function(y) {
    return x + y;
  }
}

const sum = myFunc(4)(5);
console.log(sum); // output: 9

In this code, a function named myFunc is defined that takes in one argument x. This function returns another function that takes in an argument y and returns the sum of x and y.

In the next line, the myFunc function is called with the argument 4, which returns a new function that adds 4 to any value passed in as y. Then, this newly returned function is immediately called with the argument 5, resulting in the sum of 4 and 5, which is 9.

Finally, the value of sum (which is 9) is logged to the console using console.log().

This way, myFunc function creates a closure by returning an inner function that can access the outer function's variables. Thus, the returned function can be called with different parameters and each function call will create its own closure with its own set of parameters.

The following example is similar to the closure example in the previous one. When the outerFunc function is called, the value of xis stored within the function’s scope, and innerFunc1 function is returned. Then, when the innerFunc1 function is called with the y value, the value of y is also stored in the closure, and innerFunc2 function is returned. Finally, when the innerFunc2 function is called with the z value, x, y and z values are added together and the result is returned.

function outerFunc(x) {
  function innerFunc1(y) {
    function innerFunc2(z) {
      return x + y + z;
    }
    return innerFunc2;
  }
  return innerFunc1;
}

const sum = outerFunc(4)(5)(2);
console.log(sum); // output: 11

Lifetime and Memory Usage of Functions

When a closure is created, the variables and functions inside the closure occupy a memory space just like other objects in memory.

For example, in the following code block, an innerFunction is defined inside the outerFunction, and this inner function uses a variable called innerVariable.

function outerFunction() {
  var innerVariable = 10;

  function innerFunction() {
    console.log(innerVariable);
  }

  return innerFunction;
}

var myClosure = outerFunction();

A closure is created by assigning the outerFunction function to the variable named myClosure. In this case, innerVariable and innerFunction are retained in memory and are referenced by the myClosure variable.

However, the innerVariable variable and the innerFunction function use memory unnecessarily because they are referenced by the myClosure variable. This can result in large memory usage when many shutdowns are used in the program.

For instance, in the code block below, the outerFunction is called 1000 times, and each call creates a closure. Each closure occupies a memory space, and this increases the memory usage.

function outerFunction() {
  var innerVariable = 10;

  function innerFunction() {
    console.log(innerVariable);
  }

  return innerFunction;
}

for (var i = 0; i < 1000; i++) {
  var myClosure = outerFunction();
}

Therefore, caution should be exercised when using closures and not creating too many closures unnecessarily.

References and Garbage Collection

Closures held in memory are deleted when they are out of reference or cleared by the garbage collector. If a closure references a local variable inside a function and that reference still exists after the function has finished running, the closure remains in memory and remains accessible. However, the closure is cleared from memory when there is no reference left or it is cleared by the garbage collector.

For example, if you assign a closure to a variable and then assign that variable to null or some other value, the reference to the closure is lost and the closure is cleared from memory.

The following example shows how the reference of a closure is destroyed:

function outerFunction() {
  var outerVariable = 'Hello';

  return function() {
    console.log(outerVariable);
  }
}

var myClosure = outerFunction();
myClosure(); // "Hello"

myClosure = null; // Closure is destroyed

In this example, myClosure represents a closure and is a function returned from outerFunction. The myClosure function references a local variable named outerVariable. However, when myClosure’s reference is set to null, the closure is no longer referenced and is cleared from memory by the garbage collector.

Closure Performance: How Can We Get Better Performance?

Closures are frequently used in many different use cases in JavaScript and are an essential tool for code readability and flexibility. However, they can cause performance issues if not used properly.

Closures can run slower than other functions because they create a new scope with each call. Also, having a closure in memory can cause unnecessary memory usage and slowdown.

However, there are some techniques to avoid performance issues with closures. The first is to use closures as little as possible. Especially when you are in a loop that requires frequent access to variables inside a closure, it is better to use local variables that can be used as loop variables rather than creating a new closure each time.

It is also important to keep closures as small as possible so that they do not cause unnecessary memory usage. That is, it should not unnecessarily contain too many variables or have unnecessary features.

Finally, to avoid unnecessary memory usage of a closure, it is recommended to delete its reference or set it to null when the closure is finished using it. This helps the JavaScript engine avoid unnecessary memory usage.

In summary, when used correctly, closures can be a very useful feature in JavaScript. However, they can cause performance issues if misused. Keeping Closures as small and optimized as possible and their references managed properly can help avoid performance issues.

In this article, we explained what closures are, how they work, how they affect memory usage, and when they are cleared from memory.

I created the code samples and explanations in this article using chatgpt. I wrote the article by just proceeding with chatgpt without any preliminary research on the subject from any source (books, websites, etc.). Chatgpt can give wrong information in some cases, but in these cases, I was able to proceed easily by guiding chatgpt correctly. I hope we were able to convey the subject in a nice and detailed way with chatgpt :)

Creating Reusable Components with the Composition API & Composables

Muhammed Erdinç — Wed, 29 Mar 2023 10:06:59 +0000

Hello, I would like to share with you the article of the presentation on “Creating Reusable Components with the Composition API & Composables” that I explained at Teknasyon Tech 26. Online Meetup. In this article, I wanted to touch on all the topics I explained in the presentation and create a resource for those who like to read more than watch videos. Also, since the presentation is in Turkish, I wanted to explain this subject by writing an article in English.

In this article, we will explore how to write reusable components with the Composition API & Composables that came into our lives with Vue 3, and also why we should use the Composition API and how we can use it correctly.

First of all, let’s look at the problems we encountered while developing with the options API before Vue 3 and why we need Vue 3. Then, let’s try to understand how these problems are solved with Vue 3. At the end of the presentation, we will look at how we can write our composables better.

Don’t Repeat Yourself (DRY)

One of the most important principles of software development is to avoid repetitive work. Keeping our code reusable and portable is very important. In this way, we can reduce the development cost and produce products faster as a team.

In this article, our aim is to see how to stay away from repetitive tasks in Vue projects and how we can do this more easily with Vue 3.

Single-File Components

In Vue projects, files with the .vue extension are called Single-File Components(SFC). Vue SFCs allow us to encapsulate template, logic, and styling in a single file. So we can keep Html, Css and JavaScript codes in a single file. In this article, we will focus on the script part and see how we can write our Js code sustainably and how we can organize our business logic.

Before Compisition API

Before the Composition API, we developed our Vue projects with the Options API. With the Options API, we thought our code was clearer and more understandable. The reason for this is that the code we will write has its own place and we knew what to add where (data, computed, methods etc).

When we look at the sample code block above, we can say that our code looks very organized and easy to read and understand. So is it really so? Although it seems like a good solution for small projects, we can say that this is valid when the developed application is small and simple.

As the application or components grow, things start to get complicated, especially when we start to include more than one logic in a component. Let’s say we hold more than one logic in a component. In this case, since the codes of these logics will always be written in the same blocks, it will be very troublesome to update our code, add or remove a feature. It will be very difficult to understand which method belongs to which logic or which data belongs to which logic at once.

Since we cannot read our code in a certain order, it will be difficult to understand and develop the code. This will appear as a situation that negatively affects the readability of the code.

If we could instead group our code by logic, it would be much easier to read and understand our code. This is exactly where the Composition API comes in.

In the image above, you can see how complex the code developed with the Options API is compared to the code developed with the Composition API. In the code example below, you can see how a code written with the Options API can be written with the Composition API.

In summary, the Composition API enables grouping of logics. In this way, we only see the codes related to that logic while performing operations on a logic. Also it will be much easier to separate a logic from a component or add a new logic. For example, when the user logic written with the Composition API in the code above is wanted to be moved to another place, it will be much easier to remove the relevant code from the component since the logic is already grouped.

Avoid Repetitive Work with Options API

As you can imagine, the advantages of the Composition API are not limited to these. There was a topic we mentioned at the beginning of the article. One of the most important principles of software development is to avoid repetitive work. The languages and tools we use provide solutions to help us avoid repetitive work, and these solutions evolve and change throughout the process.

Now, let’s take a look at what solutions we use to avoid repetitive works while developing with the Options API, and why these solutions are insufficient, with examples.

For example, when we want to use a function or code block that we use in a Component throughout the project, let’s look at how we do this with the Options API and what problems we encounter. Next, let’s look at how to solve these problems with the Composition API.

Utility Functions

The first of these solutions is Utility Functions. In summary, Utility Functions are structures that can take parameters from outside and allow us to encapsulate small code blocks that we expect to return a value as a result. But their use is limited because we cannot define and use vue specific properties (reactive variables, mounted, created etc) inside these functions.

When we examine the image above, you can see that the increment function is defined, but the count reactive variable cannot be defined in the function, so it is defined in the component. Here, utility functions are insufficient when we want to encapsulate the count variable or use other vue-specific properties.

Renderless Components

Renderless Components is a feature that doesn’t render any html and we can use vue specific properties. When we look at the example in the image above, we see an example of a code that shows the x and y coordinates of the mouse instantly, with a renderless component. Here we can see that we can use vue specific features.

Mixins

Another method we can use to encapsulate complex code blocks is Mixins. We can say that it was an official way to share code between components, especially when developing with the Options API. Thanks to Mixins, we can encapsulate our business logics and use them in more than one place in our project.

We can learn about the use of mixins by looking at the code example in the image above. Looking at the example, we can see that we can use vue specific features inside mixins.

Although Mixins seem like a very good solution, they can have serious disadvantages. Due to these disadvantages, the use of mixins is not recommended today. Let’s look at these disadvantages together.

One of these disadvantages is that when we use more than one mixin in a component, we cannot understand at first glance which feature comes from which mixin.

Another disadvantage is that there are reactive variables or methods with the same name in different mixins. When we use mixins with the same reactive variables or methods in the same component, conflicts will occur and the code will work incorrectly.

Mixins can be used with Vue 3 but are not recommended. There is now a much better way to encapsulate a code block that contains Vue features. Now let’s examine it together.

Composables

The most important feature of the Composition API is the Composables. With Composables, we can turn code blocks that contain reactivity into reusable modules. In this way, we can easily use a code in more than one place. However, it is not only for creating global code blocks, but also for separating multiple logic in a component and making the code more readable. Let’s go through the examples and examine the composables.

For example, let’s say we want to write a code that gives the instant coordinate information of the mouse. We have seen how we can do this with renderless components, now we can understand how we can do this with the Composition API by looking at the image below.

Let’s imagine that we want to use the code developed with the Composition API above in more than one place in the project. The method we can use here is composables.

When we turn the above code into a composable function, our code will be as follows. When we look at the example below, we can see that we can convert our code into a composable function by copy-pasting directly. One of the biggest advantages of the Composition API is that we can easily move our code to another location with almost no changes.

It is quite simple to use the useMouse composable function that we wrote above in any component. All we have to do is import and start using. In the image below, you can see how easily a composable function can be used.

Composables vs Mixins

When we look at the examples of Composable functions, we can see that the disadvantages we experience with mixins are not experienced.

For example, when we use more than one mixin, it was difficult to understand which feature came from which mixin at first glance, but when we use the refs + destructure model, we can easily understand which feature comes from which Composable.
Another disadvantage of Mixins is Namespace collisions. We can avoid namespace collisions by renaming with destructure in Composables.
Another advantage is that the values returned from Composable can be passed as arguments to one another, just like regular functions.

We can nest Composables. In this way, we can combine small logics to form larger ones. This is similar to how we use components while developing a web application. When developing a web application, we create larger components by combining small components. In this way, we can develop large web applications without repeating ourselves. We can do the same for our logics. This will allow us to avoid repetitive tasks and save time.

Looking at the example below, we can see how we can nest composables.

Looking at the example, we can see that we have created a separate composable for the event listener and can use it in another composable.

While developing with the Composition API, we mentioned that we can separate our codes according to logics. For example, let’s say we want to write a composable function. The fact that this function we will write has a certain order in itself will increase the readability of the code. When we look at the example above, you can see that the variables are defined as a block in the code and the functions are written as a separate block. Writing Vue-specific (computed, wathers, etc.) features in separate blocks in a certain order will increase the readability of the code. As in the code example at the bottom of the image above, we can separate these blocks with comment lines.

Coding Better Composables

We looked at code examples related to Composition API and Composables together. We’ve seen that Composables allow us to separate the logic in our code into functions that we can use over and over again. We mentioned that this also makes the code easier to write and read.

Now let’s see how we can write our composables better together. While I was preparing for this subject, there were many sources that I examined, but among these sources, the article “Coding Better Composables” written by Michael Thiessen especially caught my attention. He summarized the subject very well with his way of handling the subject and simple examples. I would definitely recommend checking out the article series. Since this subject is explained very well in the article I mentioned, I would like to explain the subject with the examples there. Since we will proceed in this article without going into too much detail, I recommend that you review the relevant article for detailed information.

While giving information about the subject, we will proceed with code examples again. This time we will use the VueUse library for code examples. VueUse library is an open source library with composables. In this library, we will examine how composables are written. In this way, we will understand what we should pay attention to when writing our own composables.

Options Object Parameter

Most Composables can have one or more parameters. Instead of passing many parameters to our function, we can pass them all as a single object. We can continue with the object destructure inside the function. It will be advantageous for us to pass parameters other than one or two parameters as objects.

First, we don’t need to know the order of the parameters. Sorting doesn’t matter as long as we pass parameters as objects. In this way, we can prevent possible errors.

Secondly, we can understand what the parameters we pass as objects do from the naming of the properties. This will make our code more readable.

Now let’s look at an example on this subject together. We can see how this is done in the useTitle composable in the VueUse library. The useTitle composable is pretty simple. It allows us to set the title of the page.

When we look at the example here, other parameters other than the title parameter are taken as options object. We can proceed in this way in the composables we have written.

Flexible Arguments

We mentioned that Composables can take parameters. These parameters can be primitive javascript types (string, number) as well as reactive variables. In some cases we may want the parameter to be a reactive variable no matter what or a primitive type no matter what. Here, instead of specifically asking for a reactive variable or a primitive type as a parameter, we can accept both and then convert this parameter to the type we need.

When we look at the above example, we can see that this operation can be done very easily with “ref” and “unref”. In this way, regardless of the type of the entered parameter, we can convert it to the type we want (reactive or primitive) and continue. In this way, we can easily avoid possible errors.

Now let’s see how this can be done by going through the UseTitle example.

When we look at the code above, we can see that whatever parameter is entered, it is made reactive.

Dynamic Return Values

Composables can return a single value or an object containing multiple values. You can see both examples in the example above. useDark returns a single value, while useMouse returns an object. If we want, we can make the composable’s values dynamic. We can return a single value or object according to the parameter entered from outside. We can do this very easily with a simple control. In the above example, when “controls: true” is entered, the object is returned, otherwise a single value is returned.

This pattern is often a good way to simplify our code. Now let’s see how this is done in the UseNow composable in the VueUse library.

When we look at the example above, we can see that this operation is done with a simple if check.

Code Organization

We can use Composables not only to create global code blocks, but also for code organization. For example, as the logics increase in a component, it may become more difficult to read and understand the code. For such cases, we can create a separate composable for each logic and divide our code into small pieces. Also, we can pass a variable from one composable to another composable as a parameter. This will provide a significant advantage for code organization.

Conclusion

In this article, I first told you about the difficulties we had before the Composition API, with examples. With these examples, we have seen why we need the Composition API and how these problems are overcome with the Composition API. Afterwards, we examined how we can write our Composables better with examples from the article “Coding Better Composables” written by Michael Thiessen.

Hope what is explained will be useful to you :) You can watch my presentation on this topic below (For Turkish readers).

https://youtu.be/bfIDcdHbIbI

Kaynaklar

Composition API ve Composable’lar ile Yeniden Kullanılabilir Component’ler Oluşturmak

Muhammed Erdinç — Wed, 29 Mar 2023 09:51:35 +0000

Merhabalar, bugün sizlere Teknasyon Tech 26. Online Meetup’da anlatmış olduğum “Creating Reusable Components with the Composition API & Composables” adlı sunumun makalesini paylaşmak istiyorum. Bu yazıda sunumda değindiğim tüm konulara değinmek ve video izlemek yerine okuma yapmayı daha çok sevenler için bir kaynak oluşturmak istedim.

Bu yazıda Vue 3 ile birlikte hayatımıza giren Composition API & Composable’larla sürdürülebilir component’ler nasıl yazılır ve ayrıca Composition API’yi neden kullanmamız gerektiğini ve bunu nasıl doğru bir şekilde kullanabileceğimizi keşfedeceğiz.

Öncelikle Vue 3 öncesinde options API ile birlikte geliştirme yaparken ne gibi sorunlarla karşılaştığımıza ve Vue 3'e neden ihtiyaç duyduğumuza bakalım. Sonrasında ise Vue 3 ile birlikte bu sorunların nasıl çözüldüğünü anlamaya çalışalım. Sunumun sonlarında ise composable’larımızı daha iyi nasıl yazabileceğimize bakacağız.

Don’t Repeat Yourself (DRY)

Yazılım geliştirmenin en önemli ilkelerinden biri kendimizi tekrar eden işlerden uzak durmaktır. Kodumuzu yeniden kullanılabilir ve taşınabilir tutmak oldukça önemlidir. Bu sayede geliştirme maliyetini düşürüp ekip halinde daha hızlı ürünler ortaya çıkarabiliriz.

Bu yazıda da amacımız Vue projelerinde kendimizi tekrar eden işlerden nasıl uzak duracağımızı ve bunu Vue 3 ile birlikte daha kolay nasıl yapabileceğimizi göreceğiz.

Single-File Components

Vue projelerinde .vue uzantılı dosyalar Single-File Components(SFC) olarak adlandırılır. Vue SFC’leri template, logic ve styling’i tek bir dosyada kapsüllememize izin verir. Yani Html, Css ve JavaScript kodlarını tek bir dosyada tutabiliriz. Biz bu yazımızda script kısmına odaklanıp Js kodumuzu sürdürülebilir bir şekilde nasıl yazabileceğimizi ve Business logic’lerimizi nasıl düzenleyebileceğimizi göreceğiz.

Compisition API’den Öncesi

Composition API’den önce Vue projelerinde geliştirmelerimizi Options API ile yapıyorduk. Options API ile birlikte kodlarımızın daha net ve anlaşılır olduğunu düşünüyorduk. Bunun sebebi ise yazacağımız kodun kendi yeri var ve neyi nereye eklememiz gerektiğini biliyorduk(data, computed, methods vb).

Yukarıdaki örnek kod bloğuna baktığımızda kodumuzun oldukça düzenli, okunması ve anlaşılması kolay göründüğünü söyleyebiliriz. Peki gerçekten öyle mi? Küçük projeler için düşünüldüğünde iyi bir çözüm gibi duruyor olsa da bu durumun geliştirilen uygulama küçük ve basit olduğunda geçerli olduğunu söyleyebiliriz.

Uygulama veya component’ler büyüdükçe, özellikle bir component içinde birden fazla logic barındırmaya başladığımızda işler karmaşık hale gelmeye başlıyor. Bir component’te birden fazla logic tuttuğumuzu düşünelim. Bu durumda bu logic’lere ait kodlar hep aynı bloklar içinde yazılacağından kodumuzu güncellemek, yeni bi özellik eklemek veya bi özelliği çıkarmak oldukça zahmetli olacaktır. Hangi method’un hangi logic’e veya hangi data’nın hangi logic’e ait olduğunu tek seferde anlamak oldukça zor olacaktır.

Bu durumda bir logic ile ilgili geliştirme yaparken kodda devamlı yukarı aşağı hareket etmek durumunda kalacak ve kodumuzu belli bi sıraya göre okuyamayacağımızdan kodu anlamak ve geliştirme yapmak zor olacaktır. Bu da kodun okunurluğunu olumsuz etkileyen bir durum olarak karşımıza çıkacaktır.

Bunun yerine kodlarımızı logic’lere göre gruplayabilseydik, ilgili logic ile ilgili çalışırken sadece o logic ile ilgili kodları göreceğimizden ve kodları da kitap okur gibi belli bi düzende okuyacağımızdan kodu anlamak ve geliştirme yapmak çok daha kolay olacaktı. Composition API’nin devreye girdiği yer işte tam olarak burasıdır.

Yukarıdaki görselde Options API ile geliştirilen kodun Composition API ile geliştirilen kod ile kıyaslandığında ne kadar karmaşık kaldığını görebilirsiniz. Aşağıdaki kod örneğinde de solda Options API ile yazılan bir kodun Composition API ile nasıl yazılabileceğini görebilirsiniz.

Özetle Composition API, Logic’lerin gruplanmasını ve kodun sırasıyla ele alınmasını sağlar. Bu sayade bir logic ile ilgili işlem yaparken sadece o logic ile ilgili kodları görürüz. Bunlarla beraber bir logic’i component’ten ayırmak veya yeni bir logic eklemek çok daha kolay olacaktır. Örneğin yukarıdaki kodda Composition API ile yazılmış olan user logic’i başka bir yere taşınmak istendiğinde, logic zaten gruplanmış olduğundan ilgili kodu component’ten çıkarmak çok daha kolay olacaktır.

Options API İle Birlikte Kendimizi Tekrar Eden İşlerden Uzak Durmak

Tahmin edebileceğiniz üzere Composition API’nin avantajları bunlarla sınırlı değildir. Yazının başında değindiğimiz bir konu vardı. Yazılım geliştirmenin en önemli ilkelerinden biri kendimizi tekrar eden işlerden uzak durmaktır. Kullandığımız diller ve araçlar bizi kendimizi tekrar eden işlerden uzak durmamıza yardımcı olacak çözümler üretirler ve bu çözümler süreç boyunca gelişir ve değişir.

Şimdi Composition API öncesinde yani Options API ile geliştirme yaparken kendimizi tekrar eden işlerden kaçmak için hangi çözümleri kullandığımıza ve bu çözümlerin neden yetersiz kaldığına örneklerle beraber bakalım.

Örneğin bir Component’te kullandığımız bir fonksiyon veya kod bloğunu proje genelinde kullanmak istediğimizde bunu Options API ile nasıl yapıyorduk ve ne gibi sorunlarla karşılaşıyorduk bunlara bakalım. Sonrasında da Composition API ile bu sorunlar nasıl çözülmüş bunlara bakalım.

Utility Functions

Bu çözümlerden ilki Utility Function’lardır. Utility Function’lar özetle dışarıdan parametre alabilen ve sonucunda bir değeri return etmesini beklediğimiz, ufak kod bloklarını kapsüllememize olanak tanıyan bir yapıdır. Fakat kullanımları sınırlıdır çünkü vue’ye özgü özellikleri(Reaktif değişkenler, mounted, created vb) bu fonksiyonların içine tanımlayamıyor ve kullanamıyoruz.

Yukarıdaki görseli incelediğimizde increment fonksiyonunun tanımlandığını fakat count reaktif değişkeninin fonksiyon içinde tanımlanamadığından component içinde tanımlandığını görebilirsiniz. Burada count değişkenini de kapsüllemek istediğimizde veya vue’ye özgü diğer özellikleri de kullanmak istediğimizde utility function’lar yetersiz kalmaktadırlar.

Renderless Components

Renderless Componenet’ler herhangi bir html render etmeyen ve vue’ye özgü özellikleri kullanabildiğimiz bir yöntemdir. Burada reaktif değişkenleri veya mounted, unmounted gibi Vue’ye özgü özellikleri kullanabiliriz.

Yukarıdaki görselde yer alan örneğe baktığımızda mouse’un x ve y koordinatlarını bize anlık gösteren bir kodun renderless component ile yazıldığı örneği görüyoruz. Burada vue’ye özgü özellikleri kullanabildiğimizi görebiliriz.

Mixins

Karmaşık kod bloklarını kapsüllemek için kullanabileceğimiz bir diğer yöntem de mixin’lerdir. Özellikle Options API ile geliştirme yaparken component’ler arası kod paylaşmanın resmi bir yoluydu diyebiliriz. Mixin’ler sayesinde business logic’lerimizi kapsülleyip projemizde birden fazla yerde kullanabiliyoruz.

Yukarıdaki görselde yer alan kod örneğine bakarak mixin’lerin kullanımı hakkında bilgi sahibi olabiliriz. Örneğe baktığımızda mixin’lerin içinde vue’ye özgü özellikleri kullanabildiğimizi görebiliriz.

Mixin’ler çok güzel bir çözüm gibi dursalar da çok ciddi dezavantajları olabiliyor. Bu dezavantajlarından dolayı bugün mixin’lerin kullanımı önerilmemektedir. Şimdi beraber bu dezavantajlarına bakalım.

Bu dezavantajlarından biri, bir component’te birden fazla mixin kullandığımızda hangi özelliğin hangi mixin’den geldiğini ilk bakışta anlayamıyoruz.

Diğer bir dezavantaj ise farklı mixin’lerde aynı isme sahip reaktif değişkenlerin veya method’ların yer almasıdır. Aynı reaktif değişken veya method’lar barındıran mixin’leri aynı component’te kullandığımızda conflict’ler oluşacak ve kod hatalı çalışacaktır.

Vue 3 ile birlikte mixin’ler kullanılabilirler fakat kullanılmaları önerilmemektedir. Vue özelliklerini barındıran bir kod bloğunu kapsüllemenin artık çok daha iyi bir yolu var. Şimdi hep beraber bunu inceleyelim.

Composables

Composition API’nin en önemli özelliği composable’lardır. Composable’larla birlikte içinde reaktivite barındıran kod bloklarını yeniden kullanılabilir modüller haline getirebiliyoruz. Bu şekilde yazmış olduğumuz bir kodu birden fazla yerde rahatlıkla kullanabiliyoruz. Bununla beraber sadece global kod blokları oluşturmak için değil aynı zamanda bir component’te yer alan birden fazla logic’i ayırmamıza ve kodun daha okunaklı olmasına da yarıyor. Örneklerle beraber ilerleyerek composable’ları inceleyelim.

Örneğin mouse’un anlık koordinat bilgilerini veren bir kod yazmak istediğimizi düşünelim. Bunu renderless component’ler ile nasıl yapabileceğimizi görmüştük, şimdi de bunu Composition API ile nasıl yapabileceğimizi aşağıdaki görsele bakarak anlayabiliriz.

Yukarıda Composition API ile geliştirilen kodu projede birden çok yerde kullanmak istediğimizi düşünelim. Burada kullanabileceğimiz yöntem composable’lardır. Yukarıdaki kodu composable function haline getirdiğimizde kodumuz aşağıdaki gibi olacaktır. Aşağıdaki örneğe baktığımızda kodumuzu direkt kopyala yapıştır yaparak composable function haline getirebildiğimizi görebiliriz. Composition API’nin en büyük avantajlarından biri de kodumuzu neredeyse hiç değişiklik yapmadan başka bir yere kolaylıkla taşıyabilmemizdir.

Yukarıda yazmış olduğumuz useMouse composable function’ı herhangi bir component’te kullanmak oldukça basittir. Yapmamız gereken tek şey import etmek ve kullanmaya başlamaktır. Aşağıdaki görselde bir composable function’ın ne kadar kolay bir şekilde kullanılabildiğini görebilirsiniz.

Composables vs Mixins

Composable function’larla ilgili örneklere baktığımızda mixin’lerde yaşadığımız dezavantajların yaşanmadığını görebiliriz.

Örneğin birden fazla mixin kullandığımızda hangi özelliğin hangi mixin’den geldiğini ilk bakışta anlamak zor oluyordu fakat Composable’larda özellikle refs + destructure modelini kullandığımızda hangi özelliğin hangi composable’dan geldiğini rahatlıkla anlayabiliyoruz.
Mixin’lerin diğer bi dezavantajı ise Namespace collisions(aynı isme sahip değişken veya method’ların vb olması) olayıdır. Composable’larda destructure ile yeniden adlandırmayla namespace collision’ların önüne geçebiliriz.
Diğer bir avantaj ise Composable’dan döndürülen değerler, tıpkı normal fonksiyonlar gibi bir diğerine bağımsız değişkenler olarak iletilebilir.

Composable’ları iç içe de kullanabiliriz. Bu şekilde küçük logic’leri birleştirerek daha büyük logic’ler oluşturabiliriz. Bu durum web uygulaması geliştirirken component’leri kullanmamıza benziyor. Bir web uygulaması geliştirirken küçük component’leri birleştirerek daha büyük component’ler oluşturuyoruz. Bu şekilde de büyük web uygulamalarını kendimizi tekrar etmeden geliştirebiliyoruz. Bunun aynısını logic’lerimiz için de yapabiliriz. Bu durum hem kendimizi tekrar eden işlerden uzak durmamıza hem de zamandan tasarruf etmemize olanak tanıyacaktır.

Aşağıdaki örneğe baktığımızda composable’ları iç içe nasıl kullanabileceğimizi görebiliriz.

Örneğe baktığımızda event listener için ayrı bir composable oluşturduğumuzu ve bunu başka bir composable içinde kullanabildiğimizi görebiliriz.

Composition API ile geliştirme yaparken kodlarımızı logic’lere göre ayırabildiğimizden bahsetmiştik. Örneğin bir composable function yazmak istediğimizi düşünelim. Yazacağımız bu function’ın da kendi içinde belli bi düzeni olması kodun okunurluğunu arttıracaktır. Üstteki örneğe baktığımızda kodda değişkenlerin bir blok halinde tanımlandığını ve fonksiyonların da ayrı bir blok halinde yazıldığını görebilirsiniz. Vue’ye özgü(computed, wathers vb.) özelliklerin de aynı şekilde ayrı bloklar halinde belli bir sıraya göre yazılması kodun okunurluğu arttıracaktır. Yukarıdaki görselde alt taraftaki kod örneğinde de olduğu gibi bu blokları yorum satırlarıyla ayırabiliriz.

Daha İyi Ve Sürdürülebilir Composable’lar Yazmak

Composition API ve Composable’larla ilgili kod örneklerine beraber baktık. Composable’ların kodumuzda yer alan logic’leri tekrar tekrar kullanabileceğimiz fonksiyonlara ayırmamıza izin verdiklerini gördük. Bunun da kodun yazılmasını ve okunmasını kolaylaştırdığından bahsettik.

Şimdi de beraber composable’larımızı daha iyi nasıl yazabileceğimize bakalım. Bu konuyla ilgili hazırlık yaparken incelediğim birçok kaynak oldu fakat bu kaynaklar arasında özellikle Michael Thiessen’ın yazmış olduğu “Coding Better Composables” yazısı çok ilgimi çekti. Konuyu ele alış biçimi ve yalın örnekleriyle konuyu çok güzel özetlemiş. Yazı dizisini incelemenizi kesinlikle tavsiye ederim. Bahsettiğim yazıda bu konu çok iyi anlatıldığından oradaki örneklerle konuyu anlatmak istiyorum. Bu yazıda çok detaya girmeden ilerleyeceğimizden dolayı detaylı bilgi almak için ilgili yazıyı incelemenizi tekrardan tavsiye ediyorum.

Konu hakkında bilgi verirken yine kod örnekleriyle ilerleyeceğiz. Bu sefer kod örnekleri için VueUse kütüphanesinden yararlanacağız. VueUse kütüphanesi, içinde hazır composable’lar olan ve open source olan bir kütüphanedir. Bu kütüphanede composable’lar nasıl yazılmış bunlara beraber bakacağız. Bu şekilde de kendi composable’larımızı yazarken nelere dikkat etmemiz gerektiğini de anlamış olacağız.

Parametreleri Obje Olarak Geçmek

Composable’ların çoğunda bir veya daha fazla parametre bulunabilir. Fonksiyonumuza fazla sayıda parametre geçmek yerine hepsini tek bir obje olarak geçebiliriz. Fonksiyon içinde de object destructure ile ilerleyerek devam edebiliriz. Bir veya iki parametre dışında kalan parametreleri obje olarak geçmek bizim için avantajlı olacaktır.

Birincisi parametrelerin sırasını bilmemiz gerekmiyor. Parametleri obje olarak geçtiğimiz sürece sıralamanın bir önemi yoktur. Bu sayede olası hataların önüne geçebiliriz.

İkincisi ise obje olarak geçtiğimiz parametlerin ne işe yaradığını property’lerin isimlendirmelerinden anlayabiliriz. Bu da kodumuzu daha okunur yapacaktır.

Şimdi de bu konu ile ilgili bir örneğe beraber bakalım. VueUse kütüphanesinde olan useTitle composable’ında bu işlemin nasıl yapıldığını görebiliriz. useTitle composable’ı oldukça basittir. Sayfanın başlığını ayarlamamızı sağlar.

Buradaki örneğe baktığımızda title parametresi dışında kalan diğer parametreler options nesnesi olarak alınmıştır. Bizde yazdığımız composable’larda bu şekilde ilerleyebiliriz.

Parametrelerin Esnek Olması (Reaktif Veya Primitive Türlerin Otomatik Ayarlanması)

Composable’ların parametre alabileceğinden bahsetmiştik. Bu parametreler ilkel javascript türleri (string, number) olabileceği gibi reaktif değişkenler de olabilir. Bazı durumlarda parametrenin ne olursa olsun reaktif bir değişken olmasını veya ne olursa olsun ilkel bir tip olmasını isteyebiliriz. Burada parametre olarak özellikle reaktif bir değişken veya ilkel bir tür istemek yerine ikisini de kabul edip ardından bu parametreyi ihtiyacımız olan türe dönüştürebiliriz.

Yukarıdaki örneğe baktığımızda bu işlemin “ref” ve “unref” ile çok kolay bir şekilde yapılabileceğini görebiliriz. Bu sayede girilen parametrenin türü ne olursa olsun onu istediğimiz türe(reaktif veya primitive) dönüştürüp devam edebiliriz. Bu şekilde olası hataların önüne rahatlıkla geçebiliriz.

Şimdi de bu işlemin yine UseTitle örneğinden ilerleyerek nasıl yapılabileceğini görelim.

Yukarıdaki koda baktığımızda girilen parametre ne olursa olsun reaktif hale getirildiğini görebiliriz.

Dinamik Dönüş Değerleri

Composable’lar tek bir değer döndürebileceği gibi içinde birden fazla değer barındıran bir obje de döndürebilir. Yukarıdaki örnekte her iki örneği de görebilirsiniz. useDark tek bir değer dönerken useMouse bir obje dönmektedir. Burada istersek yazacağımız composable’ın değerlerini dinamik yapabiliriz. Dışarıdan girilen parametreye göre tek bir değer veya obje döndürebiliriz. Bu işlemi basit bir kontrol ile çok kolay bir şekilde gerçekleştirebiliriz. Yukarıdaki örnekte “controls: true” girildiğinde obje dönmektedir aksi takdirde tek bir değer dönmektedir.

Bu kalıp çoğu zaman kodumuzu basitlemştirmek için iyi bir yöntemdir. Şimdi de bu işlemin VueUse kütüphanesinde UseNow composable’ında nasıl yapıldığına bakalım.

Yukarıdaki örneğe baktığımızda bu işlemin basit bir if kontrolü ile yapıldığını görebiliriz.

Composable ile Kodun Düzenlenmesi

Composable’ları sadece global kod blokları oluşturmak için değil aynı zamanda kod organizasyonu için de kullanabiliriz. Örneğin bir component’te logic’ler arttıkça kodu okumak ve anlamak daha zor hale gelebilir. Bu tarz durumlar için her bir logic için ayrı bi composable oluşturup kodumuzu küçük parçalara ayırabiliriz. Ayrıca bir composable’dan aldığımız değişkeni başka bi composable’a parametre olarak geçebiliriz. Bu da kod organizasyonu için önemli bi avantaj sağlayacaktır.

Özet Ve Teşekkür

Bu yazımda sizlere öncelikle Composition API öncesinde ne gibi zorluklar yaşadığımızdan örneklerle birlikte bahsettim. Bu örneklerle birlikte neden Composition API’ya ihtiyaç duyduğumuzu ve Composition API ile bu sorunların nasıl aşıldığını yine örneklerle beraber görmüş olduk. Sonrasında ise Michael Thiessen’ın yazmış olduğu “Coding Better Composables” yazısından örneklerle giderek Composable’larımızı daha iyi nasıl yazabileceğimizi yine örneklerle beraber inceledik.

Dilerseniz bu yazının sunumunu aşağıdan izleyebilirsiniz.

https://youtu.be/bfIDcdHbIbI

Burada anlatılanların işinize yaraması dileğiyle :)

Kaynaklar

What’s New With Nuxt 3

Muhammed Erdinç — Sun, 05 Mar 2023 14:39:59 +0000

Nuxt 3 beta was announced on October 12, 2021 after 16 months of work, introducing a new foundation based on Vue 3, Vite and Nitro. About 6 months after the beta version was announced, the first Release Candidate for Nuxt 3 called “Mount Hope” was announced.

Release Candidates are beta versions that have the potential to be released as stable. This means that no major breaking changes are expected until the stable release.

Vue 3 & TypeScript

Nuxt 3 is built to provide a great Vue 3 experience along with great SSR support.

Nuxt allows you to experience TypeScript with zero configuration. It automatically creates a TS configuration (.nuxt/tsconfig.json) and a generic type file (.nuxt/nuxt.d.ts) for this.

To learn more about TypeScript in Nuxt 3, you can read the related document.

Vite & Webpack

With Nuxt 3, Vite became the default bundler. Vite is a wrapper that aims to provide a faster development experience for modern web projects. Nuxt 3 also supports packaging with the latest version of Webpack (version 5).

Nitro Server Engine

One of the most important features of Nuxt 3, the new server engine is unjs/nitro. Nitro allows us to create API paths outside of pages in Nuxt. In this way, it provides the opportunity to develop full-stack. In addition, it provides the opportunity to distribute Nuxt application to any system that supports JavaScript (Node.js, Serverless, Workers, Edge-side rendering, etc.).

Nitro Engine also supports adding middleware to API endpoints. Nuxt reads all files in the /server/middleware directory to build middleware for your project and these files are executed on every request. This is usually used so that you can add a common header to all responses, log responses, or modify an incoming request object.

Click to watch a sample video about Nuxt server engine.

Nuxt Bridge

Nuxt Bridge is a layer created to make the transition from Nuxt 2 to Nuxt 3 as easy as possible, allowing you to experience many of the new Nuxt 3 features. Using Nuxt Bridge you can make sure your project is ready for Nuxt 3. To experience Nuxt 3 features in existing Nuxt 2 projects, you need to install @nuxt/bridge-edge in your project. Installation steps and more information can be found here.

Nuxt Bridge, to make the upgrade as easy as possible:

Backward compatibility for nuxt.config.js used with Nuxt 2,
Nuxt 2 supports backward compatibility for modules and plugins.

At the same time, new features that came with Nuxt 3 have been brought to Nuxt 2. In this way, the transition from Nuxt 2 to Nuxt 3 can be carried out gradually. Some of these features are:

Using Nitro server engine with Nuxt 2,
Using Composition API (same as Nuxt 3) with Nuxt 2,
Using new CLI and DevTools with Nuxt 2,
Progressively upgrade to Nuxt 3,
Compatibility with Nuxt 2 module ecosystem,
Upgrade piece by piece (Nitro, Composition API, Nuxt Kit)

In the image below you can see the comparisons between Nuxt 2, Nuxt Bridge and Nuxt 3 versions.

Nuxi

Nuxi (Nuxt CLI) helps you create new projects with zero effort. It’s also backwards compatible, so you can still enjoy some of its benefits even if you’re on Nuxt 2.

Nuxt Kit

Nuxt Kit aims to make developing Nuxt modules easier. It provides users with a new flexible module development experience with cross-version compatibility. In this way, it allows the development of modules that will work on both Nuxt 2 and Nuxt 3.

In summary, we can say about Nuxt 3:

It supports webpack 5 and Vite, which supports hot module replacement during development and assembles your code for production,
It uses esbuild so you can write the latest JavaScript syntax while supporting older browsers,
It uses Nuxi for Command line interface,
It uses Nitro as the server engine,
It uses Nuxt Kit as development kit,
It uses Nuxt Bridge to ease the migration from Nuxt 2.

References:

Nuxt 3 İle Birlikte Gelen Yenilikler

Muhammed Erdinç — Sun, 05 Mar 2023 14:39:17 +0000

Nuxt 3 Beta, Vue 3, Vite ve Nitro’ya dayalı yeni bir temel ile 16 aylık bir çalışmanın ardından 12 Ekim 2021'de duyuruldu. Beta sürümü duyurulduktan yaklaşık 6 ay sonra “Mount Hope” adlı Nuxt 3 için ilk Release Candidate (sürüm adayı) duyuruldu.

Release Candidate (Sürüm Adayı), kararlı olarak yayınlanma potansiyeline sahip beta sürümleridir. Bu, kararlı sürüme kadar büyük bir değişikliğin beklenmediği anlamına gelir.

Vue 3 & TypeScript

Nuxt 3, birinci sınıf SSR desteği ile birlikte harika bir Vue 3 deneyimi sağlamak için inşa edilmiştir.

Nuxt, sıfır yapılandırmayla TypeScript deneyimi elde etmenize olanak tanır. Bunun için otomatik olarak bir TS yapılandırması (.nuxt/tsconfig.json) ve bir genel tür dosyası (.nuxt/nuxt.d.ts) oluşturur.

Nuxt 3'te TypeScript hakkında daha fazla bilgi almak için ilgili dokümanı okuyabilirsiniz.

Vite & Webpack

Nuxt 3 ile birlikte Vite varsayılan bundler(paketleyici) oldu. Vite, modern web projeleri için daha hızlı ve daha yalın bir geliştirme deneyimi sağlamayı amaçlayan bir paketleyicidir. Nuxt 3, Webpack’in en son sürümü (version 5) ile paketlemeyi de desteklemektedir.

Nitro Server Engine

Nuxt 3'ün en önemli özelliklerinden biri, yeni sunucu motoru unjs/nitro’dur. Nitro, Nuxt uygulamalarında sayfalar ile birlikte API yolları da oluşturmamıza izin verir. Bu sayede full-stack geliştirme yapma imkanı sunar. Bunlarla birlikte Nuxt uygulamasını JavaScript’i destekleyen herhangi bir sisteme (Node.js, Serverless, Workers, Edge-side rendering vb.) dağıtım imkanı sağlar.

Nitro Engine, API uç noktalarına middleware (ara katman yazılımı) eklemeyi de destekler. Nuxt, projeniz için middleware oluşturmak için /server/middleware dizinindeki tüm dosyaları okur ve bu dosyalar her istekte yürütülür. Bu genellikle, tüm yanıtlara ortak bir başlık ekleyebilmeniz, yanıtları günlüğe kaydedebilmeniz veya gelen bir istek nesnesini değiştirebilmeniz için kullanılır.

Nuxt server engine ile ilgili örnek bir video izlemek için tıklayınız.

Nuxt Bridge

Nuxt Bridge, Nuxt 2'den Nuxt 3'e geçişi mümkün olduğunca kolaylaştırmak için oluşturulmuş ve yeni Nuxt 3 özelliklerinin çoğunu deneyimlemenizi sağlayan bir katmandır. Nuxt Bridge’i kullanarak, projenizin (neredeyse) Nuxt 3 için hazır olduğundan emin olabilirsiniz. Nuxt 3 özelliklerini mevcut Nuxt 2 projelerinde deneyimlemek için @nuxt/bridge-edge’i projenize kurmanız gerekmektedir. Kurulum aşamaları ve daha fazla bilgiye buradan ulaşabilirsiniz.

Nuxt Bridge, yükseltmeyi olabildiğince kolaylaştırmak için:

Nuxt 2 ile kullanılan nuxt.config.js için geriye dönük uyumluluğu,
Nuxt 2 modülleri ve eklentileri için geriye dönük uyumluluğu desteklemektedir.

Aynı zamanda Nuxt 3 ile birlikte gelen yeni özellikler Nuxt 2'ye de getirilmiştir. Bu sayede Nuxt 2'den Nuxt 3'e geçiş aşamalı olarak gerçekleştirilebilir. Bu özelliklerden bazıları şunlardır:

Nuxt 2 ile Nitro server engine kullanabilme,
Nuxt 2 ile birlikte Nuxt 3 Composition API kullanabilme,
Nuxt 2 ile yeni CLI ve DevTools kullanabilme,
Nuxt 2 modül ekosistemi ile uyumluluk
Parça parça yükseltme imkanı (Nitro, Composition API, Nuxt Kit)

Aşağıdaki görselde Nuxt 2, Nuxt Bridge ve Nuxt 3 versiyonları arasındaki karşılaştırmaları görebilirsiniz.

Nuxi

Nuxi (Nuxt CLI), yeni projeleri sıfır çabayla oluşturmanıza yardımcı olur. Geriye dönük olarak da uyumludur, bu nedenle Nuxt 2'de olsanız bile bazı avantajlarından yararlanabilirsiniz.

Nuxt Kit

Nuxt Kit, Nuxt modüllerini geliştirmeyi daha kolay hale getirmeyi amaçlar. Kullanıcılara sürümler arası uyumluluk ile yeni bir esnek modül geliştirme deneyimi sağlar. Böylelikle hem Nuxt 2 hem de Nuxt 3 üzerinde çalışacak modüllerin geliştirilmesine olanak tanır.

Özetle Nuxt 3 ile ilgili şunları söyleyebiliriz:

Geliştirme aşamasında hot module replacement’ı destekleyen ve kodunuzu üretim için bir araya getiren bir paketleyici olarak hem webpack 5'i hem de Vite’yi destekler.
Eski tarayıcıları desteklerken en son JavaScript sözdizimini yazabilmeniz için esbuild kullanır.
Command line interface (Komut satırı arayüzü) olarak Nuxi kullanır.
Server engine olarak Nitro kullanır.
Development kit olarak Nuxt Kit kullanır.
Nuxt 2'den geçişi kolaylaştırmak için Nuxt Bridge kullanır.

Nuxt, eklenen yeni özellikler ve modüller ile birlikte sürekli gelişmektedir. Planlanan sürümleri ve mevcut durumu takip etmek için Roadmap sayfasını ziyaret edebilirsiniz. Ayrıca Nuxt 3'e hızlı bir başlangıç yapmak isterseniz Quick Start sayfasını inceleyebilirsiniz.

Kaynaklar

What is the DOM & How Does HTML Rendering Happen in Browsers?

Muhammed Erdinç — Sun, 05 Mar 2023 14:34:53 +0000

DOM is a W3C (World Wide Web Consortium) standard. It is a platform and language independent interface standard that allows programs and scripts to dynamically access and update the content, structure, and style of a document.

When a web page loads, the browser builds the page’s DOM tree. In this way, we can change all HTML properties on the page, remove existing HTML elements and attributes, add new HTML elements and attributes, or change all CSS styles on the page with scripting languages such as JavaScript.

What is the DOM Tree?

A DOM tree is a type of tree whose nodes represent the content of the HTML and XML document. Every HTML or XML document has a unique DOM tree representation. For example, let’s examine the following code:

<html>
<head>
  <title>My document</title>
</head>
<body>
  <h1>Header</h1>
  <p>Paragraph</p>
</body>
</html>

The DOM tree of the above code block is as follows:

How the Browser Renders HTML?

A web browser is a piece of software that downloads files from a remote server and displays them to you, allowing user interaction. The process of compiling the files downloaded from a remote server and showing them to the user is done by browser engines. If you are interested, you can examine different browser engines and comparisons.

Data is sent over the Internet as byte packets. The browser must convert these data bytes into a form it understands. Firstly, bytes are converted to HTML characters and then to Tokens. In the next step, Tokens are converted into nodes. Nodes are different objects with certain properties. After the nodes are created, the DOM tree is created.

While creating the DOM tree, the “document” node is created first. Document is a node that represents the entire HTML document. The node that specifies an HTML tag is called “elements”. We can learn the type of any node in the DOM tree with “nodeType”. The NodeType property returns a number. You can review the relevant document to find out which node type this number represents.

The DOM tree has been successfully created, but the browser needs information on how the elements will appear in order to render the page. It is the CSSOM’s responsibility to know how the elements of a page should appear.

What is the CSSOM?

While creating the DOM tree, a request is sent to the CSS link in the

and the CSS styles are returned as a result of this request. As with HTML tags, CSS information comes in bytes, and the CSS Object Model (CSSOM) is created by going through certain stages.

CSS bytes are converted to characters, then tokens and nodes; Finally, a tree structure known as the CSS Object Model or CSSOM for short, is created.

What is the Render Tree?

DOM and CSSOM tree structures are two independent structures. The DOM contains all the information about the relationships of the HTML element of the page, while the CSSOM contains the information about how to style the elements.

The Render Tree contains information about all visible DOM content on the page and all necessary CSSOM information for the different nodes. If an element is hidden by CSS (for example, display: none), it means that the node will not be represented in the Render Tree.

The hidden element (for example, display: none) is present in the DOM, but not in the Render Tree. This is because the Render Tree combines information from both the DOM and the CSSOM.

When the browser renders a Render Tree, it first renders each visible node, starting from the root of the DOM tree (Tags such as script, meta are not included in the Render Tree, and the nodes hidden by CSS are not included in the Render Tree).

visibility: hidden and **display: none **are different. The first makes the item invisible, but the item is contained in the Render Tree (as an empty node), whereas the second (display: none) removes the item from the Render Tree.

Layout and Paint Steps

We have all the content and style information that will be displayed on the screen with the Render Tree, but the image has not yet appeared on the screen. Firstly, the browser has to calculate the exact size and position of each object on the page.

To determine the exact size and position of each object, the browser starts at the root of the Render Tree and calculates each object on the page. As a result of this calculation, the exact location and size of each element is determined. In the next step, the browser paints the nodes one by one on the screen.

Resources Blocking Rendering

DOM and CSSOM must be created before painting. Getting the HTML and CSS to the client as soon as possible is important for optimizing the time to first rendering of web applications.

Even a simple web page is likely to have used JS. When the browser encounters a script tag while reading scripts, the DOM rendering process is paused and stopped until the script file has finished executing. This is because JavaScript can modify both the DOM and the CSSOM. Because the browser isn’t sure what the JavaScript will do, it takes precautions by completely stopping the entire DOM structure.

<!DOCTYPE html>
<html>

<head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>Örnek</title>
    <link rel="stylesheet" href="style.css">
    **<script src="app.js"></script>**
</head>

<body>
  .....
</body>

</html>

In the above code example, when the browser comes to the script tag, the DOM rendering process will be stopped until the script file is finished executing. As a different scenario, if the app.js file was being pulled from a server rather than locally, and it was taking seconds to fetch app.js due to network connection, the DOM construction process would also be stopped for the same time.

Let’s continue with a different scenario, for example, when the browser encounters a script tag, if the CSSOM is not ready yet, the JS execution will wait until the CSSOM is ready.

By default the DOM construction process will be stopped whenever the browser encounters a script tag. If you add the “async” keyword to your script tag, the DOM rendering will not be stopped and will be executed when the script file is downloaded and ready.

<!DOCTYPE html>

<html>

<head>

 <meta name=”viewport” content=”width=device-width,initial-scale=1">

 <title>Örnek</title>

 <link rel=”stylesheet” href=”style.css”>

 <script src=”https://random-app.js" async></script>

</head>

<body>

 ....

</body>

</html>

References:

DOM Nedir & Tarayıcılarda HTML Render İşlemi Nasıl Gerçekleşir?

Muhammed Erdinç — Sun, 05 Mar 2023 14:33:30 +0000

DOM, bir W3C (World Wide Web Consortium) standardıdır. Programların ve komut dosyalarının bir belgenin içeriğine, yapısına ve stiline dinamik olarak erişmesine ve bunları güncellemesine olanak tanıyan, platform ve dilden bağımsız bir arabirimdir.

Bir web sayfası yüklendiğinde, tarayıcı sayfanın DOM ağacını oluşturur. Bu sayede JavaScript gibi betik diller ile sayfadaki tüm HTML özelliklerini değiştirebilir, mevcut HTML öğelerini ve nitelikliklerini kaldırabilir, yeni HTML öğeleri ve niteliklerini ekleyebilir veya sayfadaki tüm CSS stillerini değiştirebiliriz.

DOM Ağacı Nedir?

DOM ağacı, düğümleri HTML veya XML belgesinin içeriğini temsil eden bir ağaç türüdür. Her HTML veya XML belgesinin benzersiz bir DOM ağacı temsili vardır. Örneğin aşağıdaki kodu inceleyelim:

<html>
<head>
  <title>My document</title>
</head>
<body>
  <h1>Header</h1>
  <p>Paragraph</p>
</body>
</html>

Yukarıdaki kod bloğunun DOM ağacı aşağıdaki gibidir:

Tarayıcılar HTML’yi Nasıl Render Eder?

Bir web tarayıcısı, uzaktaki bir sunucudan dosyaları yükleyen ve bunları size görüntüleyerek kullanıcı etkileşimine izin veren bir yazılım parçasıdır. Uzaktaki bir sunucudan yüklenen dosyaların derlenmesi ve kullanıcıya gösterilmesi işlemi tarayıcı motorları ile yapılır. Eğer ilginizi çekiyorsa farklı tarayıcı motorlarını ve karşılaştırmalarını inceleyebilirsiniz.

İnternet üzerinden veriler byte paketleri olarak gönderilir. Tarayıcı ise bu veri byte’larını anladığı bir forma dönüştürmelidir. İlk olarak byte’lar HTML karakterlerine daha sonra ise Token’lara dönüştürülür. Sonraki adımda ise Token’lar düğümlere dönüştürülür. Düğümler belirli özelliklere sahip farklı nesnelerdir. Düğümler oluşturulduktan sonra DOM ağacı oluşturulur.

DOM ağacı oluşturulurken ilk önce “document” düğümü oluşturulur. Document tüm HTML belgesini temsil eden bir düğümdür. Bir HTML etiketini belirten düğüme ise “elements” denir. DOM ağacındaki herhangi bir düğümün türünü “nodeType” ile öğrenebiliriz. NodeType özelliği bir sayı döndürür. Bu sayının hangi düğüm tipini temsil ettiğini bulmak için ilgili dokümanı inceleyebilirsiniz.

DOM ağacı başarıyla oluşturuldu ancak tarayıcının sayfayı oluşturabilmesi için öğelerin nasıl görüneceğine dair bilgilere ihtiyacı vardır. Bir sayfanın öğelerinin nasıl görünmesi gerektiği bilgisi CSSOM sorumluluğundadır.

CSSOM Nedir?

DOM ağacı oluşturulurken

içinde yer alan CSS bağlantısına bir istek gönderilir ve bu isteğin sonucunda CSS stilleri döner. HTML etiketlerinde olduğu gibi CSS bilgileri de byte’larla gelir ve belli aşamalardan geçerek CSS Nesne Modeli(CSSOM) oluşturulur.

CSS byte’ları karakterlere, daha sonra token’lara ve düğümlere dönüştürülür; son olarak da CSS Nesne Modeli veya kısaca CSSOM olarak bilinen bir ağaç yapısı oluşturulur.

Render Tree Nedir?

DOM ve CSSOM ağaç yapıları iki bağımsız yapılardır. DOM, sayfanın HTML öğesinin ilişkileri hakkındaki tüm bilgileri içerirken, CSSOM, öğelerin nasıl şekillendirileceğine ilişkin bilgileri içerir.

Render Tree, sayfadaki tüm görünür DOM içeriğiyle ilgili bilgileri ve farklı düğümler için gerekli tüm CSSOM bilgilerini içerir. Bir öğe CSS tarafından gizlenmişse (örneğin, display: none), düğümün Render Tree’de temsil edilmeyeceği anlamına gelir.

Gizli öğe(örneğin, display: none), DOM’de bulunur, ancak Render Tree içinde bulunmaz. Bunun nedeni, Render Tree’nin hem DOM’den hem de CSSOM’den gelen bilgileri birleştirmesidir.

Tarayıcı Render Tree oluştururken öncelikle DOM ağacının kökünden başlayarak görünür her bir düğümü işler. (script, meta gibi etiketler Render Tree içinde yer almazlar ayrıca CSS ile gizlenen düğümler de Render Tree içinde yer almazlar)

visibility: hidden ile display: none birbirinden farklıdır. İlki öğeyi görünmez yapar ancak öğe Render Tree içinde yer alır (boş bir düğüm olarak), buna karşılık ikincisi (display: none) öğeyi Render Tree’den çıkarır.

Layout ve Paint Adımları

Render Tree ile birlikte ekranda gösterilecek olan tüm içeriğe ve stil bilgilerine sahibiz ancak ekranda henüz bir görüntü oluşmadı. İlk olarak, tarayıcının sayfadaki her nesnenin tam boyutunu ve konumunu hesaplaması gerekir.

Her bir nesnenin kesin boyutunu ve konumunu belirlemek için tarayıcı, Render Tree’nin kökünden başlar ve sayfadaki her bir nesnenin hesaplamasını yapar. Bu hesaplama sonucunda her bir öğenin kesin konumu ve boyutu belirlenmiş olur. Bundan sonraki aşamada ise tarayıcı düğümleri tek tek ekrana boyar.

Render İşlemini Engelleyen Kaynaklar

DOM ve CSSOM, boyama(paint) işleminden önce oluşturulmalıdırlar. HTML ve CSS’lerin mümkün olan en kısa sürede istemciye ulaşması, web uygulamalarının ilk render olma süresine kadar geçen süreyi optimize etmek için önemlidir.

Basit bir web sayfasında bile JS kullanılmış olma ihtimali yüksektir. Tarayıcı komut dosyalarını okurken bir script etiketiyle karşılaştığında DOM oluşturma süreci duraklatılır ve script dosyasının yürütülmesi bitene kadar durdurulur. Bunun nedeni, JavaScript’in hem DOM’yi hem de CSSOM’yi değiştirebilmesidir. Tarayıcı, JavaScript’in ne yapacağından emin olmadığı için, tüm DOM yapısını tamamen durdurarak önlem alır.

<!DOCTYPE html>
<html>

<head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>Örnek</title>
    <link rel="stylesheet" href="style.css">
    **<script src="app.js"></script>**
</head>

<body>
  .....
</body>

</html>

Yukarıdaki kod örneğinde tarayıcı script etiketine geldiğinde script dosyasının yürütülmesi bitene kadar DOM oluşturma süreci durdurulacaktır. Farklı bir senaryo olarak app.js dosyası local’de değil de bir sunucudan çekiliyor olsaydı ve ağ bağlantısından dolayı app.js’yi getirmek saniyeler sürüyor olsaydı, DOM yapım işlemi de saniyelerce durdurulacaktı.

Yine farklı bir senaryo ile devam edelim, örneğin tarayıcı bir script etiketiyle karşılaştığında CSSOM henüz hazır değilse, JS yürütme işlemi CSSOM hazır olana kadar bekletilecektir.

Varsayılan olarak tarayıcı her script etiketiyle karşılaştığında DOM yapım süreci durdurulacaktır. Eğer script etiketinize “async” anahtar sözcüğünü eklerseniz DOM yapımı durdurulmayacak ve script dosyası indirilip hazır olduğunda çalıştırılacaktır.

<!DOCTYPE html>
<html>

<head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>Örnek</title>
    <link rel="stylesheet" href="style.css">
    **<script src="https://random-app.js" async></script>**
</head>

<body>
  .....
</body>

</html>

Kaynaklar

What Is The Open Graph Protocol?

Muhammed Erdinç — Wed, 01 Mar 2023 22:25:20 +0000

The Open Graph Protocol is a protocol created by Facebook for standardizing SEO metadata on Web pages that controls how URLs are displayed when shared on social media. Standardizing metadata has eliminated cross-site metadata mismatch. Today, the Open Graph protocol is also used by other social media sites such as LinkedIn and Twitter, apart from Facebook. Open Graph tags are located in the head section of a Web page.

Social media is very important for your content to reach more people. Users are more likely to see and click on content shared with optimized Open Graph tags. This means more social media traffic for your website. Here are the benefits of previews created with Open Graph tags:

They make the content more eye-catching on social media streams.
A preview of what the content is about.
They help Facebook understand what the content is about, which will help you increase your brand visibility through search.

When we look at the

section of the site shared on Twitter and LinkedIn, we can see the Open Graph meta tags.

The four basic Open Graph tags required for each page are; og:title, og:type, og:image and og:url. Let’s take a quick look at some meta tags and their descriptions:

“og:title”: It will represent the title of your page. It is often the same as the
tag of the web page.
“og:type”: It represents the type of website. In the example above, this is indicated as “article”.
“og:image”: The URL of the image representing your page.
“og:url”: It refers to the current URL of your page.
“og:description”: It refers to a brief description of your content. Usually the same as <meta type=”description”.
“og:audio”: The URL of the audio file that represents your content.
“og:video”: The video URL that represents your content.

Additional Meta Tags for Images

Some meta tags may have additional meta tags attached to them. For example, let’s go over the og:image tag. Usually it will be enough to proceed with the og:image tag, but in some cases the preview of your content may not look the way you want. You may need additional meta tags for this. For example, you may want to adjust the height and width of your image. Below you can see some meta tags and descriptions for og:image.

“og:image:url”: Same as og:image. Indicates the URL of the image.
“og:image:secure_url”: An alternate url to use if the webpage requires HTTPS.
“og:image:type”: Indicates the media type information for the image.
“og:image:width”: Expresses the width of the image in pixels.
“og:image:height”: Expresses the height of the image in pixels.
“og: image:alt”: A description of what is in the image (not a caption). If the page specifies an og:image it should specify og:image:alt.

Testing Open Graph Tags

After adding your Open Graph meta tags, you can test how your content appears on social media sites. This will make debugging your meta tags much easier.

Below are the test links for Facebook and Twitter:

Facebook: https://developers.facebook.com/tools/debug/
Twitter: https://cards-dev.twitter.com/validator

References:

Open Graph Protokolü Nedir?

Muhammed Erdinç — Wed, 01 Mar 2023 22:21:38 +0000

Open Graph Protokolü, URL’lerin sosyal medyada paylaşıldığında nasıl görüntüleceğini kontrol eden ve Web sayfalarındaki SEO meta verilerinin standartlaştırılması için Facebook tarafından oluşturulmuş bir protokolüdür. Meta verilerinin standartlaştırılması, siteler arası meta veri uyumsuzluğunu ortadan kaldırmıştır. Günümüzde Open Graph protokolü, Facebook dışında LinkedIn ve Twitter gibi diğer sosyal medya siteleri tarafından da kullanılmaktadır. Open Graph etiketleri bir Web sayfasının head bölümünde yer alırlar.

İçeriğinizi daha geniş kitlelere ulaştırmak için sosyal medya siteleri oldukça önemlidir. Kullanıcıların optimize edilmiş Open Graph etiketleriyle paylaşılan içeriği görme ve tıklama olasılıkları, oluşan önizlemenin içerikle uyumlu olması nedeniyle daha yüksektir, bu da web siteniz için daha fazla sosyal medya trafiği anlamına gelir. Open Graph etiketleriyle oluşturulan önizlemelerin faydaları ise şunlardır:

Sosyal medya akışlarında içeriği daha dikkat çekici hale getirirler.
İnsanlara içeriğin ne hakkında olduğunu bir bakışta söylerler.
Facebook’un içeriğin ne hakkında olduğunu anlamasına yardımcı olurlar, bu da arama yoluyla marka görünürlüğünüzü artırmanıza yardımcı olacaktır.

Twitter ve LinkedIn’de paylaşılan sitenin

bölümüne baktığımızda Open Graph meta etiketlerini görebiliriz.

Her sayfa için gerekli olan dört temel Open Graph etiketleri; og:title, og:type, og:image ve og:url’dir. Bazı meta etiketlerine ve açıklamalarına kısaca bakalım:

“og:title”: Sayfanızın başlığını temsil edecektir. Çoğu zaman web sayfasının
etiketiyle aynıdır.
“og:type”: Web sitesinin türünü temsil etmektedir. Yukarıdaki örnekte bu “article” olarak belirtilmiştir.
“og:image”: Sayfanızı temsil eden resmin URL’sidir.
“og:url”: Sayfanızın geçerli URL’sini ifade eder.
“og:description”: İçeriğinizin kısa bir açıklamasını ifade eder. Genellikle <meta type=”description” ile aynıdır.
“og:audio”: İçeriğinizi temsil eden ses dosyasının URL’sidir.
“og:video”: İçeriğinizi temsil eden video URL’sidir.

Görüntüler İçin Ek Meta Etiketleri

Bazı meta etiketlerinde, kendilerine eklenmiş ek meta etiketleri olabilir. Örneğin og:image etiketi üzerinden ilerleyelim. Genellikle og:image etiketi ile ilerlemek yeterli olacaktır fakat bazı durumlarda içeriğinizin önizlemesi istediğiniz gibi görünmeyebilir. Bunun için ek meta etiketlerine ihtiyaç duyabilirsiniz. Örneğin görüntünüzün yükseklik ve genişlik bilgisini ayarlamak isteyebilirsiniz.

Aşağıda og:image için bazı meta etiketlerini ve açıklamalarını görebilirsiniz.

“og:image:url”: og:image ile aynıdır. Görüntünün URL’sini ifade eder.
“og:image:secure_url”: Web sayfası için HTTPS gerekiyorsa kullanılabilecek alternatif URL’yi temsil eder.
“og:image:type”: Görüntü için medya türü bilgisini ifade eder.
“og:image:width”: Görüntünün genişlik bilgisini piksel olarak ifade eder.
“og:image:height”: Görüntünün yükseklik bilgisini piksel olarak ifade eder.
“og: image:alt”: Görüntünün içeriği ile ilgili açıklamayı ifade eder.

Open Graph Etiketlerini Test Etmek

Open Graph meta etiketlerinizi ekledikten sonra içeriğinizin sosyal medya sitelerinde nasıl göründüğünü test edebilirsiniz. Bu sayede meta etiketlerinizde hata ayıklama işlemi çok daha kolay olacaktır.

Facebook ve Twitter için test linkleri aşağıdadır:

Facebook: https://developers.facebook.com/tools/debug/
Twitter: https://cards-dev.twitter.com/validator

Kaynaklar

Global Error Management in Nuxt.js Projects

Muhammed Erdinç — Wed, 01 Mar 2023 22:19:17 +0000

Today, frontend projects have become more complex and dynamic compared to the past. Therefore, we have to consider many parameters while developing a frontend project. One of these parameters is error management.

With a error management, our project will not crash in the face of undesirable situations, the cause of the error will be shown to the user and the user experience will be increased.

In a frontend project, it is important to show the user the information about the operations that the application performs or cannot for some reason. This information can be displayed to the user with the snackbar.

If you are developing a frontend project with Nuxt.js and you are making HTTP requests with axios, it is very easy to catch and process errors caused by HTTP requests globally with Axios Interceptors.

What are Axios Interceptors?

Axios interceptors are functions that are called on every HTTP request or response. HTTP requests and responses can be handled with the help of these functions before they are handled (by “then” or “catch”) within the application.

Global Error Management with Axios Interceptors

With axios-module, a special version of Axios for Nuxt, it is possible to do global error management with a simple plugin that you add to your project.
For this, respectively;

Let’s create the axios.js file in the Plugins folder and include it in nuxt.config.js.
1. We can now catch and manage HTTP errors with $axios.onError. Also, onRequest, onResponse, onRequestError and onResponseError can be used together with onError as needed.
  
  HTTP requests and responses along with global error handling will help us build a clean and maintainable architecture. In addition, it will be much easier to eliminate possible errors and add new features, and the maintenance cost of the project will decrease.

References:

Nuxt.js Projelerinde Global Hata Yönetimi

Muhammed Erdinç — Wed, 01 Mar 2023 22:17:38 +0000

Günümüzde frontend projeleri eskiye kıyasla daha karmaşık ve dinamik bir hale gelmiş durumdadırlar. Bu nedenle bir frontend projesi geliştirirken birçok parametreyi göz önünde bulundurmak zorundayız. Bu parametlerden biri de iyi bir hata yönetiminin yapılmasıdır.

İyi bir hata yönetimi ile birlikte istenmeyen durumlar karşısında projemiz çökmeyecek, hatanın sebebi kullanıcıya gösterilebilecek ve kullanıcı deneyimi artmış olacaktır.

Bir frontend projesinde uygulamanın gerçekleştirdiği veya bir sebepten dolayı gerçekleştiremediği işlemler ile ilgili bilgileri kullanıcıya göstermek önemlidir. Bu bilgiler snackbar ile kullanıcıya gösterilebilir.

Eğer Nuxt.js ile frontend projesi geliştiriyorsanız ve HTTP isteklerini axios ile yapıyorsanız, HTTP isteklerinden kaynaklanan hataların global olarak yakalanıp işlenmesi Axios Interceptors ile oldukça kolaydır.

Axios Interceptors Nedir?

Axios interceptors, her HTTP isteği veya yanıtında çağrılan fonksiyonlardır. HTTP istekleri ve yanıtları uygulama içinde ele alınmadan (“then” veya “catch” tarafından işlenmeden) önce bu fonksiyonlar yardımıyla ele alınabilirler.

Axios Interceptors İle Global Hata Yönetimi Yapmak

Axios’un Nuxt’a özel sürümü olan axios-module ile birlikte, projenize ekleyeceğiniz basit bir plugin ile global hata yönetimi yapmak mümkündür. Bunun için sırasıyla;

Plugins klasörü içine axios.js dosyasını oluşturup nuxt.config.js içerisine dahil edelim.
1. Artık $axios.onError ile birlikte HTTP hatalarını yakalayıp yönetebiliriz. Ayrıca ihtiyaca göre onError ile birlikte onRequest, onResponse, onRequestError ve onResponseError da kullanılabilir.
  
  Global hata yönetimi ile birlikte HTTP isteklerininin ve yanıtlarının merkezi olarak yönetilmesi, temiz ve sürdürülebilir bir mimari kurmamıza yardımcı olacaktır. Ayrıca olası hataların giderilmesi ve yeni özelliklerin eklenmesi çok daha kolay olacak, projenin bakım maliyeti düşecektir.

Kaynaklar

Writing Complex Classes Using @apply and Postcss-Nesting with TailwindCSS

Muhammed Erdinç — Fri, 24 Feb 2023 11:56:31 +0000

When we look at the examples where TailwindCSS is used, we can see that the code written in inline has low readability and is not usable for big projects. In such cases, we can avoid this problem by using the existing TailwindCSS classes with @apply in our own custom CSS classes. Let’s try to clarify the issue by going through a simple button component.

In the example above, when we style our button by typing the TailwindCSS classes in inline, we can see that the code is not very readable. In this example, the higher the number of codes, the lower the readability will be. Let’s refactor the above example using @apply.

As you can see, we have obtained a more readable and manageable code base. While specifying CSS class names, we can proceed by following the BEM standard and also by writing nested custom classes as in SCSS. However, since PostCSS does not support nested classes by default, we will need to install a PostCSS plugin and move forward.

Since TailwindCSS is a PostCSS plugin, we can use it with Sass, Less, Stylus or other preprocessors just like any other PostCSS plugin like Autoprefixer. However, since we will write very little CSS in a TailwindCSS project (perhaps not at all), we don’t have to use a preprocessor. In fact, it would be better to work with PostCSS only, unless it is mandatory. The advantages of developing projects using only PostCSS and its plugins are:

Since your CSS doesn’t have to be parsed and processed by multiple tools, your CSS will compile much quicker using only PostCSS.
Because Tailwind adds some new non-standard keywords to CSS (like @tailwind, @apply, theme(), etc.), you often have to write your CSS in annoying, unintuitive ways to get a preprocessor to give you the expected output. Working exclusively with PostCSS avoids this.

Considering the above items, it will be sufficient for us to develop only with PostCSS unless we have to. If necessary, we can install PostCSS plugins and continue to develop. You can review the PostCSS GitHub repository for available PostCSS plugins.

Since we only want to move forward with PostCSS, we need to use a PostCSS plugin that allows us to write nested classes. For this, we have two alternatives, postcss-nested and postcss-nesting. In this article we will use the postcss-nesting plugin as it is recommended in the TailwindCSS document. Installation and more detailed information can be found here.

Let’s try to move forward through an example again. Let’s create the following buttons using TailwindCSS helper classes.

The codes we will write to create the above buttons will be as follows.

In the above usage, since editing or developing the buttons would be very costly for us, let’s try to edit this code together now. We will now be able to use our CSS codes by nesting them with the Postcss-Nesting plugin. Now let’s edit our code and see how it looks.

We can see that the newly created CSS classes are more readable and organized. Now it will be much easier to manage and develop our button components.

In the example above, we can edit the “focus” and “hover” parts to increase the readability of the code. Here, let’s rewrite our code by enclosing the “hover” and “focus” classes in separate blocks.

I think we have achieved a better code base with our recent edits. Proceeding in this way will both make the code more readable and make a new development much less costly. In addition, when working as a team, it will be much easier to make code reviews and find possible errors.