Data models for React / Firestore apps

[Alan deLespinasse]

What's your favorite way to build a data abstraction (aka "state management") for a React / Firestore app? (A lot of the same issues probably come up if you're using RTDB, or a framework other than React, but React / Firestore is the combination I've ended up using).

Strategies I can think of include:

• No abstraction, or "Firestore is the abstraction": You pretty much load data into the app from Firestore as is, and any part of the app that wants to update it just modifies Firestore directly. Ok for quick-and-dirty apps, but usually ends up being major technical debt if you end up having to maintain the app at all. This is the only style I've seen in example apps.
• Use Redux or similar: I don't think it's a great fit, but it would be interesting to see how someone might do this. (I'm not a big fan of Redux based on my limited experience with it, but that was a while back and I've been meaning to give it another look.)
• Make a custom data abstraction, consisting of a class (or several) that take care of loading the data, transforming it into the form that the app needs, and having methods to call to make updates, which would then apply the appropriate changes to Firestore. Or alternatively have separate model and controller classes. This is my current preference, if I'm starting a new project.

I'm considering an experiment where I'd write the same demo app all three ways, then write an article comparing them.

Anyone have any wisdom on this topic?

[Alan deLespinasse]

Also, would anyone be interested in reading that article if I wrote it?

[Tracy Hall]

General article-writing advice:

No one will know if they would be interested, nor will *you* know if they will be interested, until you write it.  You'll learn an enormous amount, yourself, *if* you write it.

Write it.

[Alan deLespinasse]

Yes, I was thinking the same thing, and I do plan to do it anyway just for my own learning, even if no one else expresses interest.

On the other hand, I know I would like to read this article if someone else wrote it, so I thought I might as well ask; it could give me some extra motivation if other people said they'd like to read it.

[Bryan McConnahea]

As you stated, it depends on the level of project, but generally, I like option 3 as a lib that can be shared between projects iterated on and improved over time.