{"action":"created","issue":{"url":"https://api.github.com/repos/faceyspacey/redux-first-router/issues/126","repository_url":"https://api.github.com/repos/faceyspacey/redux-first-router","labels_url":"https://api.github.com/repos/faceyspacey/redux-first-router/issues/126/labels{/name}","comments_url":"https://api.github.com/repos/faceyspacey/redux-first-router/issues/126/comments","events_url":"https://api.github.com/repos/faceyspacey/redux-first-router/issues/126/events","html_url":"https://github.com/faceyspacey/redux-first-router/issues/126","id":261352959,"number":126,"title":"Maybe we need something more obvious for nesting routes","user":{"login":"Aetherall","id":13298494,"avatar_url":"https://avatars2.githubusercontent.com/u/13298494?v=4","gravatar_id":"","url":"https://api.github.com/users/Aetherall","html_url":"https://github.com/Aetherall","followers_url":"https://api.github.com/users/Aetherall/followers","following_url":"https://api.github.com/users/Aetherall/following{/other_user}","gists_url":"https://api.github.com/users/Aetherall/gists{/gist_id}","starred_url":"https://api.github.com/users/Aetherall/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Aetherall/subscriptions","organizations_url":"https://api.github.com/users/Aetherall/orgs","repos_url":"https://api.github.com/users/Aetherall/repos","events_url":"https://api.github.com/users/Aetherall/events{/privacy}","received_events_url":"https://api.github.com/users/Aetherall/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2017-09-28T15:05:33Z","updated_at":"2017-09-29T04:12:54Z","closed_at":"2017-09-29T02:15:15Z","author_association":"NONE","body":"Hi !\r\nMy main ( and only ) problem, is that nesting routes seems not really consistant\r\n\r\nlet's say I have that kind of app structure\r\n\r\n/dashboard  => Dashboard stuff\r\n/dashboard/posts => ListOfPosts\r\n/dashboard/posts/add => AddPostForm while keeping ListOfPosts\r\n/dashboard/posts/:id => EditPostForm while keeping ListOfPosts\r\n  \r\n\r\n/dashboard/posts/add =>\r\n````javascript\r\n<Switch>\r\n  Dashboard\r\n  <Switch>\r\n    Posts\r\n    <ListOfPosts />\r\n    <Switch>\r\n      AddPostForm\r\n    </Switch>\r\n  </Switch>\r\n<Switch>\r\n````\r\n\r\nThe thing is that if I name /dashboard as DASHBOARD and /dashboard/posts as DASHBOARD_POSTS, and then I go to DASHBOARD_POSTS, the matching of the first switch will require additionnal logic to keep it on the right component\r\n\r\nI have the feeling that i should treat all my segments as variables and have that kind of routemap\r\n/dashboard(/:1)(/:2)(/:3)\r\n\r\nbut this would not be consistant as in the future I could add /dashboard/backup or other things which would need another kind of logic...\r\n\r\nI may have misunderstood the way to do things though"},"comment":{"url":"https://api.github.com/repos/faceyspacey/redux-first-router/issues/comments/333026688","html_url":"https://github.com/faceyspacey/redux-first-router/issues/126#issuecomment-333026688","issue_url":"https://api.github.com/repos/faceyspacey/redux-first-router/issues/126","id":333026688,"user":{"login":"faceyspacey","id":154732,"avatar_url":"https://avatars0.githubusercontent.com/u/154732?v=4","gravatar_id":"","url":"https://api.github.com/users/faceyspacey","html_url":"https://github.com/faceyspacey","followers_url":"https://api.github.com/users/faceyspacey/followers","following_url":"https://api.github.com/users/faceyspacey/following{/other_user}","gists_url":"https://api.github.com/users/faceyspacey/gists{/gist_id}","starred_url":"https://api.github.com/users/faceyspacey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/faceyspacey/subscriptions","organizations_url":"https://api.github.com/users/faceyspacey/orgs","repos_url":"https://api.github.com/users/faceyspacey/repos","events_url":"https://api.github.com/users/faceyspacey/events{/privacy}","received_events_url":"https://api.github.com/users/faceyspacey/received_events","type":"User","site_admin":false},"created_at":"2017-09-29T04:12:54Z","updated_at":"2017-09-29T04:12:54Z","author_association":"OWNER","body":"basically create the following component and on the line linked replace it with our own match-path package:\r\n\r\nhttps://github.com/ReactTraining/react-router/blob/master/packages/react-router/modules/Route.js#L5\r\n\r\nhere's our package, which is a fork of their `match-path` functionality:\r\n\r\nhttps://github.com/faceyspacey/rudy-match-path\r\n\r\nthen instead of getting location state from React Router `context`, you connect the component to redux and get it from `state.location`. Here's what you replace:\r\n\r\nhttps://github.com/ReactTraining/react-router/blob/master/packages/react-router/modules/Route.js#L46\r\n\r\nNext, you'll see this line:\r\nhttps://github.com/ReactTraining/react-router/blob/master/packages/react-router/modules/Route.js#L101\r\n\r\nBasically, it's taking the props (i.e. `path`, `exact`, etc) and calling `computePath` which calls `matchPath` with the `nextProps`, and `nextContext.router`. But instead of `nextContext.router`, you have `nextProps.router`, or similar, where you created `router` out of RFR state. So it would be something like: \r\n\r\n```js\r\nthis.setState({\r\n      match: this.computeMatch(nextProps, nextProps.router)\r\n})\r\n````\r\n\r\nThe final component you create can take 1 of 2 routes:\r\n\r\nIt can mirror the RR Route component api exactly, where each route's component receives , `match`, `location`, `history`, OR you can make it RFR-specific and just pass in `type` and `payload`, or just `state.location`. You won't need `history` anymore since you should be changing the URL now by dispatching actions. You likely won't need all the info in `match` and `location`, as the primary info is just our own `state.location` object. You could also do nothing, and let the child component connect via `react-redux` to extract only the precise state it wants, which would be more optimized to prevent unnecessary re-rendering. \r\n\r\nAt the end of the day, you just have to understand the business logic that `<Route />` is doing. It's simply taking 2 paths:\r\n\r\n- `<Route path='/foo' />`\r\n- export Route = `connect(state => ({ location: state.location })(RfrRoute)`\r\n\r\nThen you need to make:\r\n```js\r\nclass RfrRoute extends React.Component {\r\n  // then you do the work here to combine the 2 aspects: redux location state + matching:\r\n  // props.location.pathname + props.path\r\n}\r\n```\r\n> And the `rudy-match-path` library which is pretty much the same as the `matchPath` function imported to RR's Route component will do the work of detecting if the passed path matches the actual path of the address bar in `props.location.pathname`. And if you're not doing `exact`, it will do what you're trying to do where partial paths match, thereby allowing for nested routes. And if you really want to do nested routes fully, make sure you have something like `match.url` as well, which passes in the parent path segment, so you don't have to repeat yourself:\r\n\r\nhttps://reacttraining.com/react-router/core/guides/philosophy/nested-routes\r\n\r\n----\r\n\r\nSo it all boils down to really understanding how this stuff works, which ultimately you will want for any serious project. Most people fly blind. There are a million things to do when building an app, and we often don't have the time, so we have to just *trust* a great number of libraries and their public interface. After all, that's the whole point of a good library. So it's just a matter of whether you really want this, whether it really provides that much value, or whether it's just what you're used to. Basically, if you get to the point where u do all this, you'll basically realize it was unnecessary, and your app would have been more professional had you managed it semi-manually in redux-state + selectors. \r\n\r\nSo basically: stop reading this and just use React Router because any bit of time reading this is defeating the purpose and taking value away from React Router. React Router is supposed to be something that requires almost zero thinking. \r\n\r\nHowever, you'll likely lose lots of time in the long run as it becomes hard to reconcile with Redux where most your state lives. \r\n\r\nNow that said, RFR is not very complicated and only takes a little bit more thinking, but with far more benefits. It's *value* is extremely high, especially for *\"real\"* apps. If you know how to use Redux, you know how to take advantage of RFR--you know how to free yourself from the limitations of having to reconcile 2 state stores: React Router and its very basic URL state storage + Redux."}}
{"actor":{"display_login":"faceyspacey"}}