I mean this in a nice way, I'd really appreciate a gist showing how you get the core concept of react-router in 50 lines. It's in a project of mine now and maybe it shouldn't be.
const path = findThePath();
class Router extends Component {
render() {
if (path === "/about") return <About />
else if (path.match(someRegex)) {
const data = parseSomePath(path);
return <Page { ...data } />
} else {
return <Default />
}
}
}
Of course, I say just buck-up and learn the damn thing, it isn't that complex... earn the "Engineer" in your job title!
Maybe I'm just an out-of-touch neckbeard these days?
So yeah, it works good when you get it working, so yeah, the best thing to do is to just buck up and learn if it you need it. But boy does it suck getting there.
All of that said, I don't understand where this view comes from that Redux is extremely confusing. It can indeed sprawl a little. Say, if you keep you containers, reducers, and actions in their own directory trees. The overall architecture didn't take me very long to grasp and start to leverage.
Plenty of folks find their home in Flux or MobX instead, but I'd have to guess that a lot of the confusion is actually confusion about state containers and their uses.
If the router was just "Buck up, learn it, and you're golden" I suspect we wouldn't hear too much hollering about it. Unfortunately, the hassle of using it is so close to clockwork I feel like I should just schedule a week every six months or so for maintenance.
I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I wouldn't mind that much except that wrapping a React component around a fragment of HTML is not a problem so difficult that I'd endure compat problems in a dep to solve it.
With the router, it was never a matter of us just deciding to upgrade for the sake of upgrading but rather ending up being painted in a corner with peer dependencies requiring upgrade. Additionally, because we were a micro service / many SPA outfit, we ended up with a dozen or more applications at varying levels of libraries so you had to deal with 2.x, 3.x, and 4.x or just upgrade.
For those of you reading along thinking "This sounds like a dysfunctional environment!" You're right! Imagine having five heads of department, albeit two interim, in a year.
> I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems.
I'm in the middle of building out an internal component library based on `react-bootstrap`, so that's fun to hear...
Have your issues mostly been upgrades of the library? Or of Bootstrap versions? We internally decided we're just sticking with Bootstrap 3 for the foreseeable future with the hope that it will mean we don't have many issues to deal with.
It's possible react-router has settled down too, but the experience I had of "I can't believe I ever wasted time trying to figure out react-router" after implementing a "router" myself was so powerful that I'm pretty averse to finding out.
That layout is the biggest reason it took me so long to understand it when my team brought it in.
It goes a bit against the spirit of Redux, but the tutorials really should pair up action and reducer in the same directory, then later explain why the other way is also useful.
We currently do this:
state/
|---some_piece_of_state/
| |------reducer.js
| |------actions.js
| |------tests.js
|
|---another_piece_of_state/
|------reducer.js
|------actions.js
|------tests.js
For the size of the tutorials, it's probably simpler to use a "folder-by-type" structure. But yes, for real apps, I myself have settled on a "folder-by-feature" structure. Note that either approach is completely orthogonal to whether you have multiple reducers listening to the same action.
The tutorial is already trying to explain a lot of concepts that are new to most people, so we try to keep it focused on the meaningful concepts. Throwing in side discussions on folder structures would probably add more confusion at that point in the learning curve.
> so we try to keep it focused on the meaningful concepts.
For me, scattering a single feature across multiple directories makes it far harder to understand what relates to what. It's _less_ meaningful to group by type than by feature, which makes it harder to learn than it should be.
I'm not saying the docs should go into asides about the alternative structures all over, but rather the people promoting Redux should definitely consider whether or not their examples smell more of spaghetti code than they need to be.
If you take the recommended path, i.e add redux iff you need it, you've already settled away from folder-by-type. It's natural to organise by feature since you're generally doing it anyway by that point.
Instead of a rework, it might be easier to add a small page on folder structure.
Noticed you on Reactiflux too, hi!
You want the things in your app that look like links to have some interesting behaviour. They should look like links, they should act like links when right-clicked.... but when left-clicked, they should not actually load the new page. Instead, they should update the History and also trigger the router to reconsider the routing. That's why ReactRouter includes Links and Redirects.
I suspect there's at least one other feature-of-some-utility in it that I can't think of right now. Hmn.
There's also some weird logic around multi-routing, which I suspect is a bug rather than a feature, but maybe there's a sweet use-case. And there's also some weird stuff about not propagating children, which seems like a bug not a feature, but the workaround is easy, and again maybe there's actually a good reason, I dunno.
Anyway, as with what you talked about, this isn't rocket science, you could do it yourself with some work. But if someone follows your advice and thinks that's the end of it, they'll eventually feel some minor pain points.
That said, I honestly can't be bothered to actually properly learn React Router. I think that some company, ideally one specializing in react training, should write better documentation for it.
You also have a few (single-digit) lines of code to wire up the history API so that the back button works.
You have a tiny helper function that uses the history API to directly navigate to a URL inside your application.
You have a tiny Component that renders an <a>...</a> whose onClick calls that helper function.
I'm sure React Router does a lot more than this. I mean, it'd have to, right? It's so complicated. But I don't know what those things are, because until I'm forced to, I'm not going to bother with it.
Similarly: I appreciate flux and think Redux is a reasonable implementation of it, but at this point, after doing a couple applications with it, I'm going to get as far as I can with a simple EventEmitter and hierarchical state before I bring it into a project. For straightforward applications --- really, a pretty big chunk of the apps I see are fundamentally straightforward --- I don't think it's a win.
When React was originally released it was sold only as a view layer that you plug into your application stack. Since no official way of approaching the rest of the stack emerged from Facebook, when Flux was announced it seems that it was taken as the rest of the stack by many.
He teaches a good chunk of the react nanodegree course on Udacity and has a lot of good blogs on react.
I'd also just look at the React Router codebase. The components are pretty well written and somewhat easy to understand: https://github.com/ReactTraining/react-router/blob/master/pa...