1
resposta

[Sugestão] Por que não usar a mesma tela de criação de tarefas para edição?

Seria muito mais fácil fazer uma tela dinâmica que pudesse lidar com a criação e atualização de tarefas, ja que a tela de edição seria praticamente igual a de criação.

1 resposta

Salve, Felipe!

Seu pensamento tá na direção certa — realmente, a tela de criação e a de edição são muito parecidas, e faz todo sentido pensar em como evitar essa duplicação. Inclusive, eu deixei isso em aberto justamente pra ser um desafio de prática. Extrair o que é comum e finalizar o app por conta própria é um ótimo exercício.

Mas já que você levantou o ponto, deixa eu compartilhar o racional que eu costumo seguir nesse tipo de situação.

A primeira tentação é criar uma tela só que "sabe" se tá criando ou editando — tipo receber um parâmetro mode ou verificar se veio um id na rota. O problema é que isso costuma gerar uma porção de ifs espalhados pelo código: "se tá editando, busca a tarefa; se tá criando, começa vazio", "se tá editando, chama updateTask; se tá criando, chama addTask", e por aí vai. Funciona, mas a tela vai ficando cada vez mais difícil de entender conforme cresce.

O que eu prefiro fazer é separar de outro jeito: abstrair só o visual que é comum (o formulário em si) e deixar o comportamento específico (adicionar vs editar) como responsabilidade de cada página. Assim cada página sabe exatamente o que ela faz, sem precisar de condicionais pra descobrir em qual "modo" ela tá.

Pra te dar um spoiler de como fica, a tela de edição no curso onde praticamos isso fica assim:

import { router, useLocalSearchParams } from "expo-router";
import { Text, View } from "react-native";
import useTaskContext from "../../components/context/useTaskContext";
import FormTask from "../../components/FormTask";

export default function EditTask() {
    const { id } = useLocalSearchParams()
    const { tasks, updateTask } = useTaskContext()
    const task = tasks.find(t => t.id == id)

    const submitTask = (description) => {
        updateTask(id, description)
        router.navigate('/tasks')
    }

    if (!task) {
        return (
            <View>
                <Text>
                    Não foi encontrada uma tarefa com o id: {id}
                </Text>
            </View>
        )
    }

    return (
        <FormTask onFormSubmit={submitTask} defaultValue={task.description} />
    )
}

Percebe que o FormTask é o componente que tem todo o visual (o input, o botão, os estilos). Mas quem decide o que fazer quando o formulário é submetido é a própria página. A EditTask passa o updateTask, a AddTask passa o addTask. O formulário não precisa saber se tá criando ou editando — ele só avisa "ó, o usuário submeteu isso aqui" e deixa a página resolver.

Esse é um tradeoff que vale a pena pensar: abstrações economizam código, mas também adicionam complexidade. Às vezes uma tela "duplicada" mas simples é mais fácil de manter do que uma tela super flexível cheia de condicionais. O ponto de equilíbrio que eu gosto é esse — extrair o visual, manter o comportamento explícito em cada lugar.

Ah, e se quiser continuar praticando e adicionando mais funcionalidades nesse app, no curso React Native: praticando customizações a gente faz isso.