Forem: Tauan Camargo

How Boring It Is to Write Articles or Talk to Certain Types of Developers These Days.

Tauan Camargo — Mon, 16 Sep 2024 02:03:47 +0000

Hey folks! A couple of days ago, I wrote an article about ts-pattern, sharing how cool it was to discover this library. I got some great feedback from people who appreciated what I shared. But, of course, there were also some comments criticizing my approach, arguing that I should just stick to basic switch statements or object literals. They mentioned that I shouldn’t add another library that would increase the bundle size.

Come on, guys. Can’t I write an article about something I found fun and wanted to share? You can use this library if you want—I’m not saying it’s the best or that everyone should use it. I’m simply sharing how cool and readable I found it for my use case. I’m not trying to launch a rocket here or explain compiler optimizations to a new developer.

It’s becoming tiresome to engage with developers who think they know everything and dismiss anything that doesn’t align with their rigid principles. Sharing something I find interesting and enjoyable shouldn’t be a battleground for those who love nitpicking. And when I read comments like “If this happened at my company, I’d block the PR,” I just think—what the hell, dude? It’s just my personal opinion about something fun, not a performance-critical decision that will destroy your project.

Let’s be real: no project is perfect, and most have code smells like any other. So far, this is just a rant, but it won’t stop me from sharing things I find cool. See you guys online.

for someone that want to read here is the ts-pattern article: Article

How ts-pattern can improve your code readability?

Tauan Camargo — Fri, 13 Sep 2024 15:09:00 +0000

My First Encounter with ts-pattern

A few months ago, I was reviewing a client’s codebase filled with numerous switch statements and object literals spread across many files, which was making the readability and maintainability a mess.

During a pair programming session with my teammate Erick, he shared his screen and showed me a library that he was testing out.

That was my first experience with ts-pattern 🤩, and honestly, it blew my mind! The improvement in readability and maintainability was incredible.

Here is the link for ts-pattern documentation.

Let me show you some use cases where ts-pattern can make a real difference. One of the first questions I had was: Can I use this in any TypeScript project? The answer is YES 🙌.

Use cases

1. Replacing Complex Switch Statements

Traditional switch statement:

const status = "success";

let message;
switch (status) {
  case "success":
    message = "Operation was successful!";
    break;
  case "error":
    message = "There was an error.";
    break;
  default:
    message = "Unknown status.";
}
console.log(message);  // Output: Operation was successful!

Using ts-pattern:

import { match } from 'ts-pattern';

const status = "success";

const message = match(status)
  .with("success", () => "Operation was successful!")
  .with("error", () => "There was an error.")
  .otherwise(() => "Unknown status.");

console.log(message);  // Output: Operation was successful!

Comparison:

Readability using ts-pattern is clean, no need for break statements, and pattern matches focus directly on the cases. Adding or removing conditions in ts-pattern is easier, and you don’t have to deal with the traps of forgetting breaks in switch cases.

2. Object Matching for API Responses

Using object matching:

const apiResponse = {
  status: 200,
  data: {
    user: {
      id: 1,
      name: 'John',
    },
  },
};

let userName;
if (apiResponse.status === 200 && apiResponse.data.user.name === 'John') {
  userName = "Hello, John!";
} else {
  userName = "User not found.";
}

console.log(userName);  // Output: Hello, John!

Using ts-pattern:

const apiResponse = {
  status: 200,
  data: {
    user: {
      id: 1,
      name: 'John',
    },
  },
};

const userName = match(apiResponse)
  .with({ status: 200, data: { user: { name: "John" } } }, () => "Hello, John!")
  .otherwise(() => "User not found.");

console.log(userName);  // Output: Hello, John!

Comparison:

ts-pattern reduces the need for deeply nested if conditions, making the logic cleaner and smoother. The pattern matching directly reflects the structure of the object, making it easier to understand and modify.

3. State Management

State management using switch:

const appState = { status: "loading" };

let displayMessage;
switch (appState.status) {
  case "loading":
    displayMessage = "Loading...";
    break;
  case "success":
    displayMessage = "Data loaded successfully!";
    break;
  case "error":
    displayMessage = "Failed to load data.";
    break;
  default:
    displayMessage = "Unknown state.";
}

console.log(displayMessage);  // Output: Loading...

Using ts-pattern:

const appState = { status: "loading" };

const displayMessage = match(appState.status)
  .with("loading", () => "Loading...")
  .with("success", () => "Data loaded successfully!")
  .with("error", () => "Failed to load data.")
  .otherwise(() => "Unknown state.");

console.log(displayMessage);  // Output: Loading...

Comparison:

ts-pattern simplifies state management by eliminating the need for repetitive case and break statements. As the number of states grows, ts-pattern scales better with fewer chances of logical errors.

By comparing switch statements, object literals, and traditional conditionals with ts-pattern, it’s clear that ts-pattern offers a more elegant and scalable approach. Whether you’re handling complex states, object matching, or validations, ts-pattern reduces boilerplate code, improves readability, and minimizes potential bugs. Give it a try.

Will try to be more consistent in posting articles here 🤪. Thanks.

Why You Should Consider Changing useEffect to useCallback in Your React Applications

Tauan Camargo — Thu, 01 Jun 2023 18:09:18 +0000

In React applications, managing side effects such as fetching data from an API or updating the DOM is a common task. One of the hooks used to handle side effects is useEffect. However, overusing useEffect can lead to performance issues and unnecessary re-renders.

Fortunately, there's a solution to this problem. You can use useCallback instead of useEffect to optimize your code and improve performance. useCallback is a hook that memoizes a function so that it only gets re-created when its dependencies change. This makes it ideal for handling events and other functions that get passed down to child components.

In this article, we'll explore the differences between useEffect and useCallback, and explain why you should consider using useCallback instead of useEffect in certain situations. We'll also provide examples of how to use useCallback to optimize your React applications and improve performance.

Understanding useEffect and useCallback

Before diving into the benefits of using useCallback, it's important to understand the differences between useEffect and useCallback.

useEffect is a hook that allows you to manage side effects in your React components. It takes two arguments: a function to execute when the component mounts or updates, and an array of dependencies. If any of the dependencies change, the function will re-run. This makes useEffect useful for fetching data from an API, updating the DOM, or subscribing to events.

useCallback, on the other hand, is a hook that memoizes a function so that it only gets re-created when its dependencies change. It takes two arguments: a function to memoize, and an array of dependencies. If any of the dependencies change, the function will be re-memoized. This makes useCallback useful for handling events and other functions that get passed down to child components.

Benefits of Using useCallback

Now that you understand the differences between useEffect and useCallback, let's dive into the benefits of using useCallback.

Improved Performance

One of the main benefits of using useCallback is improved performance. By memoizing a function and only re-creating it when its dependencies change, you can avoid unnecessary re-renders and improve the overall performance of your React application.

Code Optimization

Using useCallback can also help you optimize your code. If you're using useEffect to handle events or other functions that get passed down to child components, you may be causing unnecessary re-renders. By using useCallback, you can memoize these functions and ensure that they only get re-created when their dependencies change.

Easier to Read and Debug

By using useCallback, you can make your code easier to read and debug. Since memoized functions are only re-created when their dependencies change, it's easier to track down where changes are occurring in your code.

When to Use useCallback

While useCallback has many benefits, it's important to understand when to use it. Here are a few scenarios where useCallback is particularly useful:

Handling events or functions that get passed down to child components
Memoizing expensive computations or API calls
Improving the performance of large or complex React applications

...to be continued!!!

Building Robust iOS User Interfaces with MVVM: A Guide for SwiftUI and UIKit Developers

Tauan Camargo — Tue, 11 Apr 2023 14:27:56 +0000

Model-View-ViewModel (MVVM) is a popular design pattern for developing user interfaces in iOS applications. MVVM separates the user interface logic from the business logic, which makes the code more modular and easier to maintain. In this article, we'll explore how to implement MVVM in iOS development using both SwiftUI and UIKit.

What is MVVM?

MVVM is a design pattern that separates the user interface (View) from the business logic (Model) by introducing a new layer, the ViewModel. The ViewModel acts as a mediator between the View and the Model, providing data and business logic to the View and updating the Model based on user input from the View.

The key benefits of using MVVM in iOS development are:

Improved modularity: The code is more modular and easier to maintain, as the business logic is separated from the user interface.
Better testability: The ViewModel can be easily unit tested, as it is a separate layer with a clear responsibility.
More flexible user interface: The ViewModel provides the data and business logic to the View, allowing for more flexibility in how the user interface is designed and presented.
Implementing MVVM in SwiftUI
To implement MVVM in SwiftUI, we can follow these steps:

Define the Model: The Model represents the data and business logic of the application. We can define it as a simple struct or class that conforms to the Codable protocol.

Define the ViewModel: The ViewModel acts as a mediator between the View and the Model. It provides the data and business logic to the View, and updates the Model based on user input from the View. We can define it as an ObservableObject class that contains the data and methods required by the View.

Define the View: The View is responsible for presenting the user interface to the user. We can define it as a SwiftUI View that observes the data provided by the ViewModel and updates its own state based on changes in the ViewModel.

Here's an example of how to implement MVVM in SwiftUI:

// Define the Model
struct User: Codable {
    var name: String
    var age: Int
}

// Define the ViewModel
class UserViewModel: ObservableObject {
    @Published var user: User

    init(user: User) {
        self.user = user
    }

    func updateName(_ name: String) {
        user.name = name
    }

    func updateAge(_ age: Int) {
        user.age = age
    }
}

// Define the View
struct UserView: View {
    @ObservedObject var viewModel: UserViewModel

    var body: some View {
        VStack {
            TextField("Name", text: $viewModel.user.name)
            TextField("Age", value: $viewModel.user.age, formatter: NumberFormatter())
        }
    }
}

// Usage
let user = User(name: "John", age: 30)
let viewModel = UserViewModel(user: user)
UserView(viewModel: viewModel)

In this example, we define the User Model as a simple struct with two properties: name and age. We then define the UserViewModel as an ObservableObject class that contains the User Model and two methods for updating its properties. Finally, we define the UserView as a SwiftUI View that observes the UserViewModel and updates its own state based on changes in the ViewModel.

Implementing MVVM in UIKit

To implement MVVM in UIKit, we can follow a similar approach:

Define the Model: The Model represents the data and business logic of the application. We can define it as a simple struct or class that conforms to the Codable protocol.

Define the ViewModel: The ViewModel acts as a mediator between the View and the Model. It provides the data and business logic to the View, and updates the Model based on user input from the View. We can define it as a class that contains the data and methods required by the View.

Define the View: The View is responsible for presenting the user interface to the user. We can define it as a UIViewController or a UIView that observes the data provided by the ViewModel and updates its own state based on changes in the ViewModel.

Here's an example of how to implement MVVM in UIKit:

// Define the Model
struct User: Codable {
    var name: String
    var age: Int
}

// Define the ViewModel
class UserViewModel {
    var user: User

    init(user: User) {
        self.user = user
    }

    func updateName(_ name: String) {
        user.name = name
    }

    func updateAge(_ age: Int) {
        user.age = age
    }
}

// Define the View
class UserViewController: UIViewController {
    var viewModel: UserViewModel!

    @IBOutlet weak var nameTextField: UITextField!
    @IBOutlet weak var ageTextField: UITextField!

    override func viewDidLoad() {
        super.viewDidLoad()
        bindViewModel()
    }

    private func bindViewModel() {
        nameTextField.text = viewModel.user.name
        ageTextField.text = String(viewModel.user.age)

        nameTextField.addTarget(self, action: #selector(nameTextFieldDidChange(_:)), for: .editingChanged)
        ageTextField.addTarget(self, action: #selector(ageTextFieldDidChange(_:)), for: .editingChanged)
    }

    @objc private func nameTextFieldDidChange(_ textField: UITextField) {
        viewModel.updateName(textField.text ?? "")
    }

    @objc private func ageTextFieldDidChange(_ textField: UITextField) {
        if let age = Int(textField.text ?? "") {
            viewModel.updateAge(age)
        }
    }
}

// Usage
let user = User(name: "John", age: 30)
let viewModel = UserViewModel(user: user)
let viewController = UserViewController()
viewController.viewModel = viewModel

In this example, we define the User Model as a simple struct with two properties: name and age. We then define the UserViewModel as a class that contains the User Model and two methods for updating its properties. Finally, we define the UserViewController as a UIViewController that observes the UserViewModel and updates its own state based on changes in the ViewModel.

Conclusion

In this article, we've explored how to implement MVVM in iOS development using both SwiftUI and UIKit. By separating the user interface logic from the business logic, MVVM makes the code more modular, easier to maintain, and better testable. Whether you're using SwiftUI or UIKit, MVVM is a powerful design pattern that can help you create robust and flexible user interfaces in your iOS applications.

SwiftUI vs UIKit: Choosing the Best Framework for Your iOS App as a Beginner

Tauan Camargo — Tue, 04 Apr 2023 18:50:31 +0000

As a Swift learner, you may have come across the terms SwiftUI and UIKit while exploring iOS development. Both are frameworks used to build user interfaces in iOS apps, but they differ in several ways. Here, we will discuss the benefits of using each framework and when to choose one over the other.

SwiftUI is a relatively new framework introduced in iOS 13, and it is a declarative way of building user interfaces. Declarative programming means that you describe what the interface should look like and let the framework handle the details of how it is rendered. This approach simplifies the development process by reducing the amount of code you need to write and makes it easier to create complex UIs.

One of the significant benefits of SwiftUI is that it offers a real-time preview of your app's interface as you develop it, making it easier to test and debug your code. SwiftUI also provides several layout options, such as VStack, HStack, and ZStack, enabling you to easily arrange views in different ways. Additionally, SwiftUI's use of modifiers, such as font and color, allows you to customize your app's UI without needing to create custom classes or methods.

On the other hand, UIKit is a more established framework that has been around since the first iOS release. It is an imperative way of building user interfaces, meaning you write code that creates and manipulates views directly. UIKit offers more control over the UI, allowing for more customized and advanced layouts. UIKit also provides more UI elements and functionality than SwiftUI, which may be useful for apps that require more complex interactions.

In summary, SwiftUI is ideal for creating apps with simple to medium-complexity interfaces that need to be developed quickly. It is excellent for prototyping and testing new ideas and creating simple UIs for your app. UIKit, on the other hand, is ideal for creating more complex interfaces with advanced functionality. It provides more control over the UI and is excellent for creating apps that require custom or more advanced user interactions.

In conclusion, whether you choose to use SwiftUI or UIKit depends on your app's complexity and your development goals. Both frameworks have their strengths and weaknesses, and choosing the right one will depend on your specific use case. However, as a Swift learner, it's important to understand the benefits of each framework to make an informed decision about which one to use.

SolidJs the new React, but better 😎

Tauan Camargo — Thu, 07 Apr 2022 05:35:01 +0000

Introduction

I started working professionally with react about 4 years ago, I had the pleasure of seeing this library become what it has become today, before we had to create smart components extending the Component class of react, then we had the introduction of hooks where when instead of using class components we used function components with the [useState, useEffect, useMemo, useContext, useReducer] hooks, this made the verbosity of the code slightly decreased.

"OK, but isn't this post about SolidJs?"

To talk about solid-js we have to give a context of how things are done in react.

Here's an example using react Hooks for a simple counter component.

function Counter() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    setInterval(() => {
      setCount(count + 1)
    }, 1000)
  })

  return <div>Count: {count}</div>
}

"But wait, this useEffect keeps popping me a warning", yes, it will say that a dependency is missing in the Array dependency of useEffect, let's add it to stop the warning.

function Counter() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    setInterval(() => {
      setCount(count + 1)
    }, 1000)
  }, [count])

  return <div>Count: {count}</div>
}

Let's run the project:

But now we face another problem, after a few years working with react we started to fight this problem daily, the famous re-run, we can solve this re-run problem in the Counter component in a few ways:

Returning from useEffect a function that clears the setInterval
Using setTimeout instead of setInterval (a great practice but the above approach would be necessary to clean the function)
Using the function itself to return the previous value directly as the current value

Let's use the last option here:

function Counter() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    setInterval(() => {
      setCount(prevCount => prevCount + 1)
    }, 1000)
  }, [])

  return <div>Count: {count}</div>
}

We came up with an idea that react has a "false reactivity" 🧐 .

Let's talk a little about SolidJS

First of all, solid-js is not trying to re-invent the wheel, solid-js is identical to react, let's create our Counter component using solid-js.

function Counter() {
  const [count, setCount] = createSignal(0)

  setInterval(() => {
    setCount(count() + 1)
  }, 1000)

  console.log('the counter called!')

  return <div>Count: {count()}</div>
}

We see a big difference here, count in solid is a function. in solid this is called accessor and this is one of the mystical things behind how solid works. Okay, we noticed in react that we have to clean the setInterval or get the value of the setCount function itself to return the previous value as the current value, to be able to work without the famous re-render, right?

No, :D only this code already works.

We added a console.log to check how many times this component was rendered during the count update, we will check how many times it runs in the console:

Magic!!!! In solid your code does not run more than once unless it is required at some point in the code.

But how does Solid work?

Solid's data management is built around a set of flexible reactive primitives that are responsible for all updates. It has a very similar approach to MobX or Vue, except it never trades its granularity for a VDOM. Dependencies are automatically tracked when you access their reactive values in your effects and JSX View code, Solid primitives come in the form of create calls that usually return tuples, where usually the first element is a readable primitive and the second is a setter. It is common to refer only to the human-readable part by the primitive name.

Primitives

Solid is composed of 3 primary primitives: Signal, Memo and Effect. At its core is the Observer pattern, where Signals (and Memos) are tracked involving Memos and Effects.

Signals are the simplest primitives. They contain get and set value and functions so that we can intercept when they are read and written.

const [count, setCount] = createSignal(0);

Effects are functions that involve readings from our Signal and are executed again whenever the value of a dependent Signal changes. This is useful for creating side effects such as rendering.

createEffect(() => console.log("The latest count is", count()));

Finally, Memos are cached derived values. They share the properties of Signals and Effects. They track their own dependent Signals, rerunning only when they change, and are themselves traceable Signals.

const fullName = createMemo(() => `${firstName()} ${lastName()}`);

How does this Signal work?

Signals are event emitters that contain a list of signatures. They notify their subscribers whenever their value changes.

Things get more interesting as these subscriptions happen. Solid uses automatic dependency tracking. Updates happen automatically as data changes.

The trick is a global stack at runtime. Before an Effect or Memo executes (or re-executes) its developer-provided function, it pushes itself onto that stack. Then any Signal that is read checks if there is a current listener on the stack, and if so, adds the listener to its subscriptions.

You can think like this:

function createSignal(value) {
  const subscribers = new Set();

  const read = () => {
    const listener = getCurrentListener();
    if (listener) subscribers.add(listener);
    return value;
  };

  const write = (nextValue) => {
    value = nextValue;
    for (const sub of subscribers) sub.run();
  };

  return [read, write];
}

Link Github SolidJs: SolidJS

SolidJs o novo React, porem melhor 😎

Tauan Camargo — Thu, 07 Apr 2022 05:30:54 +0000

Introdução

Comecei a trabalhar profissionalmente com react a uns 4 anos, tive o prazer de ver essa library virar o que se tornou atualmente, antes tínhamos de criar smart components estendendo a class Component do react, depois tivemos a introdução dos hooks aonde ao invés de utilizar class components utilizamos function components com os hooks [useState, useEffect, useMemo, useContext, useReducer], isso fez com que a verbosidade do código desse uma leve diminuida.

"OK, mas esse post não é sobre SolidJs?"

Para falarmos sobre o solid-js temos que dar um contexto de como as coisas são feitas no react.

Aqui temos um exemplo utilizando os Hooks do react para um simples component de contador.



function Counter() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    setInterval(() => {
      setCount(count + 1)
    }, 1000)
  })

  return <div>Count: {count}</div>
}

"Mas pera ai, esse useEffect fica me estourando um warning", sim, ele dirá que esta faltando uma dependência no Array dependency do useEffect, bora adicionar para parar com warning.



function Counter() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    setInterval(() => {
      setCount(count + 1)
    }, 1000)
  }, [count])

  return <div>Count: {count}</div>
}

Vamos rodar o projeto:

Mas agora nos deparamos com outro problema, apos alguns anos trabalhando com react começamos a lutar contra esse problema diariamente, o famoso re-run, podemos solucionar esse problema de re-run no component Counter de algumas formas:

Retornando do useEffect uma function que limpa o setInterval
Utilizando o setTimeout no lugar do setInterval (uma ótima pratica porem seria necessário a abordagem a cima de limpar a função)
Usando a própria função para retornar o valor anterior diretamente como o valor atual

Vamos utilizar a última opção aqui:



function Counter() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    setInterval(() => {
      setCount(prevCount => prevCount + 1)
    }, 1000)
  }, [])

  return <div>Count: {count}</div>
}

Chegamos a uma ideia de que o react tem uma "falsa reatividade" 🧐 .

Vamos falar um pouco sobre o SolidJS

Primeiro de tudo, solid-js nao esta tentando re-inventar a roda, solid-js é identico ao react, vamos criar nosso component Counter utilizando o solid-js.



function Counter() {
  const [count, setCount] = createSignal(0)

  setInterval(() => {
    setCount(count() + 1)
  }, 1000)

  console.log('the counter called!')

  return <div>Count: {count()}</div>
}

Vemos aqui uma grande diferença, count no solid é uma função. no solid isso é chamado accessor e isso é uma das coisas misticas por tras de como o solid funciona. Okay observámos no react que temos que fazer uma limpeza do setInterval ou pegar o valor da própria função setCount para retornar o valor anterior como valor corrente, para poder funcionar sem o famoso re-render, certo?

Não, :D só esse código já funciona.

Adicionamos um console.log para verificar quantas vezes foi renderizado esse component durante a atualização do count, checaremos quantas vezes ele roda no console:

Magic!!!! No solid seu código não roda mais de uma vez a não ser que isso seja requerido em algum momento do código.

Mas como Solid funciona?

O gerenciamento de dados do Solid é construído a partir de um conjunto de primitivas reativas flexíveis que são responsáveis por todas as atualizações. Ele tem uma abordagem muito semelhante ao MobX ou Vue, exceto que nunca troca sua granularidade por um VDOM. Dependências são rastreadas automaticamente quando você acessa seus valores reativos em seus efeitos e código JSX View, os primitivos do Solid vêm na forma de chamadas create que geralmente retornam tuplas, onde geralmente o primeiro elemento é um primitivo legível e o segundo é um setter. É comum referir-se apenas à parte legível pelo nome primitivo.

Primitivos

O Solid é composto de 3 primitivas primárias: Signal, Memo e Effect. Em seu núcleo está o padrão Observer, onde Signals (e Memos) são rastreados envolvendo Memos e Effects.

Os Signals são os primitivos mais simples. Eles contêm valor e funções get e set para que possamos interceptar quando eles são lidos e escritos.



const [count, setCount] = createSignal(0);

Effects são funções que envolvem leituras de nosso Signal e são executadas novamente sempre que o valor de um Signal dependente muda. Isso é útil para criar efeitos colaterais, como renderização.



createEffect(() => console.log("The latest count is", count()));

Finalmente, Memos são valores derivados armazenados em cache. Eles compartilham as propriedades de Signals e Effects. Eles rastreiam seus próprios Signals dependentes, reexecutando apenas quando eles mudam, e eles próprios são Signals rastreáveis.



const fullName = createMemo(() => `${firstName()} ${lastName()}`);

Como esse Signal funciona?

Signals são emissores de eventos que contêm uma lista de assinaturas. Eles notificam seus assinantes sempre que seu valor muda.

As coisas ficam mais interessantes como essas assinaturas acontecem. Solid usa rastreamento automático de dependência. As atualizações acontecem automaticamente conforme os dados mudam.

O truque é uma pilha global em tempo de execução. Antes que um Effect ou Memo execute (ou reexecute) sua função fornecida pelo desenvolvedor, ele empurra a si mesmo para aquela pilha. Então, qualquer Signal que é lido verifica se há um ouvinte atual na pilha e, se houver, adiciona o ouvinte às suas assinaturas.

Você pode pensar assim:



function createSignal(value) {
  const subscribers = new Set();

  const read = () => {
    const listener = getCurrentListener();
    if (listener) subscribers.add(listener);
    return value;
  };

  const write = (nextValue) => {
    value = nextValue;
    for (const sub of subscribers) sub.run();
  };

  return [read, write];
}

Link Github SolidJs: SolidJS

Replace your switch statement and multiple "if and else", using Object Literals - [en-US].

Tauan Camargo — Wed, 27 Nov 2019 17:18:00 +0000

So First, What is Switch Statement?

A switch is a function that receives data, and that data will be analyzed, if this data is equal to one of our cases, it makes the instructions in that case and returns a value.



function UserPolicy(type) {
  switch(type) {
    case 'admin':
      return 'This User is Admin!'
      break
    case 'client':
      return 'This User is Client!'
      break
    case 'salesman':
      return 'This User is Salesman!'
      break
    default:
      return 'Ops, this guy doesn\'t have user profile'
  }
}

UserPolicy() // 'Ops, this guy doesn't have user profile'
UserPolicy('admin') // "This User is Admin!"

It’s similar to if and else statements, but it should evaluate a single value – inside the switch we use a case to evaluate against each value.

When you are using lots of else if statements, something very wrong and generally you should use something like a switch as it’s more suited for the purpose and intention. Here’s some else if abuse:



function UserPolicy(type) {

  let userType

  if (type === 'admin') {

    userType = 'This User is Admin!'

  } else if (type === 'client') {

    userType = 'This User is Client!'

  } else if (type === 'salesman') {

    userType = 'This User is Salesman!'

  } else {

    userType = 'Ops, this guy doesn\'t have user profile'

  }

return User is type: </span><span class="p">${</span><span class="nx">userType</span><span class="p">}</span><span class="s2">

}

Problems with switch

There are multiple issues with switch, from its procedural control flow to the non-standard-looking way it handles code blocks, the rest of JavaScript uses curly braces yet switch does not. Syntactically, it's not one of JavaScript's best, nor is its design. We're forced to manually add break; statements within each case, which can lead to difficult debugging and nested errors further down the case should we forget! We have to treat this with caution.

We often use Object lookups for things in JavaScript, often for things, we would never contemplate using switch for - so why not use an Object literal to replace the switch? Objects are much more flexible, have better readability and maintainability and we don't need to manually break; each case. They´re a lot friendlier on new JavaScript developers as well, as they´re standard Objects.

Reasons not to use switch

As the number of “cases” increases, the performance of the object (hash table) gets better than the average cost of the switch (the order of the matter of the case). The object approach is a hash table lookup, and the switch has to evaluate each case until it hits a match and a break.
More maintainable and readable. We also don’t have to worry about break; statements and cases falling through – it’s just a plain Object.

Normally, we would put a switch inside a function and get a return value. Let's do the same here and make the switch case a usable function with a return of an Object Literal:



function UserPolicy(type) {

  // We create a const that receives an object and each of its properties.

  // will be the values corresponding to our types

  const Users = {

    admin: 'This User is Admin!',

    client: 'This User is Client!',

    salesman: 'This User is Salesman!',

    default: 'Ops, this guy doesn\'t have user profile'

  }

return Users[type] || Users.default

}

UserPolicy() // 'Ops, this guy doesn't have user profile'

UserPolicy('admin') // "This User is Admin!"

Overview

Object literals are a more natural control of flow in JavaScript, the switch is a bit old and clunky and prone to difficult debugging errors. Objects are more extensible, maintainable, and we can test them a lot better. They’re also part of a design pattern and very commonly used day to day in other programming tasks. Object literals can contain functions as well as any other Object type, which makes them really flexible! Each function in the literal has function scope too, so we can return the closure from the parent function.

//I'm not dictating the rule - it's just another way of solving our everyday problems

Substitua sua instrução switch e vários "if and else", usando Object Literals - [pt-BR].

Tauan Camargo — Wed, 27 Nov 2019 17:17:51 +0000

Então, primeiro, o que é uma instrução Switch?

Um switch é uma função que recebe dados, e esses dados serão analisados; se esses dados forem iguais a um de nossos "cases", ele executa a instrução que está inserida no bloco de código e retorna um valor.

function UserPolicy(type) {
  switch(type) {
    case 'admin':
      return `This User is Admin!`
      break
    case 'client':
      return 'This User is Client!'
      break
    case 'salesman':
      return 'This User is Salesman!'
      break
    default:
      return 'Ops, this guy doesn\'t have user profile'
  }
}

UserPolicy() // "Ops, this guy doesn't have user profile"
UserPolicy('admin') // "This User is Admin!"

O switch é semelhante às instruções ife else, será avaliado um único valor - dentro da opção, usamos um case para avaliar em relação a cada valor.

Quando você usa muitas declarações de if e else, tem algo muito errado acontecendo, geralmente você deve avaliar usar outra abordagem, aqui está um caso de abuso de if e else:

function UserPolicy(type) {
  let userType
  if (type === 'admin') {
    userType = 'This User is Admin!'
  } else if (type === 'client') {
    userType = 'This User is Client!'
  } else if (type === 'salesman') {
    userType = 'This User is Salesman!'
  } else {
    userType = 'Ops, this guy doesn\'t have user profile'
  }

  return `User is type: ${userType}`
}

Problemas com o switch

Existem vários problemas com o switch, desde seu fluxo de controle processual até a aparência não padronizada de como ele lida com blocos de código, o restante do JavaScript usa chaves, mas o switch não. Sintaticamente, não é um dos melhores do JavaScript, nem o seu design. Somos forçados a adicionar breaks manualmente; instruções em cada case, o que pode levar a erros difíceis de depuração e aninhados futuramente, caso nos esqueçamos! Temos que tratar isso com muita cautela.

Costumamos usar pesquisas de objeto para muitas coisas em JavaScript, muitas vezes para coisas que nunca contemplaríamos usando o switch - então por que não usar um Object Literal para substituir o switch? Os objetos são muito mais flexíveis, têm melhor legibilidade e capacidade de manutenção e não precisamos quebrar manualmente; cada case. Eles também são muito mais amigáveis com os novos desenvolvedores de JavaScript, pois são objetos por padrão.

Motivos para não usar switch

À medida que o número de cases aumenta, o desempenho do objeto (tabela de hash) fica melhor que o custo médio do switch(a ordem da questão do caso). A abordagem de objeto é uma pesquisa de tabela de hash, e a opção deve avaliar cada case até que ele atinja uma correspondência e uma quebra.
Object Literals são mais sustentáveis e legíveis. Também não precisamos nos preocupar com "breaks"; declarações e casos que se enquadram - é apenas um objeto simples.

Normalmente, colocaríamos um switch dentro de uma função e obteríamos um valor de retorno. Vamos fazer o mesmo aqui e transformar o switch case em uma função utilizável com retorno de um Object Literal:

function UserPolicy(type) {
  // Criamos uma constante que recebe um objeto, e cada uma das propriedades
  // será os valores correspondentes aos nossos types
  const Users = {
    admin: 'This User is Admin!',
    client: 'This User is Client!',
    salesman: 'This User is Salesman!',
    default: 'Ops, this guy doesn\'t have user profile'
  }


  return Users[type] || Users.default
}

UserPolicy() // "Ops, this guy doesn't have user profile"
UserPolicy('admin') // "This User is Admin!"

Visão global

Object Literals é um controle mais natural do fluxo em JavaScript, o switch é um pouco antigo, desajeitado e propenso a erros de difícil depuração. Os objetos são mais extensíveis, sustentáveis e podemos testá-los muito melhor. Eles também fazem parte de um padrão de design e são comumente usados diariamente em outras tarefas de programação. Os Object Literals podem conter funções e qualquer outro tipo de objeto, o que os torna realmente flexíveis! Cada função no literal também tem escopo de função, para que possamos retornar o fechamento da função pai.

// Não estou ditando regra - é apenas mais uma forma de solucionar os problemas do nosso dia a dia.

React Hooks, What is it? How to use it? Pt.2 - Using "useState" and "useEffect"

Tauan Camargo — Mon, 23 Sep 2019 19:25:01 +0000

On this second part, Following our project sample, I'm going to show you how to use useState and useEffect.

Third Step: Continuing to use "useState"

So now we'll be able to type a new book to our list and save it:

// We need to import useState from react
import React, { useState } from 'react';

export default function App() {
  const [books, setBooks] = useState(['Javascript', 'React']);
  /* Here we're going to create a new state to save the value typed for newBook 
  */ 
  const [newBook, setNewBook] = useState('');

  /* Here we're going to create a function to bind this value inputted
  */
  const handleBookInput = e => setNewBook(e.target.value);

  /* Here we're going to pass as argument 'newBook' xD */
  const addBook = () => setBooks(newBook);

  return (
    <>
      <input 
        value={newBook}
        onChange={handleBookInput}
        placeholder="add here you new book"
        onKeyPress={e => e.key === 'Enter' && addBook()}
      />
      <button onClick={addBook}>Add Book!</button>
      <ul>
        {books.map((book, index) => <li key={index}>{book}</li>)}
      </ul>
    </>
  );
};

I'm going to show the diffs between first and second code, these codes do the same thing 😄

--- import React from 'react';
+++ import React, { useState } from 'react';

--- class App extends React.Component {
+++ export default function App() {
---   state = {
---     books: ['Javascript', 'React'],
---     newBook: '',
---   }
+++  const [books, setBooks] = useState(['Javascript', 'React']);
+++  const [newBook, setNewBook] = useState('');

---  handleBookInput = e => this.setState({ newBook: e.target.value });
+++  const handleBookInput = e => setNewBook(e.target.value);

---  addBook = () => {
---    this.setState({
---      books: [...this.state.books, this.state.newBook],
---      newBook: '',
---    });
---  }
+++  const addBook = () => setBooks(newBook);

---  render() {
    return (
      <>
        <input
---       value={this.state.newBook}
+++       value={newBook}
---       onChange={this.handleBookInput}
+++       onChange={handleBookInput}
          placeholder="add here you new book"
---       onKeyPress={e => e.key === 'Enter' && this.addBook()}
+++       onKeyPress={e => e.key === 'Enter' && addBook()}          
        />
---     <button onClick={this.addBook}>Add Book!</button>
+++     <button onClick={addBook}>Add Book!</button>
        <ul>
---       {this.state.books.map(
---         (book, index) => <li key={index}>{book}</li>
---       )}
+++       {books.map((book, index) => <li key={index}>{book}</li>)}
        </ul>
      </>
    );
---}
+++};

---export default App;
+++

Fourth Step: Using useEffect

Previously i show to you how to use state in a functional component, now i'm going to show how to use lifecycle methods;
First, These is the most used lifecycle methods from React.Component:
- componentDidMount()
- componentDidUpdate()
- componentWillUnmount()
Seat down, the way to use it in hooks is so hard and expensive 😄 :

  useEffect(() => {}, []); // xD easier, right? hehehe

let's put these methods to our case, we'll use componentDidUpdate to change document.title to show how many books are added, first in Class Component without hooks:

import React from 'react';

class App extends React.Component {
  state = {
    books: ['Javascript', 'React'],
    newBook: '',
  }

  componentDidUpdate() { 
    document.title = `Current books added: ${this.state.books.length}`
  }

  handleBookInput = e => this.setState({ newBook: e.target.value });

  addBook = () => {
    this.setState({
      books: [...this.state.books, this.state.newBook],
      newBook: '',
    });
  }

  render() {
    return (
      <>
        <input
          value={this.state.newBook}
          onChange={this.handleBookInput}
          placeholder="add here you new book"
          onKeyPress={e => e.key === 'Enter' && this.addBook()}
        />
        <button onClick={this.addBook}>Add Book!</button>
        <ul>
          {this.state.books.map(
            (book, index) => <li key={index}>{book}</li>
          )}
        </ul>
      </>
    )
  }
};

export default App;

the same using hooks:

// We need to import useEffect from react
import React, { useState, useEffect } from 'react';

export default function App() {
  const [books, setBooks] = useState(['Javascript', 'React']);
  const [newBook, setNewBook] = useState('');

  const handleBookInput = e => setNewBook(e.target.value);

  const addBook = () => setBooks(newBook);

  /* using useEffect you can use all lifecycle methods 
  to use componentDidMount() {} in hooks you should code something like that:
  useEffect(() => {
    ....
  }, []);
  here useEffect get 2 arguments a function and a array, inside 
  the function will contain your code, on componentDidMount the array value
  need to be empty.

  to use componentDidUpdate() {} in hooks the code will look like changing only one thing:
  useEffect(() => {
    ....
  }, [state_to_observe]);
  here use effect get 2 arguments like the code before, but the only change is on the
  second argument receives the state observer (Note: if do you want to observer many states 
  you can put that states inside the array), in our sample we're going to use useEffect with state observer.
  */

  /* When that state has any changes, the function inside useEffect is called xD  easy peasy, right?
  */

  useEffect(() => {
    document.title = `Current books added: ${books.length}`
  }, [books]);

  return (
    <>
      <input 
        value={newBook}
        onChange={handleBookInput}
        placeholder="add here you new book"
        onKeyPress={e => e.key === 'Enter' && addBook()}
      />
      <button onClick={addBook}>Add Book!</button>
      <ul>
        {books.map((book, index) => <li key={index}>{book}</li>)}
      </ul>
    </>
  );
};

In the next post we're going to use useCallback(), see you soon 😄

React hooks Pt. 1 - Link here
React hooks Pt. 2 - Link here

React Hooks, What is it? How to use it? Pt.1 - Using "useState"

Tauan Camargo — Mon, 23 Sep 2019 05:35:17 +0000

On this first part, I'm going to show you how to use react hooks in a sample react application, that application you'll be able to add books to your list, think the possibilities, we'll use useState(), useEffect() and useCallback().

First Step: Create Project

You will need to install create-react-app to your machine, use this command to install npm install -g create-react-app;
So now you can generate the project typing npx create-react-app books;
Your project folder will contain this paths and files:
Delete this file App.js and create a new file with the same name;
On your new file create something like that:

import React from 'react';

export default function App() {
  return <h1>Hello World!</h1>
};

Second Step: Using useState()

In react version before 16.8 to create a Component that has a state, you should to create a Class Component like that:

import React from 'react';

class App extends React.Component {
  state = {
    title: 'Hello World!',
  }

  render() {
    return <h1>{this.state.title}</h1>
  }
};

export default App;

Okay now we're going to put this in our context:

import React from 'react';

class App extends React.Component {
  state = {
    books: ['Javascript', 'React'],
    newBook: '',
  }

  handleBookInput = e => this.setState({ newBook: e.target.value });

  addBook = () => {
    this.setState({
      books: [...this.state.books, this.state.newBook],
      newBook: '',
    });
  }

  render() {
    // if you don't know what is <></> is short way to use <React.Fragment> :D
    return (
      <>
        <input
          value={this.state.newBook}
          onChange={this.handleBookInput}
          placeholder="add here you new book"
          onKeyPress={e => e.key === 'Enter' && this.addBook()}
        />
        <button onClick={this.addBook}>Add Book!</button>
        <ul>
          {this.state.books.map(
            (book, index) => <li key={index}>{book}</li>
          )}
        </ul>
      </>
    )
  }
};

export default App;

let's re-build this file to a functional component and let's use useState:

// We need to import useState from react
import React, { useState } from 'react';

export default function App() {
  /* When we declare a state variable with useState,
  it returns a pair — an array with two items.
  The first item is the current value,
  and the second is a function that lets us update it.
  Using[0] and[1] to access them is a bit confusing because 
  they have a specific meaning.
  This is why we use array destructuring instead. */

  /* 
  const booksStateVariable = useState(['Javascript', 'React']);
  const books = booksStateVariable[0];
  const setBooks = booksStateVariable[1];
  */

  /* To be more pretty and readable we use the way bellow,
  now you don't need to use this.state.books, just use books as a state 
  variable :D;   
  */

  const [books, setBooks] = useState(['Javascript', 'React']);

  /*We'll create an addBook function to save this new book in books array,
  what this setBooks do? Answer: It do something like that to you => [...books, the_new_value],
  in this first part of article, we'll put the 'Test' value locally, 
  in next part i'll show the next steps.
  */
  const addBook = () => setBooks('Test');

  return (
    <>
      <button onClick={addBook}>Add test book!</button>
      <ul>
        {books.map((book, index) => <li key={index}>{book}</li>)}
      </ul>
    </>
  );
};

React hooks Pt. 1 - Link here
React hooks Pt. 2 - Link here