[x] All keys within the values in the state are accessible in the schema
[x] Correctly formatted
[x] Sample state is rendered with triple backticks, and the language ```javascript...```). This will display the state as a code block instead of a giant line of text
[x] Top level slices
[x] entities
[x] session
[x] errors (here or in ui)
[x] ui (if needed)
[x] Should NOT have nested slices, aka comments inside of posts
Some info from other tables is ok, for instance:
the author username and imageurl for a post. basically any info that the user can't change
like count and a boolean on whether the user likes the post instead of a likes slice
Comments
Generally looks good. We talked about the business tags joins table in schema and I see that reflected in your state, but it is not necessary. Instead, get rid of business tags slice of state and have the tagIds as an array in each business. Keep the tags slice of state as is.
I would recommend having a reviewIds array within each business in the business slice of state to keep track of all of the related reviews
Sample State
```javascript...```
). This will display the state as a code block instead of a giant line of textentities
session
errors
(here or inui
)ui
(if needed)comments
inside ofposts
Comments
tagIds
as an array in each business. Keep the tags slice of state as is.reviewIds
array within each business in the business slice of state to keep track of all of the related reviews