Fork me on GitHub
#untangled
<
2016-12-01
>
baris15:12:46

Hi, I have some trouble to understand the local app-state in the untangled-template-workspace project. To be more precise with the “Pages” component. If I print out the current app-state (with log-app-state) all the defined pages e.g. main, login, new-user have the query and the data from all other defined pages and also the [:ui/fetch-state …] for each of them. Is this correct behavior or do I miss something? Compared to the Video Tutorial “Using Unions for Efficient Tabs/Routing" I don’t understand the duplication of those data.

baris15:12:07

Btw: What's the best practice or solution to design a dynamic multilevel navigation in the local app-database? For example something like that.

{:ui/locale "en-US"
   :pages [{:id :page-a
            :name "Page-A"
            :icon "a-icon"
            :sub-pages [{:id :sub-a
                         :name "Sub-A"
                         :icon "sub-a-icon"}]}
           {:id :page-b
            :name "Page-B"
            :icon "b-icon"
            :sub-pages []}]})

A typical use-case would be showing different navigations for different clients e.g. Desktop, Mobile.

baris15:12:17

Following the example in the template-workspace I’d need to define my pages in the Pages Component and then I can run (om/transact! …) to switch the page. Is there a more elegant and dynamic way to populate the Switcher Pages component and build the navigation structure dynamically?

baris21:12:32

Ok, looking a the tab-interface example in the cookbook, the same “duplications” are also available in the local app-state. Mostly surprising is the appearance of these ui/fetch-state‘s as already mentioned. Is this attributable to the union queries?