Basically. I don't remember exact details off the top of my head, but the point of having denormalized data is mainly performance: performance of the query to feed the UI, performance of the network result processing, etc. Many reports are purely derived data and taking the normalization hit is senseless. As far as using the specific options, read the docstrings. If those are insufficient check out the demo. If that isn't enough, then use the source. The report state machine really isn't that big for the number of features is supports.

Thanks Jakub for a new exercise. In https://fulcro-community.github.io/guides/tutorial-minimalist-fulcro/index.html#_components_initial_state are given a few reasons why we'd like to use it. Which point is the exercise testing? Is is the point When you want to make sure that the component has particular props before any data is loaded from the backend.

Hi, and thank you! The goal is to make sure that you understand that you can make arbitrary edges in the client DB and that you can use eg initial state for that (though how you do it is secondary to the fact that you can do it).

in that case my knowledge of initial-state is limited to using it like this: :initial-state {:ui/number 0} when populating a form with some date before getting data from server.

I guess you also know to compose child's init state into parent's?

@U0530ACAK are you implying that you don't know how to do the task because you don't know enough about initial state?