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.
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
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.
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.