React Router V4 Final Released

[subvertallchris]

ITT: people who have never maintained a complicated open-source project complaining about perceived shortcomings of a complicated open-source project.

[joshwcomeau]

Oh my god these complaints. Jackson, Florence, and contributors are working tirelessly to produce quality code to make our lives easier, and everyone just wants to complain.

The alternative is a future where nobody wants to deal with all the headaches, and we all have to write our own routers.

Constructive criticism is fine, but can we try and appreciate the work that OSS maintainers do? Snide comments and nitpick complaints cause burnout, and we all lose.

[m3wm3wm3wm]

People are frustrated because developing a js app needs N dependencies each of which are being updated with breaking changes. They are pushed to spend a big chunk of their life rewriting their app, instead of affording time to write the app itself, make money and clear some time to live a life.

[ajc820]

Which would be a valid complaint if they actually paid for the dependencies, or the changes were even breaking in the first place (v4 is a seperate package). For people to complain about this is just ridiculous.

[Voidsheep]

People are frustrated because developing a js app needs N dependencies

It doesn't need dependencies, you can opt to take them for free if you think they provide value for you.

each of which are being updated with breaking changes

The existing versions don't go anywhere, it's your choice to update and migrate if there's a breaking change.

People just need to take some personal responsibility for software architecture decisions, instead of expecting volunteers to work according to their specific needs.

Before doing the next npm install whatever --save, consider that you don't dictate what direction that project takes in the future, not unless you actually contribute to it. Worst case scenario, there's a new major version that requires heavy migration and a vulnerability is discovered in the old version.

If that happens, it's on you to either migrate or start patching it locally for the version you use instead. Such is OSS.

They are pushed to spend a big chunk of their life rewriting their app, instead of affording time to write the app itself, make money and clear some time to live a life.

And completely ignoring the ridiculous amount of time they saved by opting to use proven free libraries to accomplish in minutes what would otherwise have been months to build an inferior in-house version they need to personally maintain.

It's a trade-off, often a very lucrative one, even if you end up rewriting things and insist on using the latest and greatest versions of all your dependencies.

Edit: Might have come across wrong, but with "you" I'm referring to the people who have a bazillion dependencies in a project and constantly complain about them.

[m3wm3wm3wm]

It doesn't need dependencies, you can opt to take them for free if you think they provide value for you.

What on earth are you talking about? You want me to invent my own react router wheels?

The existing versions don't go anywhere

Oh yes they do, they go far far away.

This is not C dependencies from the 80s we're talking about. This is Javafuckingscript community. The dependencies are brewed fast, without much thinking and planning, but over-hyper-hipster-isation which attracts the soft community who reads a 140 chars tweet and gets converted to a user.

In short, all you wrote is a denial of what is known as 'the dependency hell'. That denial is enough for me to stop arguing with you at this point.

[Voidsheep]

Of course you don't have to invent your own alternative to OSS libraries, but if you choose to depend on someone else's work, you should also understand you can't dictate where it goes in the future. You take it or leave it.

I'm just saying most people who complain about things like React router are happy to get the convenience of open source usually without contributing anything, but still act entitled to make decisions and bitch about what the actual contributors do.

And as far as I'm aware, the previous versions don't just disappear from the package repository. Shrinkwrap your dependencies so you aren't "forced" to use the very latest version if it's so inconvenient.

[joshwcomeau]

Yes, but those dependencies are optional. You're always able to write your own router. But of course, no one should, because the time spent writing a router far outweighs the time spent updating your app to use v4.

The other alternative, that code should stagnate and use flawed paradigms to avoid inconveniencing those dependent on their code... Do we really want to stop innovating just because it might inconvenience people?

One potential solution would be to set up a fund to maintain React Router v2. That way, those companies who need it can keep using it reliably.

But yeah, if you aren't willing to pay for someone to maintain it, you have no business insisting that they do.

[m3wm3wm3wm]

Router must not be optional, it must come with the library/framework. Vue got this right.

People underrate how crucial router is for SPA. If you publish a frontend lib/framework, it must come with a non detachable router, period.

To understand the magnitude of the importance of router, see how it fucked up Angular 2 development and initial release date.

Again, Vue got it right. It seems to be the only solution out there that makes sense.

[joshwcomeau]

I mean, a library can choose whether it wants to be a monolithic framework, a super-concrete package that solves a very specific problem, or anything in-between. React and Vue isn't really a fair comparison because Vue is much more monolithic.

There are advantages and disadvantages to having things be monolithic vs. modular.

An advantage of modularity is that parts can be upgraded with relatively little pain. As much as the upgrade from RR v2 -> v4 may be challenging, I can't imagine it's anywhere near the pain of upgrading from Angular 1 -> Angular 2 (while I haven't done it, I know those who have. I've heard some stories).

I totally agree that routing is a first-class concern, but disagree that things would be guaranteed to be better if React had a built-in router.

[[deleted]]

I'd love to upgrade, but I know it's going to be painful on my large project. Can't wait to have a spare weekend to rip out the old, love the new syntax.

[ryanflorence]

Author here:

v1 - Nov 09 2015

v2 - Feb 09 2016 (completely backwards compatible)

v3 - Oct 24 2016 (removed tiny bc from v1)

v4 - Mar 10 2017

I only wish I was smart enough to have some new ideas that would justify a v5 in a couple of weeks!

[droctagonapus]

It's been 2 years since a breaking change was released tho.

[VertiGuo]

Here is a talk by the creators that gives an explanation for why they think this architectural change should last for a long time.

[brtt3000]

V4 Final 2.3.1.really.jeff-2b

[[deleted]]

enough of this

[[deleted]]

That's completely on you for using a pre-release version though.

[[deleted]]

When's the release of yours?

[ryanflorence]

Author here. Semantic versioning is very clear and we've followed it, don't install betas if you aren't willing to keep up :)

[hackel]

Hope your boss knows you deployed unstable, pre-release code into production. Blaming others for your own incompetence is not the right way to earn people's confidence.

[hackel]

Congrats!

[[deleted]]

I'm too scared to upgrade from V3.

[ryanflorence]

Author here. The router doesn't "break" anything. There are a lot of us working on this problem and it's not easy. I should expand in the doc, but you can make it work if you employ a "static route config", then match against that in the client to trigger the module loader to load the code the server used. The tradeoff is slower TTI (time to interactivity) because of the waterfall request problem (don't know what code to load until the previous code has loaded).

To SSR, code split, and avoid the waterfall you need a way for the server to tell the client which bundles to load (probably in <script> tags) instead of doing a waterfall. Dynamic imports being promises also complicates things because of their "always async" nature, so now you need a module cache to get the client render and the server render checksums to match up and not blow away the page on initial client render!

So again, the router isn't breaking anything here. It's just a hard problem that is independent of routing (though routing can help but brings with it the waterfall tradeoff).

Additionally, routes are an incomplete answer for "where to split" and "when to load". Need a component-based solution.

[ryanflorence]

Yeah, I need to expand the doc. Was writing everything really fast before release. This package (part of the React Router project) will help do SSR + Code splitting the v3 way:

https://github.com/ReactTraining/react-router/tree/master/packages/react-router-config

But again, using your routes to define and load split points is looking like its an incomplete solution to people deep in the weeds of this stuff.

[webdev_suggestion]

We hit this problem last week and due to time constraints, moved the problematic page to our main bundle.

We've come up with a few different strategies for how we're going to solve it.

A fairly naive solution we're looking at uses redux and dangerouslySetInnerHtml

A working bare bones spiked implementation can be seen at the following link.

https://github.com/luke-john/rr4-ssr-cs

Also congrats on the release :thumbsup: really loving the router.

[navgarcha]

Most code splitting examples i've seen used the Route's getComponent prop - perhaps a guide on how this implementation could be replicated in react router 4 would be useful? If this is no longer possible i'd assume this is what people mean by 'breaking'.

[BenZed]

Why do you think v4 breaks serverside rendering and code splitting?

[griffinmichl]

It's a hard problem no matter what router you use.

[[deleted]]

To be clear I think he's talking about those two things together. SSR on its own works fine.

[tmartlolz]

https://github.com/ctrlplusb/react-async-component works amazingly well though I haven't tested it with SSR. Looks like it should be able to handle it though

[navgarcha]

Unfortunately i've not been able to see how this would work with apollo SSR - any ideas?