🧩 Da lista ao editor e de volta

Imos reunir o aprendido nunha aplicación pequena: unha lista de alumnos na que podemos premer un nome, editalo noutra pantalla e gardar ou cancelar.

Parte	Responsabilidade
PantallaAlumnos	Garda a lista no seu State e mostra unha fila por alumno.
EditorAlumno	Recibe o nome inicial e prepara un controlador para editalo.
Botón Gardar	Valida o nome e devólveo con Navigator.pop.
Pantalla da lista, ao volver	Recibe o nome con await e actualiza a fila con setState.

🧪 Exemplo completo

🔗 DartPad:

• https://dartpad.dev/?id=874583ca211d91e9bd09bb269f95bf29.

🔍 Seguir unha edición paso a paso

1. Prememos «Iria». A súa fila chama a _editar(1), pois ocupa a segunda posición da lista.
2. O construtor recibe nomeInicial: 'Iria'. No editor, widget.nomeInicial permite preparar o controlador en initState.
3. Cambiamos o texto a «Iago». Polo momento só cambia o campo; a lista aínda conserva «Iria».
4. Ao gardar, validamos e devolvemos «Iago» con Navigator.pop. Continúa o método _editar, que estaba esperando.
5. Se a pantalla segue montada e recibiu un nome, substitúe _alumnos[1] e chama a setState para mostrar o cambio.

Ao cancelar, ou volver coa frecha, o resultado é null e mantense «Iria». Proba tamén a borrar todo o texto e gardar: o erro aparece no campo e o editor permanece aberto.

Aquí podemos conservar o índice porque a lista non cambia por outra vía mentres o editor está aberto. Nunha aplicación con cambios simultáneos convén identificar cada alumno cun id estable.

💡 Se máis adiante empregas obxectos mutables, pasar un alumno polo construtor non crea unha copia: cambiar os seus atributos podería modificar o orixinal antes de gardar. Mantén a edición nos campos e devolve os novos datos só ao confirmar, como facemos aquí co nome.

🗂️ Separar os ficheiros

Igual que fixemos cos widgets propios no Tema 3.2, podemos separar:

• main.dart: inicia e configura a aplicación.
• pantallas/: lista e formulario de edición.
• widgets/: compoñentes reutilizables.
• modelos/: clases cos datos, cando sexan necesarias.

Cada ficheiro importa o que utiliza. Non copiamos main() nin creamos outro MaterialApp en cada pantalla. É unha organización inicial; non necesitamos unha arquitectura máis complexa para estes exemplos.

Os datos destes temas viven na memoria. Pechar e iniciar a aplicación non conserva os cambios; gardar en ficheiros ou bases de datos é outro paso, tratado na ampliación do Tema 3.6.