I described the problem in the repository below and gave a small example.
I hope my friends help me solve the problem and take a look at this repository :
https://github.com/Saeeed-B/Corrupted-data-in-SSR-and-fast-rendering
I described the problem in the repository below and gave a small example.
I hope my friends help me solve the problem and take a look at this repository :
https://github.com/Saeeed-B/Corrupted-data-in-SSR-and-fast-rendering
Hello to the meteor community, I had a lot of difficulties in building my software with meteor and I overcame the problems.
But this problem that I am facing now, I have not found an answer to it for a long time, on the other hand, our software is close to release. And thatās the only software problem that needs to be solved.
To illustrate the problem in a small example, I created a repository in github so that you can check my problem.
And it does not take more than half an hour, thank you for helping us.
https://github.com/Saeeed-B/Corrupted-data-in-SSR-and-fast-rendering
All I try to do is not let this problem cause me to drop the meteor.
I need your help in this difficult situation
I think your problem is related to this. My suggestion is to try switching to mdg:validated-method
and see if that cleans up your issue.
@captainn and other frinds ā¦
The Fast Render package has been revived and I hope you can trust it.
I have raised this issue again and it is being seriously pursued.
I hope friends also help solve this problem.
This should be considered resolvedā¦
After spending approximately 6 hours on this, it boils down to this. When either
FastRender.onPageLoad
orFastRender.onDataReady
run, they callFastRender.wait
to tell FastRender not to run its default data loading behavoir. This default behavior runs within aMeteor.startup
so thatonPageLoad or
onDataReadyget to run first and can call wait beforehand. If you run your UI code also from within a
Meteor.startupthen
onPageLoador
onDataReady` will be called after the default loading behavior and will cause the data be loaded twice which causes the strange artifacts that you are experiencingā¦In your reproduction repo youāre client UI code path starts here, and as you can see you are importing from within
Meteor.startup
. Importing from the top level of the file will fix your issue here.
Just to keep anyone updated that cares about or is affected by this issue. This was an execution order issue that happened when FastRender.onPageLoad
was called within a Meteor.startup
block. As of V4, via 3a78e3254, this will no longer be a problem and fast-render will work from within Meteor.startup
as well.
@copleykj
I do not think the problem is solved.
I removed Meteor.Startup from client and server.
But the issue remains as follows:
No problem as long as the server renders and no extra data is shared.
But as soon as the client is rendered, additional data comes in the subscription.
Of course, it is very strange, sometimes this shape appears and sometimes the removal of m.
@copleykj @captainn
Of course, I also use the npdev: react-loadable package, I do not know if it has a direct effect.
@copleykj
My Server Code :
//-------------------- SSR -----------------------\\
import React from "react";
import { StaticRouter as Router } from "react-router-dom"
// import { onPageLoad } from "meteor/server-render";
import { FastRender } from 'meteor/communitypackages:fast-render'
import { renderToString } from "react-dom/server"
import { HelmetProvider } from 'react-helmet-async'
import { LoadableCaptureProvider, preloadAllLoadables } from 'meteor/npdev:react-loadable'
import Routes from "../../Routes/Routes";
preloadAllLoadables().then(() => FastRender.onPageLoad(sink => {
const context = {};
const loadableHandle = {};
const helmetContext = {};
const html = renderToString(
<LoadableCaptureProvider handle={loadableHandle}>
<HelmetProvider context={helmetContext}>
<Router location={sink.request.url} context={context}>
<Routes />
</Router>
</HelmetProvider>
</LoadableCaptureProvider>
);
const { helmet } = helmetContext;
sink.appendToHead(helmet.meta.toString());
sink.appendToHead(helmet.link.toString());
sink.appendToHead(helmet.title.toString());
sink.renderIntoElementById('App', html)
}))
//------------------- End SSR ---------------------\\
My Client Code :
async function main () {
const [
React,
ReactDOM ,
{ BrowserRouter },
{ HelmetProvider },
{ preloadLoadables },
{ default: Routes},
{ default: ScrollToTop},
{ FastRender }
] = await Promise.all([
import('react'),
import('react-dom'),
import('react-router-dom'),
import('react-helmet-async'),
import('meteor/npdev:react-loadable'),
import('../../Routes/Routes'),
import('./ScrollToTop'),
import('meteor/communitypackages:fast-render')
]);
const renderMethod = module.hot ? ReactDOM.render : ReactDOM.hydrate;
const helmetContext = {}
// const { default: Routes} = await import('../../Routes/Routes')
FastRender.onPageLoad(async sink => {
const promisables = preloadLoadables()
await promisables
ReactDOM.hydrate(
<HelmetProvider context={helmetContext}>
<BrowserRouter>
<ScrollToTop />
<Routes/>
</BrowserRouter>
</HelmetProvider>
, document.getElementById('App'));
})
}
main();
withOut Any Meteor.StartUp
If you go to the following address and check the minimongo with the Meteor extension
, you will notice that there is a data that does not have id_, this is the extra data.
And this program is without Meteor.StartUp.
@saeeed I canāt think of another possible reason why this could happen. Improper order of execution is the only valid reason that Iāve found that could be the cause of this particular issue. This was the cause of the problem in the reproduction repository that you provided and moving the code outside the startup block fixed the issue. At this point unless you can provide new code that reproduces the issue, Iām not not exactly sure how I can start to triage any further issues.
For now Iāve published version 4.0.0-beta.0
which contains a fix that negates the need for execution order. Letās give that a shot first and see if that fixes the issue. First remove staringatlights:fast-render
and replace any imports if you are still using that package. Then run meteor add communitypackages:fast-render@4.0.0-beta.0
If that doesnāt fix your issue then Iām at a loss, unless you can reproduce the issue some other way, or you open access for me to the codebase that you are experiencing the issue with.
You are missing some output in your server code:
sink.renderIntoElementById('App', loadableHandle.toScriptTag() + html)
Try adding that.
Try not dynamically importing 'meteor/communitypackages:fast-render'
. Try doing it at the top level. Fast render is a bit of a hack, so when you dynamically import it, it might be patching things too late in the process.
In a quick read, it looks correct.
@copleykj The problem was solved by updating the package.
But there are warnings and logs on the console and on the server.
We are looking forward to the release of version 4.
Can you post the warnings and logs you are seeing?
Thanks. What is the rest of error caught on publication
part?
@copleykj The errors in the console are not related to my code. Because the publish_context.js file is not mine at all.
I thought it was related to fast rendering.