Yo diría que ninguna de sus ideas iniciales captura la imagen completa. La idea 1 es solo una devolución de llamada. Si desea utilizar una devolución de llamada: useCallback
. Idea 2 funcionará y es preferible si no necesita usar redux. A veces es mejor usar redux. Quizás esté configurando la validez del formulario marcando que ninguno de los campos de entrada tenga errores o algo similar. Como estamos en el tema de redux, supongamos que ese es el caso.
Por lo general, el mejor enfoque para el manejo de errores con redux es tener un campo de error en estado que luego se pasa a un componente de error.
const ExampleErrorComponent= () => {
const error = useSelector(selectError);
if (!error) return null;
return <div className="error-message">{error}</div>;
}
El componente de error no solo tiene que mostrar un error, también podría causar efectos secundarios useEffect
.
La forma en que se establece / desarma el error depende de su aplicación. Usemos su ejemplo de número de teléfono.
1. Si la verificación de validez es una función pura, se puede hacer en el reductor.
Luego establecería o desarmaría el campo de error en respuesta a las acciones de cambio de número de teléfono. En un reductor construido con una declaración de cambio, podría verse así.
case 'PHONE_NUMBER_CHANGE':
return {
...state,
phoneNumber: action.phoneNumber,
error: isValidPhoneNumber(action.phoneNumber) ? undefined : 'Invalid phone number',
};
2. Si el backend informa de errores, envíe acciones de error.
Digamos que está enviando el número de teléfono a un backend que valida antes de hacer algo con el número. No puede saber si los datos son válidos en el lado del cliente. Solo tendrá que tomar la palabra del servidor.
const handleSubmit = useCallback(
() => sendPhoneNumber(phoneNumber)
.then(response => dispatch({
type: 'PHONE_NUMBER_SUBMISSION_SUCCESS',
response,
}))
.catch(error => dispatch({
type: 'PHONE_NUMBER_SUBMISSION_FAILURE',
error,
})),
[dispatch, phoneNumber],
);
El reductor debería aparecer con un mensaje apropiado para el error y configurarlo.
No olvides desarmar el error. Puede desactivar el error en una acción de cambio o al realizar otra solicitud según la aplicación.
Los dos enfoques que describí no son mutuamente excluyentes. Puede usar el primero para mostrar errores detectables localmente y también usar el segundo para mostrar errores del lado del servidor o de la red.