ryanflorence

Remix co-author here. We haven't "missed on RSC", they aren't even released!

We already have experimental versions of Remix running on React 18 and have experimented with RSC, Suspense, and streaming extensively. In their current state however, we're not seeing them beat Remix's current approach in production results or developer ergonomics. We've been providing the React team with our feedback. When these features from React are ready, Remix will be able to easily support them.

Remix co-author here. Infinite scroll/pagination is a great way to test the limits of a web framework!

Remix doesn't ship an infinite scroll/pagination set of components so it's up to apps to make sure that state is still there when the user clicks back. If the state is still there, Remix's scroll restoration will work.

You could either manage your own global state for this, but I like to use "location state" which is our API into the browser's built in `history.state`.

There are various ways to use it (declaratively, imperatively, etc.), but simplest way to explain is to imagine a "Load more" button that's really just a link like this:

`<Link to="?page=2" state={{ data }} />`

Your Remix loader would load page 2 from the url search param and your component would concat that onto `location.state.data` (the previous entries from the initial location). This renders the old data and the new data together.

Location state, unlike typical "global state", automatically persists across both refreshes and back/forward button clicks, but dies with the session, so scroll restoration will work as expected even for a refresh! Built in browser APIs tend to be a bit more resilient than storing stuff in application memory, they also keep your bundle smaller.

I don't know where the demo is, but I helped somebody at some point implement this without needing to ship a global state container for server-supplied data. Just made a note to make an example and put it our repo :)

If we're talking "load more" a much simpler way to do it is to consider how you'd do it old school with no JS. Just return all pages according to the search param, so "?page=3" would return all three pages. More kB over the network, but far easier to implement. There's even a product reason to do it this way: when you load more you automatically update the comment counts/points of each entry, so maybe it's worth it.

Great question!

Author here.

One more time for those in the back:

v0.x > v1 Breaking changes

v1 > v2 > v3 a couple obscure breaking changes, but practically none

18 months pass

v3 > v4 New, composable design, basically a new project

v3 still maintained, 3.5 years no changes. v4 2 years, no changes.

v4 -> v5 was supposed to be 4.4, but an internal dependency '^' got us, so best choice was version bump to prevent problems.

Jimmy. Jimmy 2020, my man. Did you click the link? Did you notice how every link on the page links to a free video? Did you see the paragraph at the top of the page explaining that these free videos are part of a larger course?

No? Huh.

Sorry about that, meant to say "lectures" not "videos" ... But I mean ... the videos for every pattern is free, so if we're gonna split hairs the title is correct!

Not any time soon, gotta pay the bills somehow! :P

Following stable releases we had one breaking API change in 2 years from 0.13 -> 1.0. 2.0 was fully BC, 3.0 removed 1.0 API 8 months after 2.0 was released. People shouldn't install beta/alpha like its stable and then complain to us about it.

Also, don't upgrade. v3 is going to maintained with bugfixes and whatever needs to happen to be compatible with new React releases indefinitely.

I'm so confused. There are only two actual releases there: v2.0.0 and then 8 months later v3, where all that happened was v1 API was removed. If you only keep up with the stable releases your life has been simple with React Router.

also, not every app wants to do it the same way. Now that we're Just Components™ you can handle scrolling however you'd like.

you get location.search, which is just a string. We removed default query handling because it can be composed in with something like `RouteWithQuery` and `LinkWithQuery`. Lots of people didn't want the default serialization anyway. It's like 7 lines, we'll have an example of it you can copy/paste.

We had breaking changes from 0.13 -> 1.0. We had no breaking changes from 1.0 -> 2.0. That's 2 years with no breaking changes.

Our workshops have $899 early bird tickets.

Every software company I've ever worked for sells training and consulting for their software.

0.13 -> 1.0 was breaking 1.0 -> 2.0 was fully BC

That was 2 years with only one breaking change.

2.0 -> 3.0 removed deprecated 1.0 API, fully BC with 2.0

The only churn is for people who don't stick to stable releases, and that's their own problem.

1) Not sure why navigating is "more complex on native". The platform the code runs on has nothing to do with the way the user interacts with the page. Complex navigation state is represented as one or many stacks of URIs.

2) In React Router you can have a statically available route config. This is React. Make an array then map it to render.

3) React Router is all components, so it composes exactly like the rest of your app. No new API to learn. It's Just React™

backcompat-breaking changes to React-Router

We had breaking changes from 0.13 to 1.0.

Then complete BC from 1.0 to 2.0

That's two years, one breaking upgrade.

Don't confuse a libs "changing API" with "people use the development branch as stable".

Difference is the API. React Router is a 100% declarative components, rather than configs and imperative actions.

only have time for so many things, v1 final release will have a site that works well on mobile too.

browsers are handling that now https://majido.github.io/scroll-restoration-proposal/history...

We're working on an upgrade guide, but in short, it's a completely different library. Major difference is that routes are actual components that are actually rendered, where before they just had their props stripped and plugged into the routing machine. Now your routing is composed like the rest of your react app.

Neither were we >.< but we were learning React along with everybody else! You'll love this version.

I went back to component state.

1. Solve something that hasn't already been solved well

2. Have a ton of examples in the repository

3. Use it in production in your own stuff

4. Keep a solid change log and upgrade guide

5. Ignore the stars, all of this is for your team.

If you read the overview you may understand our opinion that "application state" is precisely which views to render.

https://github.com/rackt/react-router/blob/master/docs/guide...

We're almost done with serializing the application data as well. Both pieces are important.

We've almost tied all the knots we need to meet this requirement of a router.

Every application has UI nesting at the core of its state, though.

Then use them as JavaScript functions, because that's what they are :)

The point of JSX is to express attributes and hierarchy, which matches with our route configs perfectly.

I'm one of the authors of react router.

How do you feel about <script/> tags, or <link/> or <meta/> or <base/>?

yeah, I've talked a lot with james about volo. I really like it. If people authored es6, shipped UMD, volo would also just work.

The point is to let people continue to use the tools of today with the module format of tomorrow :)

Completely agree on all points.

Also, community. My wife was sick in bed for 3 months, our neighbors came and watched our kids every morning from 8:00am-12:00pm so I could work and continue to support my family. You only get that from a neighborhood of homeowners.

That's 22 mins from my house, it's quite new, makes sense it isn't showing yet.

Ember is supposed to be an opinionated, high level framework built on low level apis. Not sure what the point was in this article.