Fast rendering is officially obsolete And looking, the new owner

packages
21

The fast render package is a bit of a hack I think.

With SSR, the data can be injected and used to hydrate the client, which I think is cleaner than the subscription highjacking that this package does.

1 Like
22

If you render a list with classic meteor pub sub, you subscribe to the data set and iterate over it. If you do this with server sider rendering you get multiple problems:

  • the dataset is different, because the server does not know about the publication, it will just threat any ā€œCollection.find()ā€ as direct db access
  • the result from the server is correct and the list is rendered as you intended, but now on the client, it will start with an empty collection, throw away the server result, start the subscription and wait for the data. This will result in a flicker, where you initially see the right content, but it vanishes and eventually reappears again
  • Maybe this is solved in the core, but i am not sure: Meteor.userId() might be incorrect or empty on server

At least some of these problems are solved (yes hacky) in fast-render. The first can be solved with more discipline, by always defining precise selectors for Meteor.Collectio on the client (this is a common flaw of meteor pub/sub).

@alawi fast render DOES exactly extract the subscription data and hydrate. For this to work, it has to monkey-patch the pub/sub mechanism.

2 Likes
23

React is along way off - and there are solutions available today that we just need to polish.

For SSR in Meteor with React, we currently need:

  • Core: dynamic-imports and server-render
  • code splitting: npdev:react-loadable eventually lazy might be used, but I think there will always need to be integration at some level. I maintain this, but it could probably use a design pass to make it easier to use.
  • data capture/hydration : staringatlights:fast-render(or similar) - This adds Meteor.subscribe and the accounts APIs to the server, and does the capture work, etc.

For fast-render, there may be easier ways to implement the same behavior using a normal React Context Provider, which would b e easier to maintain (while retaining the work to sort of polyfill subscribe and accounts on the server). Iā€™d actually love to do that work, but I have a full time job these daysā€¦ Iā€™d be happy to share some thoughts on how to approach that if someone wants to take up an implementation effort. On the other hand, it might make sense just to try and maintain fast-render - but as part of core (it can be used by more than just react).

I believe both of these components should be in Meteor core.

2 Likes
24

Instead of focusing on subscription, better if we focus on how to properly hydrate data from methods.

The normal use case of SSR is for SEO. And therefore, the pages normally used for this are pages accessible to non-logged-in users. And most of these pages use methods. It is rare that guest pages will require pub-sub and also SEO

3 Likes
25

Yes, that is the use case for me. I hydrate the landing page by injecting the data with the SSR. I didnā€™t have a case where Iā€™ve pub/sub at the landing page.

26

Hydration from methods can be done relatively easily - but it needs the accounts support server side provided by fast-render. That support should at the very least be in core.

2 Likes
27

Yes, I only borrowed the account initiation during SSR.

Iā€™ve that code extracted in a package here https://github.com/aliogaili/ssr-helper.

In addition it has helperer methods to inject/retrieve data during SSR.

1 Like
28

Seems that answer the question on what must be in the core. @alawi has already the required changes which seems perfect as a PR for the server-render package

Then the front-end-library specific handling can use these helper functions

1 Like
29

Maybe these additional packages:

  • server-render-accounts (gliogaili:ssr-helper)
  • server-render-pubsub - contains tools to enable Meteor.subscribe in server-render, and capture/hydrate that data. This can either be done like it is in fast-render by adding a step in front of server-render's onPageLoad, or it could expose tools to do it properly in your chosen front end stack.

Iā€™m honestly not sure how staringatlights:fast-render even integrates with routing. It seems to work, but how?

Or just copy all of staringatlights:fast-render to a core fast-render packageā€¦

3 Likes
30

I do not think leaving pub / sub in ssr is the right thing to do.
Using methods for data is just clearing the face of the issue.
That is why I say that any external package only erases the problem and is difficult to bypass.
The separate problem must be solved inside the kernel

31

Hello everyone again.
We are talking seriously about ssr in metoer.
I invite all those who are concerned about it