Navigation Best Practices about re-frame HOT 8 CLOSED

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])])))

from re-frame.

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.

from re-frame.

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.

from re-frame.

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.

from re-frame.

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.

from re-frame.

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.

from re-frame.

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

from re-frame.

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.

from re-frame.