(newbie) om/react modelling question

[Colin Yates]

Newbie modelling question here. The general question is do I have multiple instances of the same component configured differently or a single instance which is parameterisable?

I have a SPA with a set of sub "pages". Each sub-page has a banner at the top. This banner displays the title but it might also display sub-page specific information. For example, the search page will display a summary of results in the banner, which when clicked on does something. The project-list sub-page will display any outstanding projects which when clicked on does something else. Essentially the "banner" might be fundamentally different between sub-pages".

In other words, when looking at the welcome page I want this:
- page
-- banner
--- title: "Welcome"

On the search page:
- page
-- banner
--- title: "Search results"
--- SearchResultsBannerComponent

On the project page:
- page
-- banner
--- title: "Projects"
--- ProjectBannerComponent

In direct-dom-manipulation world I would replace the banner div on navigation. In react world I can see three approaches:

1) a single instance of banner which knows how it is used everywhere. One of the configuration parameters must be a component itself (or resolvable to a component through dynamic dispatch)
2) each sub-page is a component hierarchy each including their own configuration of the banner component. So three pages, three instances of the banner. Each sub-page lives in the dom but only one is visible at any one time (display: none for example)
3) like 2 but the component hierarchy is rebuilt upon navigation.

I really hope it isn't 1 as that (unless I misunderstand) is quite restrictive. I can see Clojure's fantastically flexible dispatching capability helping but it still seems the wrong way to chunk concerns.

2 or 3 seem to be the same approach - multiple component hierarchies, choosing 2 or 3 is a matter of style? 2 or 3 would work with something dispatching on the ":current-sub-page", the result of which is the appropriate hierarchy.

In fact, 3 seems the most "idiomatic" way forward, replying on the efficiency of the diff'ing technique - not sure.

The trouble is I have seen examples of all three :). I don't know what option 4 is but I am sure it exists.

Help :).

[Ahmad Hammad]

Good question. although I would lean towards 3, i think the solution can vary a lot depending on how you setup your navigation/route handling and how it triggers the new page to render. For example you could let your router/controller decide that the sub-page should show the projects component in this section and the project banner component in the banner section, and the projects component will not have to know about it.

If you could shed some more light on your current nav/routing structure it might be easier to come up with an appropriate approach.

[Colin Yates]

Thanks Ahmad. Regarding the navigation, it is all chicken and egg and
I haven't got there yet :). I wanted to check my assumptions first and
that I hadn't missed the point of React. I wanted to make sure I had
made the paradigm shift into React.

I do get your point about how the navigation influences this.

On 29 October 2014 12:36, Ahmad Hammad <a.f.h...@gmail.com> wrote:
> Good question. although I would lean towards 3, i think the solution can vary a lot depending on how you setup your navigation/route handling and how it triggers the new page to render. For example you could let your router/controller decide that the sub-page should show the projects component in this section and the project banner component in the banner section, and the projects component will not have to know about it.
>
> If you could shed some more light on your current nav/routing structure it might be easier to come up with an appropriate approach.
>

> --
> Note that posts from new members are moderated - please be patient with your first post.
> ---
> You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/bkdVlT9LZbk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.
> To post to this group, send email to clojur...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

[Ahmad Hammad]

I was in the same boat with regards to navigation. I briefly described the approach i'm toying with here: https://groups.google.com/forum/#!topic/clojurescript/E2Lxody9SlM , however the concern of "layouts" which includes your question is something I will have to tackle soon in my app but I don't see it being too difficult with that approach.

[Colin Yates]

Yeah, I had already read that and it helped.

I am currently also tossing up how much state to keep in app-state versus component local state. For example, is the fact the menu expanded or collapsed app or local? Benefit of app is that taken to its logical conclusion you can serialise the entire front end in a single atom. Reproducing bugs is now a case of "email me the app-state" rather than "give me a set of steps".

This om malarky really does change things :).

[Ahmad Hammad]

It looks like David Nolen is already thinking about building in support for that:

"experimental support to write component local state into global state"
https://github.com/swannodette/om/commit/7946ad354befd89b49aca71d775e75131acb8381#diff-8b1c3fd0d4a6765c16dfd18509182f9dR8