Status of this project about after.js

[nimaa77]

we can go web server agnostic and use any web server that we want to bootstrap the server (yes this means support for edge runtimes)
having examples that show how to run Vite with after.js can be good as well
and typescript types are a mess, those can get improved as well

[MatthewPattell]

@nimaa77 hi,

In my mind I see it like this:

• Building the project - move away from tsdx to something like rollup, etc. (low priority, but it can be easy)
• Support for the latest version of react-router and react (medium priority, it can be taken from our fork)
• The most important part for us is the render to stream (high priority)
• Update dependencies (medium priority)
• Fix typescript errors (medium priority, it can be taken from our fork)

Ready to discuss any possibilities and offer any assistance. Therefore, the team and I would very much like the implementation of render to stream.

[MatthewPattell]

I do not think that someone will continue to maintain this repository. Although the project is cool in my opinion.
I don't want it to disappear, so I try to update on our fork:
https://github.com/Lomray-Software/after.js
https://www.npmjs.com/package/@lomray/after

react-router v6 + react18.

You need to find the strength in yourself to go to streams 😄

[nimaa77]

hello everyone

what features do you guys need? I mean what should be the next features we add to the library except for upgrading the deps to latest versions (react and react-router and ...)

remix framework solves a lot of issues and has a lot of good apis that are available in react router as well, this means we can integrate them into after js. but if we just copy whatever they have, we will endup with remix again. it's like inventing the wheel from scratch

the question is what should be the goal of this project in 2023? what should be features that makes this librray different and better from other solutions around?

the only problem that I have right now is, I don't know which way should this library go. give me ideas, roadmaps, a goal

[Yamaha32088]

For us just updating the dependencies would be great. We don't necessarily need a lot of features, just bug fixes and keeping up with dependency updates.

[nimaa77]

I'm on it 😉

[nimaa77]

so if we use React 18 it has support for React lazy and code splitting on the server with suspense

react-router (remix router) 6.4 has data routers that are SSR ready This means we can drop support for getInitialProps

the transitionBehavior prop can be removed as well, it was a workaround to control wheater you want to render the next page component while the next page data is loading or if you just want to fetch data at first and then show the next page. react-router 6.4 Awaited and Defer APIs will do this (with more control)

scrollToTop will be dropped as well (since we are going to remove getInitialProps), react-router Scroll Restoration will handle that (with way way more control 😍 - this is the best feature)

so to summerize it would be:

6 breaking changes in one release

1. Drop Support for React 16 - Upgrade to 18
2. Drop Support for React Router 5 - Upgrade to 6.4
3. Drop Support for asyncComponent - Alternative: React Lazy, Suspense, React Router Lazy
4. Drop Support for getInitialProps - Alternative: React Router Data Apis and Data Router And Loader
5. Drop Support for transitionBehavior - Alternative Awaited and Defer
6. 404, After.js will not come with a default 404 anymore

let me know your thoughts

[nimaa77]

if you think it's a big change, maybe (it might not be possible but I will give it a try)

we can keep all the current APIs and only upgrade react and react-router dependencies, so the list of the breaking changes will become:

1. Drop Support for React 16 - Upgrade to 18
2. Drop Support for React Router 5 - Upgrade to 6.4

then I add new APIs (new functions and components available to import) that include all those nice features that come from react-router 6 (nested layouts, scroll restoration, defer API, loader, and ...)

---

if it was too much complicated to implement we can break the release into two smaller breaking ones

in the first release, we just upgrade the dependencies
in the second release, we introduce the new APIs and remove the old ones
the best case scenario is to have both of them at the same time to allow the users gradually migrate to new APIs (but this is almost impossible to do)

[MatthewPattell]

After giving it a lot of thought, I have come to the conclusion that perhaps we don't need a remix after all. If we want to use it, we can simply go ahead and install it. Additionally, both the remix and the vite integration already exist.

I really like this project because it doesn't impose many rules and is not significantly different from a regular React SPA application. I have studied many solutions for SSR, and all of them immerse us in a sea of rules, thus limiting our freedom of action.

We have tweaked this solution a bit so that switching between spa and ssr happens without modifications. With our current implementation, it became possible to transfer the project, launch, build without pain, fear and anesthesia from SPA to SSR and back.😄

InitialProps - like useEffect for SPA and fetching data for SSR. It works the same in all modes.

Therefore, I believe integrating the latest versions of React and React-DOM with streaming support would be fantastic. Additionally, we could consider using the vite instead of the Razzle but I'm not sure.

I think to breathe new life with the plan above

[batusai513]

@MatthewPattell @nimaa77 do you need help with this, I'm actively using this package and would like to get this updates, please let me know so we can move this forward

[MatthewPattell]

Right now, I'm torn between two options. On one hand, I want to follow this plan, but it would require project migrations, which can be more time-consuming. On the other hand, I could implement this plan, which would make the migration of existing projects easier.

Currently, I'm in the process of studying these two plans :) As they say, "the road always appears under the feet of those who walk".

PS: I would also be interested to know if there is any progress from @nimaa77 .

[MatthewPattell]

Definitely came to the conclusion that it must be vite. The only thing that slows me down is that I can't get renderToPipeableStream to work correctly with createStaticRouter. I really don't want file navigation.

There are no problems with renderToString.

[nimaa77]

@MatthewPattell I had some progress regarding the meta tags and head API

the biggest challenge that I have right now is that I don't know how to map the dynamic modules to the routes so we can send the <script src="path/to/dynamic/route" /> in the initial HTML that we send to the users

Does any one have any ideas about this?

[MatthewPattell]

Hi, sorry guys but I got so immersed in solving problems that I came up with my own framework😂. With your permission, I will leave the link here for study.

[golaod]

Is there a chance to finish up this project to work with router 6 and react 18?
This vite template you gave is awesome but of course it does too much in a same way nextjs does. I don't like having mobx and store managers and all of that. Simple solution like getInitialData was just fine

[MatthewPattell]

@golaod The point is, you don't necessarily have to use everything shown there. Just remove MobX, store managers, and anything else you don't need. Then refer to the React Router API v6.

In short: gitInitilProps is replaced with a loader function.
Here what do you looking for.