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.