{"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":"[ Nesting Routes ] Some Possible Solutions","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":12,"created_at":"2017-09-28T15:05:33Z","updated_at":"2018-04-01T06:06:14Z","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/377765304","html_url":"https://github.com/faceyspacey/redux-first-router/issues/126#issuecomment-377765304","issue_url":"https://api.github.com/repos/faceyspacey/redux-first-router/issues/126","id":377765304,"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":"2018-04-01T06:06:14Z","updated_at":"2018-04-01T06:06:14Z","author_association":"OWNER","body":"That's the react router way. React Router is easy at the easy stuff, but challenging at the real stuff. So the tradeoff is to go a little bit lower level and be really in charge of your *'state'* (i.e. redux state), and have a very manageable situation when it comes to the truly complex task of async data fetching.\r\n\r\nAt the end of the day async is the only really complex things in modern React apps these days. So we're focused on solving those problems, not the simple problem of conditional logic to pick and choose which component to show.\r\n\r\nAlso as far as *what a \"route\" is*, React Router invented and popularized the notion of *routing components*. Before that we used to deal with things in a static map and from here figure out what to render. I.e. in the server-side MVC days, but also in client-routing until React Router came around. ...So perhaps if all you've ever used is React Router, that might be the case. But here we're essentially going back to the \"old wisdom\" of a \"controller layer\" that handles the data-fetching, rather than letting it live in the view layer, which can become problematic for a great number of reasons. That's what this router is all about. \r\n\r\nBottom line: build a big redux + react router + possibly apollo app, and feel the pain of 4 different state stores (you also have local state), then appreciation for having it all under one roof can be gained. Otherwise it's hard to compare the pain of the real problems to the pain of a little work conditionally choosing to what to render from your *own* state.\r\n\r\nIn the future we'll likely have routing components to help people get started with, as we do realize React Router is so popular that it will help to transfer current understandings (as well as current apps).\r\n\r\nAnother thing to note: the entire React + Node approach is based on writing more/explicit code to avoid leaky abstractions behind the scenes (yours or 3rd party) breaking our apps without providing much information about what happened. I.e. this is \"configuration over convention,\" whereas the Rails approach was \"convention over configuration.\" So the extra work here in RFR isn't misaligned with general javascript patterns. \r\n\r\n...Now that all said, here's a non-nested route component:\r\n\r\n```js\r\nconst Route = ({ type }) => components[type]\r\n\r\nconst components = {\r\n   HOME: Home,\r\n   ABOUT: About\r\n}\r\n```\r\n\r\nObviously you could do it based on params, or types + params. Or any combination of conditional logic. Guess what, that's several hundred lines behind the scenes that React Router is doing to provide you an abstraction you now gotta *trust* where here **you know exactly what you're doing, and no leaks, or misunderstood things, or new package versions conflicts, or perf issues from so much extra code, etc, can get in your way**. The most valuable thing--and again this is part of the JS \"configuration\" approach--is simply knowing exactly what the code is doing. \"Explicitness.\" \r\n\r\nAs we age as programmers, we come to appreciate this more. A lot of the people that find problems with the redux boilerplates are obviously younger programmers exercising there \"abstraction\" muscles, which is a good thing. But clearly they haven't been burned by the pain of their apps collapsing under the weight of leaky abstractions *yet*. Basically when you're a *learner*, just mastering syntax and all the different language features etc is the goal. So less code is important, as it takes a lot of time to mentally *parse* all that code. That's why they/we all seek to reduce the amount of code at that stage. Code reduction is always important, but it goes down in priority as you progress. Later the goals become different and essentially more complex (with all sorts of layers to it). And what happens is the things you did to keep things DRY actually got in the way of how modular code can be. So more code allows for different layers to the cake you can shift around, whereas if it's all in one grand DRY abstraction, u can't shift it around much, and u begin to make it do so many things that u can't easily reason about that code anymore.\r\n\r\nThe approach here requires you to make your own little routing-oriented components, but they are simple, non-abstract, and very straightforward. They come in handy when you want to do *that one custom thing* the given library (in this case React Router) can't do--cuz ur not relying on a large abstraction anymore, u can insert the small customization you need right where you need it. Enjoy.\r\n\r\nps. if you're still mastering the react ecosystem, React Router may be the thing to continue with, but if you're getting heavily into redux and really wanna master state-driven principles, RFR is the way to go. No juggling in the view layer, just use react-redux's `connect` to get the state you need.\r\n\r\n"}}
{"actor":{"display_login":"faceyspacey"}}