call changeView from App.js rather than from cDM in (Page) components

[SherylHohman]

OMG - revelation! If I call changeView from just inside the <Switch> statement in App component, then store will always (it's still asynch, but..) have the current url info when componentDidMount gets called.

Thus, don't need to decide whether to callgetLoc using (store, null) or (store, routerProps).

In fact the components no longer need routerProps !!

This simplifies

• App calling components (don't need to pass in routerProps
  • mapStateToProps inside the components, as they only need store not
  • viewData, and posts selectors (maybe others as well) can be simplified, as there will now (mostly) only be 1 version necessary.

---

How to Access routerProps from <Switch> context.router gives access to location and match. These are the only properties I use (form "routerProps") anyway.

[SherylHohman]

OK. <Switch>, since it "matches" on all urls `"/"will Not work !

BUT, if I can access Route.state, it has exactly what I need !

State
  match: {…}
    isExact:  true
    params:  {…}
      categoryPath:  "react"
      path:  "/:categoryPath"
    url:  "/react"

This (plus routeName, which is derived from the above "path" plus my ROUTES) is exactly the information I need when calling changeView and updating store.viewData.loc !!

So the question is, can I access and use that info from within the <Route> render method to first call changeView, then render my component ??

Or must I keep all as it currently is ?

Hmm.. maybe what I need is an Higher Order Component ?? Is HOC where I extendRoute with extra capabilities ??

I could call it PageRouteor RoutePage because I only want to save Exact PAGE urls to the store, and this PageRoute would be used to call / render components are responsible for a full PAGE. (which could be container components that hold all the components that make up a page).

MORE Research Needed.

[SherylHohman]

Another interesting tidbit:
Router Context has Route.history with an action(actionType) called "PUSH"

Perhaps my actionCreators/reducers can listen for an action === "PUSH" to trigger an update to store.viewData.loc (would need to also somehow get access to the new url)

<Route>

Context
  router:{…}
    history:{…}
     action:"PUSH"
      ..
    goBack()
    ..
    location:{…}
    ..
  route:{…}
    location:{…}
      hash:""
      key:"4l6uj5"
      pathname:"/react"
      search:""
    match:{…}
      isExact:false
      params:

[SherylHohman]

Nevermind. the action from the previous comment is not an action that will get dispatched when history object is updated ! DUH - that would not even make sense.

Instead, it might be the action that was last dispatched.

For example, looking at Context.router.history.actionlater, it held "POP".

So.. previous comment is NOT useful.

[SherylHohman]

https://reactjs.org/docs/higher-order-components.html

At first glance, it seem creating an HOC to wrap my Page components may work. It would call changeView with routerProps, which would determine whether or not store.viewData.loc should update its url data (params, route, routeName, url).

This makes components that render a Page would become explicit in that they render PAGE urls.

And ensures thatn changeView always called for PAGE views. And if I'm hands-off - ie don't call changeView from any component directly, then it will Never be called unless a Page is being rendered.
One less thing to think about. Updating viewData.loc becomes automatic.

And pulling loc from store will always give m the correct values, no checks necessary. (Caveat: changeView updating state is asynch, so depending on how React handles the Page components, loc might not have the correct value in cDM, but I assume it would. If not, it's ok, it would just eat a render cycle (for loc to upate and value within the component to change). Not an Issue. Ya, if it's incorrect, then a fetch could occur on the wrong info, followed by a fetch on the correct info. No different than what the app did before I wrote code to allow me to specify it to use routerProps over store - an optimization that did not need to happen. And, I suspect that the wrapped Page component would receive the correct info at cDM, not at cWillReceiveProps.

Overall, this would simplify code in the components.