[x] You'll want to make the keys consistently camel case (there's an easy way to convert keys to camel case in jbuilder, I'll be sure to touch on this during a checkin next week)
[x] Likewise with what I mentioned about the database, any addition of wishlists / removal of breweries / other changes should lead to updates to your sample state as well.
What does the toast part of the ui slice of state refer to?
Suggestions / Thoughts:
[x] You should probably store the stats for the drink show page (such as average rating and total number of ratings) as part of the drinks slice of state (if you have small enough seed data where you fetch every checkin with a drink show page, you could probably do all those calculations on the frontend inside the component, but might be cleaner to calculate it on the backend and include that in your jbuilder views / state).
Regarding your question about where drink / brewery images come from: since it's not part of your create drink / brewery form, I'd recommend just having seeded images for all your seeded beers / breweries, and for new, user-uploaded ones, use some stock photo. Likewise, I'd recommend using a stock photo for the user profile image (in which case, no need to have that stored in the users slice of state, if all users have the same prof pic)
Regarding has_many through relationships on the frontend, I'd recommend just writing selector functions (which you could define in a util file and the use in your mSTP) that do that work for you. (Example, first grab all the beers in the beers slice of state for a brewery, then iterate through those and grab all their associated checkins).
To Revise:
toastpart of the ui slice of state refer to?Suggestions / Thoughts: