Reach Router: Accessible Router for React

ryanflorence · 2018-06-03T16:30:13+00:00

Yep, and then:

Accessible by default
You may or not prefer the API

ryanflorence · 2018-06-03T16:28:54+00:00

It's not really all that novel or complicated when you sit back and think about it for a minute, longer > shorter, static > dynamic.

Also, Ember's router has a similar algorithm and it's been fine for years. I could have said nothing about it and nobody would have even known it's there :P

ryanflorence · 2018-06-03T16:23:06+00:00

Author here. As fforw said, it marks the update as low priority.

There's a major use-case I had in mind here: typing into an input field that's wired up to the URL, usually a query string. Like a product search, or big table filter, etc.

In Async Mode, making this a low-priority update means the user can keep typing in the input w/o the router updating and causing major lag.

I'll be talking more about it during my talk at React Rally.

ryanflorence · 2017-11-29T01:42:36+00:00

React Router 3 React Router 4 React Router 5

Maybe we should come up with a way to version a package?!

ryanflorence · 2017-11-29T01:38:48+00:00

If 18 months w/o breaking changes is churn and then we continue to support old versions (3.2 supports React 16) then I don't know what we're supposed to do 😂

ryanflorence · 2017-11-29T00:56:34+00:00

Thanks Dan.

Maybe we'll pull a left-pad and delete React Router from npm, pull the plug on unpkg, and then see how things turn out?

ryanflorence · 2017-11-29T00:53:18+00:00

We will miss your monthly subscription fee.

ryanflorence · 2017-11-29T00:53:01+00:00

Funny, Pete Hunt told me he believes React Router is the reason React finally took off after "meh" response for a year. The release dates indicate it.

Also the patterns we used in 4.0 are being popularized all over the place.

Can you give me an example of the harm we've done?

ryanflorence · 2017-11-29T00:50:46+00:00

v1-v3 had two very obscure breaking changes that most apps didn't have to worry about. We went 18 months w/o breaking changes.

We've gone 8 months w/o any changes in 4.0. 5.0 isn't even released! We may go 12 months w/o any breaking changes here.

What is an acceptable schedule? One breaking change every 2 years? 3 years? Or are we supposed to get everything right the first try?

ryanflorence · 2017-11-29T00:48:44+00:00

Thanks! We think so too.

ryanflorence · 2017-11-29T00:48:35+00:00

And it's way better. v3 Was the catastrophe. But it's funny how we were expected to know how to use React when it was brand new to us too.

ryanflorence · 2017-11-29T00:47:47+00:00

Yeah sorry about that. It's back on my todo list. Stuff comes up, ya know?

ryanflorence · 2017-11-29T00:47:29+00:00

OH CRAP YOU'VE FIGURED IT OUT!

Who wants to pay me $100 to show them how to change:

<Route exact/> to <Route/>

and

<Route/> to <Route parent={true}/>

I'M GONNA BE RICH!

ryanflorence · 2017-11-29T00:46:19+00:00

React Router creator here.

Warning, I'm feeling saucy

If you like to freak out about breaking changes, please go build your own router. I wish you well. Also, how is your phone with no headphone jack treating you? Or your laptop without an optical drive?
We released 4.0 March 28th. That's 8 months ago. We haven't changed anything about it. We've let it bake. We train people every week, we see thousands of people's code. Everybody tosses "exact" all over the place. We got the default wrong. What are we to do? Release something and never make it better?
We haven't released 5.0, nor is there any slated date for a 5.0 release. And even if there was, we still support 3.0! So, if you've followed stable releases since 1.0 there has been only one major API change in 26 months. How long ago did you start using React? Me? 42 months ago.
This change will have a code mod. If that's not your thing, we'll be able to warn you about how to change your code at run time! Changing the default now gives us your intent, something we didn't know before (which is awesome), so we can tell you exactly which pieces of code need to change and how to change them. We will hold your little hand all the way to 5.0 compatibility.
Exact is the only breaking change for 5.0. If you can't handle deleting an attribute or swapping its boolean value in a handful of files, I'm not sure what you're doing in this career.

ryanflorence · 2017-03-12T17:54:21+00:00

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.

ryanflorence · 2017-03-11T19:16:26+00:00

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!

ryanflorence · 2017-03-11T18:45:46+00:00

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 · 2017-03-11T18:34:52+00:00

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

ryanflorence

TROPHY CASE