Not a bad model, though a bit hard to consume (read) in the large code chunks presented in the article. I'd say adding a diagram - even if hand-drawn - of how the whole relationship works would give a much better birds eye view of the proposed architecture.

I am doing something similar with Provider, and you are right, it's a fantastic way to solve the problem. I have entirely separated my UI from my methods, the user model and my Firebase calls and I have yet to find a view that cannot be done with a stateless component (I have nothing against them when used sporadically). I found that it was crucial to make a very clear separation between the app and Firebase because if at any point I decide I want to move to Amazon Amplify or any other service for that matter, I want to be able to just change my network calls and leave everything else as untouched as possible.

Writer of code, blogs and things that live on the web. Pragmatic doer, Lego fan, Mac user, cool nerd. JavaScript and Flutter enthusiast. editor.