Why Subscribe to something that is not in the database

help
#1

I subscribed and published as follows.
But one of the database documents is repeated in the subscription, while it has no _id and is not in the database !

this is publish :

import { Meteor } from "meteor/meteor";
import {Article}  from "../../Collections/Article/Article";
Meteor.publish('Pages.Articles', function() {
    return Article.find({});
});

this is Subscribe :


// Subscribe Data
 const ArticlesContainer = withTracker(() => {
        const handle = Meteor.subscribe('Pages.Articles');
        const loading = handle.ready();
        if(loading){
            const data =  ArticleCollection.find({}, { sort: { createdAt: -1 } }).fetch() ;
            return {
                data ,
                loading
            };
        }
        
})(Articles);

// For Redux
const MapStateToProps = state => {
    return {
        HasUser : state.HasUser
    }
}

// Connect To Reducer
export default connect(MapStateToProps)(ArticlesContainer);

And i handle the Data as Follow :


 { this.props.data
        ?  
        this.props.data.map((article , index) => <Article key={index} title={article.title} img={article.img} />
          : 
            ''          
 }
Strange behaviour on ReactMeteor ToDo List
#2

For example, I have 1 articles in the database, but it Subscribe 2 records, one of which is a duplicate of the other, except that it does not have an _id
like this :

image

#3

I filtered documents that did not have IDs and stopped rendering them, but I do not really know why something that is not in the database is shared?

Everything Welcome

#4

This will not work. You assigned the result of .ready() to loading which inverts the logic.

Fix that, and then get rid of the if conditional, you don’t need it.

3 Likes
#5

@captainn
How exactly do you think it should be implemented?

#6

I modified the code, but like before, it Subscribe what is not in the database

image

image

#7

Do you have any kind of offline support running there? What does your Collections/Article/Article.js file look like?

That second document looks like a copy of the first, with the _id prop stripped off. I’m not sure what’s going on there.

2 Likes
#8

First, it is true that only one of the documents in the database is duplicated.
Except it does not have _id

Second, because it does not have a duplicate _id document, I prevented it from rendering.

And my Article.js file looks like this :

image

#9

@captainn
In fact, I made the _id and slug fields mandatory to render the article .

#10

And this is Article Collection File :

image

#11

Those allow functions should all be returning false, not true,or replace allow with deny. The way it is now, anyone can can update, insert or delete any document in your collection.

This is a weird problem, I don’t know where that phantom document is coming from.

1 Like
#12

@captainn Is my publish correct?

image

#13

@filipenevola This problem exists precisely for user publishing as well .

image
image791×101 11 KB

As you can see, the second document is exactly the copy of the first document, except it has no id

In this publish , I did not interfere and this user publish is Logged in

#14

Everything looks correct here - have you removed autopublish and insecure packages?

1 Like
#15

this is my Packages :

image

I think both packages are comments

#16

I wonder if it could be staringatlights:fast-render doing it - try disabling that (and ssr) and see what happens.

1 Like
#17

@captainn
Exactly when I do these two things, the system works properly and only the documents in the database are Subscribe.

#18

But I need ssr, I also need server side subscription.

@abecks Is this bug from the staringatlights:fast-render package?

#19

If the problem disappears when you remove that plugin, it’s probably a bug in there, or a configuration problem with that package. I’d check with them about it.

1 Like
#20

@captainn
Thanks for following up, please finally announce the result