Navigation Best Practices

[taylorSando]

I have been thinking about what's the best way to structure the app map so that it can deal with navigation.

You can dispatch navigation events like :section/navigation, or :section.subsection/navigation

Seems like you need to have a navigation key in your app structure. For example {:x 1 :y 1 :active-nav :x}

That way top level views know what sections to display. You could do it for app data and views that are nested as well {:x {:a 1 :b :active-nav :b}} :y 5 :active-nav :x}

The other way might be something like {:x {:display :true} :y {:display :false}}

Though every time you wrote a navigation event handler, you'd have to have one that caused all the displays to be false, and then set the active one. Would be a pain if you keep adding sections.

[mike-thompson-day8]

Yep, we've used that pattern:

1. Your app-db has an :active-panel key containing an id (for the panel being displayed).

2. When the user does something navigation-ish (selects a tab, a dropdown or something which changes the active panel), then the associated dispatch looks like this:

   (dispatch [:set-active-panel :panel1])

3. Some high level reagent view has a subscription to :active-panel and will switch the associated view.

(defn panel1
   []
   .....)

(defn high-level-view
   []
   (let [active  (subscription [:active-panel])]
      (fn []
         [:div
             [div.title   "Heading"]
            (condp = @active                ;; or you could look up in a map
               :panel1   [panel1]
               :panel2   [panel2])])))

[taylorSando]

Seems like you could also hold the majority of your data in local storage, or datascript. Then just pull out what information you need into app-db based on events. That way you only have relevant data in your app-db at any given time. Though your views would still be looking for the presence of certain keys or values in a conditional, or multimethod.

[mike-thompson-day8]

We put all our data into app-db. The moment you have data in two places, you have a synchronization problem. Client/Server is bad enough much less adding multiple places in the client.

[mdhaney]

I keep all the page definitions, including the render function, uri, and nav menu text in app-db, along with a :current-page key and use a single :show-page handler. Here's an example:

https://github.com/mdhaney/homesale-clj

The main routing code is in the core namespace. You can also look in ui/navbar to see how I use the page definitions to build the nav menu.

Lot's of cleanup to be done still - in the process of removing all the Bootstrap "add 10 classes to do anything useful" style code. But the basic concept has worked for me on several apps.

[gaconnet]

I would love to see this covered in the wiki with the same aplomb we see in the excellent README. Navigation has an awkward bi-directional nature that always sets my head spinning:

• Sometimes a change in app state should lead to a change in URL
• Sometimes a change in URL, such as onpopstate & onpageload, should lead to a change in app state.

Can we put the URL on the conveyor belt and treat it the same as we do our <input/> fields?

A second point of confusion for me: Suppose app-db contains state that is effectively scoped under panel1—for example, the text of a search field, a collection of orders matching that search, and a subset of that collection that the user selected for some upcoming action—and then onpopstate dispatches panel2 to replace panel1. Should panel1's "local" state get removed from app-db? If so, who is responsible for doing that?

I know I would greatly benefit from seeing these nuances of navigation treated in the docs.

[gaconnet]

After writing this I realized that panel1 is the "local" state and my second point of confusion is already covered by the README and by the subscription in the example given above. Oops. Old mutable thinking habits die hard.

It would still be nice to see the bi-directional aspect of navigation treated via the conveyor belt, if it can be.

[mike-thompson-day8]

I've created a brief placeholder page for further explanation in the Wiki:
https://github.com/Day8/re-frame/wiki/A-Larger-App

[mike-thompson-day8]

Given we now have a basic wiki entry for this, I'm closing.
If you feel that you'd like to flesh out that Wiki page with some of your experience, please do because it is currently pretty basic.