[Resolved] Why Subscribe to something that is not in the database

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.

2 Likes

@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.

1 Like

This should be considered resolvedā€¦

After spending approximately 6 hours on this, it boils down to this. When either FastRender.onPageLoad or FastRender.onDataReady run, they call FastRender.wait to tell FastRender not to run its default data loading behavoir. This default behavior runs within a Meteor.startup so that onPageLoad or onDataReady get to run first and can call wait beforehand. If you run your UI code also from within a Meteor.startup then onPageLoad or 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.

2 Likes

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.

4 Likes

@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.

https://ghadr.org/

@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.

1 Like

@captainn Are the rest of the code correct?

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.

3 Likes

In a quick read, it looks correct.

1 Like

@saeeed do you get a chance to try the `4.0.0-beta.0ā€™ release?

@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?

Logs in Terminal :

image

logs in console:

1 Like

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.