Publication indicates it is ready before all data is published #67
Comments
|
I;m using react on my project too something similar to this https://github.com/micouz/meteor-react-tutorial-next |
|
This may be caused by publishComposite returning the |
|
Yep.. This is an issue.. The ready event comes through before the data is fetched.. Any thoughts on a fix @mquandalle ? Here the propertyHandle.ready() output true even if the subscription is not ready to send the data down.. Because of this I cannot use FastRender, and React SSR too.. |
|
@reywood here we go, https://github.com/sahanDissanayake/hello-react-meteor You could see the difference when you change |
|
Any thoughts on the issue ?? |
|
I tried to fix this issue, but it may require a rather large refactoring of the internal implementation. I would love to read @reywood on the matter. We should take inspiration of |
|
@mquandalle @reywood Should I open a new issue for the |
|
+1 |
|
This fix is badly needed or SSR will be impossible with this package. Is there a way I can help? |
|
@reywood Do you think there is a fix for this ? Like @eXon mentioned can we help somehow to get this fixed ? This is a comment found regarding the issue So yeah, regarding reywood:publish-composite, #67 is an issue for SSR since it currently marks the subscription as ready as soon as the data for the "primary" cursor is sent, and data for the "secondary/joined" cursors get sent after that. I'm not sure whether it's the only issue though : trying to use the latest meteor-react-router-ssr with reywood:publish-composite, I'm seeing no data at all in the server-side subscription, even on the primary cursor |
|
I'm still fairly new to Meteor, but as a temporary workaround, I believe I achieved what this package helps with by manually chaining together two subscriptions in |
|
@TedAvery this is good for simple structures, But when it comes to this https://docs.mongodb.org/manual/core/data-model-design/#normalized-data-models We need the publishComposite to work as it is suppose to |
|
@TedAvery the issue with doing that on the client is that it requires more data roundtrips. That's what this package is supposed to avoid :-) |
|
+1 |
|
++1 |
|
+1 |
|
+1 Even from a non-SSR perspective, it would be nice (and expected) if a |
|
+1 |
|
+1 Any news on this? |
|
+1 |
|
+1 |
reywood
changed the title
ready before all data is published
reywood
changed the title
ready before all data is published
|
I've tried repeatedly to reproduce this problem, but I can't get it to happen. If anyone can create a GitHub repo that reproduces this problem, I would be very grateful. |
|
We have reproduced this problem with a normal Meteor.publish as well; when publishing the relations of one of our Collections we return an array of cursors in a normal Meteor.publish and when subscribing to this publication subscription.ready() will fire before all data from the relations is actually there. |
|
Also, to add: for us this problem only appears when a previously rendered component also subscribes on a subset of one (or more) of the relations. For instance: when displaying a paginated list of a collection we subscribed on the 'listWithRelations' composite publication which provided the first x (20) results of the collection together with all the related fields (but only those items which are actually necessary to render the current list, not the entire collection). Afterwards when we go to the create page we subscribe on the 'relations' publication (normal Meteor publication) which is supposed to load data for all the relations, but (I assume) because we were previously subscribed to only a subset of the same collection we are now subscribing to the subscription returns ready too early (because we were previously subscribed, but to a subset). We can confirm that the create component ONLY and EXACTLY renders exactly those items which were in the 'subset subscription' and that the problem is resolved when the page is refreshed. So it appears that Meteor does not properly destroy composite subscriptions on the client side when a component is unmounted and still believes the subscriptions to be available. I hope this sheds some light for some other people. The solution we have implemented for now is no longer subscribing on the subset of the relations on our list page, but simply subscribing on entire 'relations' publication right away. While not ideal, it is acceptable for our use-case. |
|
+1 |
|
@KoenLav could you create a reproduction or even better a failing test? I tried by following your description but didn't succeed... as I get it this should do the trick with the testing setup provided in this package - but it doesn't as the test succeeds: /* test/server.js */
// subset
publishComposite('limitPosts', {
find() {
return Posts.find({}, { limit: 1 });
},
children: postPublicationChildren
});
// all related
Meteor.publish('allComments', () => {
return Comments.find();
});
/* test/client.js */
it('should throw', onComplete => {
// subscribe to subset
const handle1 = Meteor.subscribe('limitPosts', () => {
expect(Posts.find().count()).to.equal(1);
// handle1.stop(); // not sure if you want to stop the subsciption here, but it doesn't change anything
const handle2 = Meteor.subscribe('allComments', () => {
// everything seems to be ready now
expect(Comments.find().count()).to.equal(5);
onComplete();
});
});
});The above test case should describe your scenario if i'm not mistaken (the handle.stop() would emulate the unmount, but even without stopping it works as expected) |
|
@sakulstra we found out that the issues was caused by us modifying the selector used in the publish functions rather than obtaining a copy of the object and modifying that. Because of this the relations of an Entity were filtered by the id's of the Entity on the previous page. In short: our issue was not caused by publishComposite. |
|
+1 |
|
Has this issue been resolved? I'm having the same problem. |
|
I have this code : publishComposite('users', async function getUsers(realm, token) {
const [_, company] = await decodeToken(realm, token);
return {
find() {
return UsersCollection.find({
company: company._id,
deletedAt: null,
}, {
fields: { keycloakUserId: 0, company: 0 },
});
},
children: [
{
collectionName: 'usersAttributes',
find(user) {
return UsersAttributesCollection.find({
company: company._id,
deletedAt: null,
user: user._id,
}, {
fields: { company: 0, createdBy: 0, createdAt: 0 },
})
},
children: [
{
collectionName: 'attributes',
find(userAttribute, _) {
return AttributesCollection.find({
company: company._id,
deletedAt: null,
_id: userAttribute.attribute,
}, {
fields: { company: 0, createdBy: 0, createdAt: 0 },
})
},
children: [
{
collectionName: 'attributesChoices',
find(attribute, userAttribute, _1) {
let ids = []
if(attribute.type==="select"){
ids.push(userAttribute.value)
}else if(attribute.type==="multiselect"){
ids.push(...userAttribute.value)
}
return AttributesChoicesCollection.find({
_id: { $in: ids },
company: company._id,
deletedAt: null,
attribute: attribute._id,
}, {
fields: { company: 0, createdBy: 0, createdAt: 0 },
})
}
}
]
}
]
},
]
}
});Enabling logging here shows the following traces : A clear race condition that i narrowed down to this instantiation and how its promises are not awaited here I created a PR, here. @StorytellerCZ @reywood , what do you think ? |
and others
Hi @reywood ,
Is there a way to debug why I'm not getting the joined data from the server ?
This is just returning the results
As this one
The text was updated successfully, but these errors were encountered: