Mi rendo conto che questo è stato chiesto qualche tempo fa, ma ho pensato di buttare i miei due centesimi.
In realtà sto lavorando a un progetto che sta facendo qualcosa del genere al minuto. La mia opinione sarebbe di non farlo, a meno che tutti i tuoi casi d'uso non possano seguire la stessa logica.
Ho riscontrato un problema in cui è presente un componente che gestisce gli errori e visualizza i messaggi all'utente. Ha risposte integrate, ad es.
- Non è stato possibile connettersi ai server, riprova
- Sembra che ci siano difficoltà tecniche, riprova più tardi
- Sembra che tu non abbia una connessione dati
ecc.
Il problema principale con questo è che i messaggi di errore vengono presi fuori dal contesto. La ricezione di un errore generico A nella prima schermata potrebbe generare "Mi dispiace non poterci connettere", tuttavia non voglio mostrare che sullo schermo in cui hai effettuato un ordine, voglio dire, ad esempio "Il tuo ordine non poteva 'essere elaborati in questo momento ".
Quello che potresti facilmente fare è creare una super classe per i gestori degli errori, quindi potresti creare sottoclassi diverse e passare una di quelle nel tuo "Single widget" come parametro init, che manterrebbe intatta la tua modularità.
Tuttavia il grosso problema che vedo con questo è il sovraccarico associato a questo, dato che i clienti vogliono sempre piccoli cambiamenti qua e là. Quando ciò accade, rielaborazione / creazione di un altro widget, solo per visualizzare sullo schermo una porzione di testo.
La mia opinione è che le situazioni di errore siano meglio gestite passando in un blocco di fallimento di qualche tipo. La logica per visualizzare una vista di avviso personalizzata può essere sottratta, ma può essere comune a situazioni diverse per richiedere messaggi diversi per lo stesso errore.
Come ho detto prima, se ti trovi in una situazione in cui nulla cambierà mai (lo sai mai davvero?), quindi fallo, meno codice duplicato è sempre un vantaggio.