0

I'm creating an application that stores user's data in multiple database tables - info, payments and booking (this is a booking system).
In 'info' table I store the user info such as email, name, phone, etc..., In 'payments' table I store his payments details and in 'booking' I store his booking history.

My questions is - What is the best way of representing this data in Flux architecture? Do I need 3 different stores (for each table) or a single store (let's say 'UserStore') that holds all user's data?

Basically, I have a dashboard component that should show all user's data.

In case I should go with the 3 different stores solution, is it possible to know when all of them finished loading their data (since each store loads the data asynchronously from the DB)?...

Thanks!

Amit Kaspi
  • 835
  • 2
  • 10
  • 19
  • 1
    With Reflux you can mixin multiple stores into one. That way the component only has one store to deal with. If the data fetching is fast enough you could just get it serially. Otherwise you have to create state in the store as to the status of the gets. – J. Mark Stevens Sep 14 '15 at 19:39

1 Answers1

0

Generally, less stores is better (easier to maintain).
Rule of thumb I use: if a store gets bigger than 300 lines of code, then you should consider splitting up in different stores.
In both solutions (one store or 3 stores) you will need code to manage dependencies between the tables. The code just lives in different files/stores.

About the user dashboard you mention: avoid storing redundant data in your store(s). So if you have e.g. total number of bookings for a user, make a getter function that does live calculation.

Better not let stores load data from the DB or server-side directly, but create a WebAPIUtil that fires an update-action when new data comes in. See the 'official' flux diagram. offical flux diagram
The stores can have a waitFor function that wait until another store is updated.

wintvelt
  • 13,855
  • 3
  • 38
  • 43