尝试使用流星和蒙哥过滤基于“类别”的“行情”

Question

So I'm having a bit of trouble. I have a list of quotes, and each quote has category.

I wasn't sure the best solution of how to architect this, so I decided to make 2 collections. One for "Quotes" and one for "Categories".

Each "Quote" has a "Category" which is the _ID of the categories I inserted into the database.

I'm trying to "Filter" the list of quotes based on the "Category" I click on in my webapp.

I'm having trouble figuring out how to to this.

So far I've created a session which stores my "Clicked Category Id" but from there I don't know how to filter my "Quotes" database to show "ONLY QUOTES WITH CATEGORY ID = SESSION CAT_ID"

Any help is much appreciated.

Answer 1

You should really indicate what your current code looks like so we have a reference to start from. However this is a fairly simple task so I've gone ahead and provided a mock example:

Template:

{{#each quoteCategories}}
    <button class="quote-category" value="{{_id}}">{{title}}</button>
{{/each}}

<ul>
{{#each quotes}}
    <li>"{{content}}" &mdash; {{author}}</li>
{{/each}}
</ul>

Template events :

Template.quotesList.events({
    'click button.quote-category': function(event) {
        var categoryId = $(event.target).val();
        Session.set('quote-category-id', categoryId);
    }
});

Template helpers :

Template.quotesList.helpers({
    'quoteCategories': function() {
        return QuoteCategories.find({});
    },
    'quotes': function() {
        var categoryId = Session.get('quote-category-id');
        if(categoryId) {            
            return Quotes.find({category: categoryId});
        } else {
            return Quotes.find({});
        }
    }
});

Your Collection architecture is fine. One of the best things about a noSQL database like MongoDB is that you can really choose to normalise or denormalise depending on your needs. So for your structure if it's easier to work with as two Collections then that's fine. Generally speaking the best way to determine DB structure is to optimise for heaviest use, so make it simpler to be read for read-heavy applications (the majority) or easy to write (insert, update) for write-heavy applications. The structure can vary depending on these needs.