DEV Community: Isaac Batista

Refactoring toast presentation with OOP + Template Method

Isaac Batista — Thu, 02 Feb 2023 03:24:57 +0000

Context

Today I discovered a bug in my app code.

Last week, I have implemented a toast rendering for displaying an warning. And, if you don't know what a toast is, he's this little guy:

Really cute, but here's what I was trying to do:

User presses a button with invalid field values
The toast should appear with some warning like "you cant do this with this values bro"

Simple as that.

It should be, but I did not thought that after receiving the message, the user would press that button insanely. And of course open billions of toasts at the same time.

So, that's my problem.

To figure out how to solve it, let's look at my code:

type ToastDuration = 'SHORT' | 'LONG'

type ToastInterface = {
  show(message: string, duration?: ToastDuration): void;
};

export const getPlatformToast = (): ToastInterface => {
  if (Platform.OS === 'android') {
    return {
      show(message: string, duration = 'SHORT') {
        ToastAndroid.show(message, ToastAndroid[duration]);
      },
    };
  }

  return {
    show(message: string, duration = 'SHORT') {
      Toast.show(message, {duration: Toast.durations[duration]});
    },
  };
};

Finding out a solution

As you can see, I have a native option for Android and a default option for other platforms. Besides that, none of the libs return me if the toast is open or not.

So, how would I prevent it from open?

I have to know if it's open, so that, when user rage press that button, not even a single extra toast appears.

Think with me:

When I press the button the toast opens
I know for how many seconds the toast should be there (that duration option).
I could, therefore, to start a timer when user presses the button for the first time.
If the user presses again and the timer is still on, nothing happens.
When the timer finishes, the toast should be openable again.

Yea bug, you have been burned.

It's time to apply!

Time to apply

The first thing I figured out was that I had to use some state to control if the toast was open.

I started to write for some seconds and wait... I have to write it twice, once for each interface implementation (android and default).

So, let's think again: state management, polymorphism..

SOUNDS LIKE FUN OBJECT ORIENTED MODELING TIME

Awesome solo and lazer blasts

FUN OBJECT ORIENTED MODELING TIME

Back to the code, I like starting from concrete, then abstracting what makes sense. So I'll start with android implementation.

(btw I have changed some names, since I understood I'm not implementing the toast itself, but the one that opens/shows/presents it)

type Duration = 'SHORT' | 'LONG';
type ToastPresenter = {
  show(message: string, duration?: Duration): void;
};

class ToastPresenterAndroid implements ToastPresenter {
  private static readonly durationInMs: Record<Duration, number> = {
    LONG: 3500,
    SHORT: 2000,
  };

  private isShowing = false;

  show(message: string, duration: Duration = 'SHORT'): void {
    if (!this.isShowing) {
      ToastAndroid.show(message, ToastAndroid[duration]);
      this.isShowing = true;
      setTimeout(() => {
        this.isShowing = false;
      }, ToastPresenterAndroid.durationInMs[duration]);
    }
  }
}

Really nice.

With some concrete code implemented, it's much easier to see what's abstract (applies for any implementation) and what's concrete (specific for this android implementation).

(If you cant see it, write the second concrete implementation as well to make it more easy to see the common code.)

In the end ~~it doesnt even matterrrr~~ the line bellow here is the only ~~and lonely~~ concrete code:

ToastAndroid.show(message, ToastAndroid[duration]);

ALL the rest could and will be applied for that default implementation. Even the durationInMs are standardized. Then, how can I reutilize almost all the code and just customize that little piece in the middle?

Design Patterns to the rescue!!112!

We'll use template method.

As it's described:

Template Method is a behavioral design pattern that defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure.

Exactly what we are trying here. It's really creepy, seems like they read our mind.

How can we apply it? First we'll take that common code to a abstract class. And just that concrete line (which uses ToastAndroid) won't be there, we'll declare an abstract method and use it.

Since we are at this abstraction level, it doesnt make sense to use concrete libs now, specific behaviors wont be implemented

abstract class ToastPresenterAbstract implements ToastPresenter {
  private static readonly durationInMs: Record<Duration, number> = {
    LONG: 3500,
    SHORT: 2000,
  };

  private isShowing = false;

  show(message: string, duration: Duration = 'SHORT'): void {
    if (!this.isShowing) {
      this.showConcrete(message, duration);
      this.isShowing = true;
      setTimeout(() => {
        this.isShowing = false;
      }, ToastPresenterAbstract.durationInMs[duration]);
    }
  }

  protected abstract showConcrete(message: string, duration?: Duration): void;
}

Finally, we can fill that template with concrete implementations, that will extends this basic common behavior:

class ToastPresenterAndroid extends ToastPresenterAbstract {
  protected showConcrete(message: string, duration: Duration): void {
    ToastAndroid.show(message, ToastAndroid[duration]);
  }
}

// "Root" is just a reference to the lib name "react-native-root-toast" xD
class ToastPresenterRoot extends ToastPresenterAbstract {
  protected showConcrete(message: string, duration: Duration) {
    const distanceFromBottom = -120;
    ToastRoot.show(message, {duration: ToastRoot.durations[duration], position: distanceFromBottom});
  }
}

Notice that all sorts of concrete behavior will rest on this layer. Such as that distanceFromBottom, it's a specific definition for this lib, to make the toast appears where it should. This was not necessary at the android implementation (even though some other thing could be necessary).

Returning, then, to the beginning, this is how my original function became:

export const getPlatformToast = (): ToastPresenter => {
  if (Platform.OS === 'android') {
    return new ToastPresenterAndroid();
  }

  return new ToastPresenterRoot();
};

Bonus tip: as I was working in react, I had to create a ref, so the instance would keep alive through the component life cycle (keeping the isShowing state, the core of our logic). So, I made a custom hook:

const useToast = () => {
  const ref = useRef(getPlatformToast())

  return ref.current
}

Domain Layer and React? Decorators to the Rescue!

Isaac Batista — Sat, 14 Jan 2023 02:48:14 +0000

Why?

Yeah, why would I try to implement a domain layer within a frontend react application?

*To be able to change and test business rules in isolation from the rest of the system. *

Business rules doesn't live in backend? Mostly, yes. But there are some rules that are attached to the view, they are about your form behavior, they are about how user may or not interact with your UI without making a request for every single movement.

Some rules are quite simple, like that isOpen for a modal. Others can become that big ugly component if your not paying enough attention. We're talking about these last guys.

There's nothing better than being able to test a complex logic in isolation. There's no UI, there's no API. Just the two of us.

Of course, you could isolate the logic inside a hook, and there's an awesome way of testing it with renderHook. But yet, you're trapped into react features, if they change their API, you will have to put your hands in your working logic and adapt some stuffs to keep up to date.

And that's ok if there's no complex domain logic or high life expectancy for the software.

So, repeating the why:

*To be able to change and test business rules in isolation from the rest of the system. *

How?

I have found this answer suggesting to wrap the model instance with 2 layers:

A ref layer keeping the mutable instance alive.
A projection layer keeping the instance data as a state and extending writting behaviors with setState calls.

For example, assume we have this fancy car model:

class Car {
  private speed = 0

  speedUp() {
    this.speed++
  }

  speedDown() {
    if(this.speed > 0) {
      this.speed--
    }
  }

  getSpeed() {
    return this.speed
  }
}

We should keep the mutable instance with useRef:

const useCarRef = () => {
  const carRef = useRef<Car>()

  if(!carRef.current) {
    carRef.current = new Car();
  }

  return carRef.current
}

We should also make a projection function that gets a DTO from instance data:

const projectCar = (car: Car) => {
  return { speed: car.getSpeed() };
}

Last, but not least: we'll create the projection by wrapping write methods and saving the projection as state:

const useCarProjection = (car: Car) => {
  const [projection, setProjection] = useState(projectCar(car));
  return {
      ...projection,
      speedUp: () => {
        car.speedUp();
        setProjection(projectCar(car));
      },
      speedDown: () => {
        car.speedDown()
        setProjection(projectCar(car));
      }
  };
}

Finally we could mix it all and render a component:

const CarView: React.FC = () => {
  const carRef = useCarRef();
  const car = useCarProjection(carRef);

  return <div>
    <button onClick={car.speedDown}>-</button>
    <span>Speed: {car.speed}</span>
    <button onClick={car.speedUp}>+</button>
  </div>
}

That's really nice! But I was studying some design patterns when I read this solution and I could not help noticing that the decorator pattern pretends exactly to wrap some original class adding some behavior.

Quick steps:

Create an interface with the class behaviors
Create a decorator base class that just wraps an instance and it's methods.
Create the specialized decorator that executes base behavior and adds some new.

So, would it fit this application? YES!

First, we should incorporate the projectCar function to Car. I'll also rename it to getDTO.

This is our car now:

class Car {
  private speed = 0

  speedUp() {
    this.speed++
  }

  speedDown() {
    if(this.speed > 0) {
      this.speed--
    }
  }

  getDTO() {
    return {
      speed: this.speed
    }
  }
}

Neat.

Now, we have to create an interface for our Car. That's the contract that will be decorated.

interface CarDTO {
  speed: number
}

interface CarInterface {
  speedUp(): void;
  speedDown(): void;
  getSpeed(): number
  getDTO(): CarDTO
}

class Car implements CarInterface {
  private speed = 0

  speedUp() {
    this.speed++
  }

  speedDown() {
    if(this.speed > 0) {
      this.speed--
    }
  }

  getSpeed() {
    return this.speed;
  }

  getDTO() {
    return {
      speed: this.speed
    }
  }
}

With the contract, we can build the base of our decorator. He's really just a wrapper for the car instance:

class CarDecorator implements CarInterface {
  constructor(protected wrapped: CarInterface){}
  speedUp(): void {
    this.wrapped.speedUp()
  }
  speedDown(): void {
    this.wrapped.speedDown()    
  }
  getSpeed(): number {
    return this.wrapped.getSpeed()
  }
  getDTO(): CarDTO {
    return this.wrapped.getDTO()
  }
}

NOW we can add the true decoration (additional behavior), extending from this base, overriding the write methods (exactly as we did before at useCarProjection hook). But first, as the behavior involves triggering another function, we need to receive it and keep it.

class CarProjectionDecorator extends CarDecorator {
  constructor(
    wrapped: CarInterface,
    private setProjection: (projection: CarDTO) => void 
  ){
    super(wrapped)
  }

  speedUp(): void {
    super.speedUp()
    this.setProjection(this.getDTO())
  }
  speedDown(): void {
    super.speedDown() 
    this.setProjection(this.getDTO())
  }
}

The projection decorator only responsability is calling original behavior and adding something more, in this case: state update trigger. Note that decoration could be added to getters as well, but their original behavior already fits our case.

We can still use the hook just to launch the state and deliver the data to the requesting component.

const useCarProjection = (car: Car) => {
  const [_projection, setProjection] = useState(car.getDTO());
  return new CarProjectionDecorator(car, setProjection)
}

The _projection is not really needed because all the data is available through CarProjectionDecorator getters.

Usage doesn't change much:

const CarView: React.FC = () => {
  const carRef = useCarRef();
  const car = useCarProjection(carRef);

  return <div>
    <button onClick={car.speedDown}>-</button>
    <span>Speed: {car.getSpeed()}</span>
    <button onClick={car.speedUp}>+</button>
  </div>
}

The only difference is that we are now using the getters instead of accessing directly the DTO properties.

Conclusion

Our car is now isolated and the behavior addition is being executed in a class with defined responsability with a well known design pattern with the cons of increasing the complexity by adding more abstraction layers and more files.

Extra - real application

As a reward for reading this all, here's an example of a real application. It's from a RPG character creator in which user will buy his character attribute points. At github.

Domain class:

export class AttributesLauncherPerPurchase implements AttributesLauncherPerPurchaseInterface {
  static price: Record<number, number> = {
    [-1]: -1,
    [0]: 0,
    [1]: 1,
    [2]: 2,
    [3]: 4,
    [4]: 7
  }

  static defaultAttributes = {strength: 0 , dexterity: 0, constitution: 0,  intelligence: 0 , wisdom: 0, charisma: 0  }

  private points = 10;

  constructor(private attributes: Attributes = AttributesLauncherPerPurchase.defaultAttributes){}

  confirm(): void {
    if(this.points > 0) {
      throw new Error('POINTS_LEFT')
    }
  }

  increment(attribute: Attribute): void {    
    const currentAttribute = this.attributes[attribute]
    if(this.points === 0) {
      this.attributes[attribute] = currentAttribute;
      return
    }
    if(currentAttribute >= 4) {
      this.attributes[attribute] = 4;
      return 
    }
    const attributeResult = currentAttribute + 1;
    const totalResult = this.points - Math.abs(AttributesLauncherPerPurchase.price[currentAttribute] - AttributesLauncherPerPurchase.price[attributeResult])

    if(totalResult < 0) {
      this.attributes[attribute] = currentAttribute
      return
    }
    this.points = totalResult
    this.attributes[attribute] = attributeResult;
  }

  decrement(attribute: Attribute): void {
    const currentAttribute = this.attributes[attribute]
    if(currentAttribute <= -1) {
      this.attributes[attribute] = -1
      return
    };

    const result = currentAttribute - 1;
    this.points += Math.abs(AttributesLauncherPerPurchase.price[currentAttribute] - AttributesLauncherPerPurchase.price[result])
    this.attributes[attribute] = result;
  }


  getAttributes(): Attributes {
    return this.attributes
  }

  getPoints() {
    return this.points
  }

  getDTO(): AttributesLauncherPerPurchaseDTO {
    return {
      attributes: this.getAttributes(),
      points: this.getPoints()
    }
  }
}

Base decorator:

// AttributesLauncherPerPurchaseDecorator.ts
export class AttributesLauncherPerPurchaseDecorator implements AttributesLauncherPerPurchaseInterface {
  constructor(protected attributesLauncherPerPurchase: AttributesLauncherPerPurchaseInterface){}

  confirm(): void {
    this.attributesLauncherPerPurchase.confirm()
  }

  getDTO(): AttributesLauncherPerPurchaseDTO {
    return this.attributesLauncherPerPurchase.getDTO()
  }

  getAttributes(): Attributes {
    return this.attributesLauncherPerPurchase.getAttributes()
  }

  getPoints() {
    return this.attributesLauncherPerPurchase.getPoints()
  }

  increment(attribute: Attribute): void {    
    this.attributesLauncherPerPurchase.increment(attribute)
  }

  decrement(attribute: Attribute): void {
    this.attributesLauncherPerPurchase.decrement(attribute)
  }
}

Projection decorator:

// AttributesLauncherPerPurchaseProjectionDecorator.ts

export class AttributesLauncherPerPurchaseProjectionDecorator extends AttributesLauncherPerPurchaseDecorator {
  constructor(
    attributesLauncherPerPurchase: AttributesLauncherPerPurchaseInterface,
    private setProjection: (projection: AttributesLauncherPerPurchaseDTO) => void
  ){
    super(attributesLauncherPerPurchase)
  }

  confirm(): void {
    super.confirm();
    this.setProjection(this.getDTO())
  }

  increment(attribute: Attribute): void {    
    super.increment(attribute)
    this.setProjection(this.getDTO())
  }

  decrement(attribute: Attribute): void {
    super.decrement(attribute)
    this.setProjection(this.getDTO())
  }
}

View

const AttributesLauncherPerPurchaseView: React.FC = () => {
  const {sheetBuilderForm} = useSheetBuilderFormContext()
  const attributesLauncher = sheetBuilderForm.getAttributesLauncher()
  const attributes = attributesLauncher.getAttributes();
  return (
    <div>
      <h3 className='mb-3'>Compra de pontos</h3>
      <div>Restante: {attributesLauncher.getPoints()}</div>
      <div className="flex justify-evenly mb-3">
        {Object.entries(attributes).map(([key, value]) => {
          const attribute = key as Attribute;
          return (
            <AttributeInput 
              key={attribute} 
              attribute={attribute} 
              value={value} 
              decrement={() => attributesLauncher.decrement(attribute)} 
              increment={() => attributesLauncher.increment(attribute)} 
            />
          )
        })}
      </div>
    </div>
  )
}

That's it, til next app.

Hello World - O Primeiro Projeto

Isaac Batista — Wed, 01 Apr 2020 03:33:33 +0000

EEEEEESTAMOS DE VOLTA!!!

Depois desse break pra respirar vamos COMEÇAR nosso PRIMEIRO APP com Framework7!!11!!

Sem mais enrolação, vamos lá.

Primeiros passos:

Crie uma pastinha para o projeto
Rode o comando: framework7 create

Se seu CLI estiver atualizado você estará no mesmo passo que eu.

Por outro lado você receber um erro sobre versão desatualizada, use primeiro: npm install framework7-cli -g

Agora que todos estão no mesmo barco, vamos responder esse formulário sobre que tipo de aplicativo queremos fazer.

Sem muitas complicações vamos estar respondendo assim:

Qualquer erro, use o atalho Ctrl + C pra cancelar a operação.

Vamos às explicações de forma bem rápida:

Simple Web App será um aplicativo que não vai depender de SDKs e outras ferramentas para começarmos a trabalhar. Ele será puramente um App de browser.
Nome do projeto, você pode chamar até de Uber se quiser.
Framework7 Core é a versão do Framework7 sem nenhuma outra lib de interface como React ou Vue, apenas JS puro.
Single View é um template de layout mais simples.
Webpack é a lib que vai estar gerenciando nossas builds e o servidor de desenvolvimento (veremos o que isso quer dizer mais na frente).
CSS acho que vocês conhecem. Não precisamos ter que lidar com outra coisa nesse momento, mas vai de sua preferência.
Cor principal do tema do APP.
Incluir fonts (ícones) no projeto.

Agora vai ser iniciado o processo de instalação de dependências, estruturação das pastas, etc.

Como pode demorar uns minutos, aproveite pra beber um copo d'água ;)

E agora............ Se você está vendo essa mensagem:

Projeto criado com sucesso!

Chegou a hora mais esperada, vamos rodar o projeto pra ver uma coisa concreta pelo menos né?

Alguns de vocês devem estar pensando que vamos abrir procurar algum arquivo como o index.html e abri-lo manualmente, mas nananinanão.

Vamos agora entrar na pasta do projeto e executar o comando npm start. Esse comando vai iniciar nosso servidor de desenvolvimento.

Nosso aplicativo em desenvolvimento estará rodando no endereço http://localhost:8080.

Dica: ative o modo responsivo do seu navegador e selecione os dispositivos pra ver os estilos específicos pra cada plataforma: iOS, Android e Desktop.

Show de bola, galera. Agora vocês podem dar uma explorada em tudo que já vem prontinho pra ser usado nessa página e quem sabe ter umas ideias, ein?

Próxima aula FINALMENTE a gente brinca no código! Até lá!

Instalação do Framework7

Isaac Batista — Sat, 14 Dec 2019 03:53:17 +0000

Olá novamente, quanto tempo, ein?

Nessa aula vamos instalar o Framework7. A melhor forma de começar a trabalhar com o Framework7 segundo a documentação é usando o Framework7 CLI, e é o que iremos fazer.

CLI - Command Line Interface, ou para os mais íntimos: Interface de Linha de Comando.

Que danado é isso?

Bom, na prática quer dizer que vamos ter que deixar o terminal aberto mais um pouquinho, hehe.

Instalando o Framework7 CLI

Basta voltarmos pro nosso terminal e executar o seguinte comando:

npm install -g framework7-cli

Obs.: talvez seja necessário rodar assim:

npm install -g framework7-cli --unsafe-perm=true --allow-root

Para testar a instalação rodaremos o comando framework7 --version e receberemos a versão instalada.

E pronto! Finalmente estamos com a faca e o queijo para iniciarmos nosso primeiro projeto.

Até o próximo artigo!

Preparação do Ambiente para o Framework7

Isaac Batista — Sat, 14 Dec 2019 03:31:25 +0000

Olá a todos, estamos de volta com as aulas de Framework7.

Ajeite a postura, dê uma alongada e pegue um café ou um achocolatado, que hoje a gente hoje a gente só sai daqui com o ambiente preparado.

1. Instalação do NodeJS

Primeiramente: O que danado é isso?

Não se preocupe muito com isso agora, basta saber que é a ferramenta que utilizaremos para gerenciar nossas dependências juntamente com o NPM (Node Package Manager - Gerenciador de Pacotes do Node).

Como eu faço pra baixar?

Que bom que perguntou, basta acessar https://nodejs.org/ e baixar a versão LTS - a versão estável.

Se estiver no Windows basta clicar nesse botão verdão, baixar, executar e fazer o conhecido esqueminha: next->next->next

Porém se estiver no Linux ou Mac, recomendo clicar em Other downloads, descer a telinha até o final, escolher Installing Node.js via package manager e seguir os passos para sua distribuição.

Se todos estamos com o Node corretamente instalado faremos dois testes:

Primeiro Teste: Node

Abra o Terminal ou CMD do seu sistema e digite node -v, esse comando deve retornar a versão do Node instalada, que no meu caso é a v12.13.1.

Segundo Teste: NPM

AINDA NÃO FECHE O TERMINAL! Se acostume a deixá-lo sempre aberto!
Dessa vez executaremos o comando npm -v para verificarmos a instalação do NPM - que deve ter ocorrido junto da do Node automáticamente.

Se deu tudo certo pra você, finalizamos assim essa primeira leva de preparação do ambiente. Nem foi tão difícil, né? No próximo artigo vamos instalar o Framework7 em si, fique ligado.

Ah, e tá com alguma dúvida? Não conseguiu instalar tudo certinho? Deixa no comentário seu problema que a gente ajuda.

Introdução ao Desenvolvimento Mobile com Framework7

Isaac Batista — Sat, 07 Dec 2019 22:25:33 +0000

O que é o Framework7?

É um framework para o desenvolvimento de aplicações mobile com HTML, CSS e Javascript. Pra fins didáticos vamos dizer que ele é meio que uma fusão do JQuery (biblioteca Javascript que ajuda a manipulação do HTML) com o Bootstrap (framework para desenvolvimento de interfaces responsivas), adicionado de features para lidar com o ambiente mobile/desktop. Um similar muito popular é o Ionic.

Inicialmente, nós vamos trabalhar apenas no navegador, pra que possamos por a mão no código mais rápido e evitar a chatisse da preparação do ambiente toda de uma vez. Mas não se preocupe, aprenderemos a instalar nossos aplicativos nos dispositivos para que possamos mostrar nosso app por aí.

O que é interessante saber desde já?

Cada plataforma tem sua forma exclusiva de desenvolvimento de apps. Sua forma nativa. Que no caso do Android é utilizando as linguagens Java ou Kotlin, e do iOS é utilizando Objective-C ou Swift. Só de ler isso você já deve imaginar o quanto de trabalho não dá escrever um aplicativo nativo para as duas plataformas.

A vantagem é a proximidade que você está do dispositivo, isso é: você tem um melhor acesso a todas as funcionalidades - isso sem falar da peformance. Nesse contexto, existem diversas ferramentas que tem essa ideia de programar só uma vez e rodar nos dois ambientes.

E é nessa categoria que o Framework7 se encaixa, a do desenvolvimento híbrido.

Do lado de cá, abrimos mão de um app totalmente fluido e com acesso a tudo que o dispositivo disponibiliza para reduzir o custo de produção.

Para que fique claro: a melhor alternativa vai sempre depender do contexto.

Por hoje é só, mas fique atento que no próximo artigo vamos preparar o ambiente para usar o framework7 e começar a codar. Até lá.