code injection, integration with reaction-filtration #743
Conversation
|
Right now it adds link "Show Filters" into the bottom of the right side-bar on the product grid page only and allow reactive filtration for product grid output |
There was a problem hiding this comment.
This will need to be removed in v0.12 both contentFor and the placement of this.
|
I don't think you need to do this, the v0.12 layout will allow you to inject these templates using a "layout". We can hold merging and review after v0.12... |
| api.use("ongoworks:[email protected]"); | ||
| api.use("ongoworks:[email protected]"); | ||
| api.use("alanning:[email protected]"); | ||
| api.use("tmeasday:[email protected]"); |
There was a problem hiding this comment.
This package doesn't seem to be very well maintained,(source has deprecated Meteor code) and warns This package is designed primarily for correctness, not performance. That's why it's aimed at counting smaller datasets and keeping the count instantly up to date. Is this the best choice?
There was a problem hiding this comment.
I agree completely, this notice also make me hesitate about using it. I will try to find another way of getting reactive count value.
|
This doesn't work anymore with the latest code on development (yesterday). |
|
@ScyDev I will fix it in short time |
|
Yes, SS is good idea for this case and I agree, that validation and execution should be in separate places. May be there are package similar to ValidatedMethod, but for Publications |
|
implemented validation using SS for productFilters argument in Products publication. Now format is more readable, thanks @newsiberian. Also added translations |
| * @return {Object} return product cursor | ||
| */ | ||
| Meteor.publish("Products", function (productScrollLimit, productFilters) { | ||
| check(productScrollLimit, Match.OneOf(null, undefined, Number)); |
There was a problem hiding this comment.
We could simplify it like this:
const filters = new SimpleSchema({
"shops": {type: [String], optional: true},
"tag": {type: String, optional: true},
"query": {type: String, optional: true},
"visibility": {type: Boolean, optional: true},
"details": {type: Object, optional: true},
"details.key": {type: String},
"details.value": {type: String},
"price": {type: Object, optional: true},
"price.min": {type: Number},
"price.max": {type: Number},
"weight": {type: Object, optional: true},
"weight.min": {type: Number},
"weight.max": {type: Number}
})
Meteor.publish("Products", function (productScrollLimit, productFilters) {
new SimpleSchema({
productScrollLimit: { type: Number, optional: true },
productFilters: { type: filters, optional: true }
}).validator()
...I think it should work not only in validationMethod. see docs. We don't need try/catch. Need tests
There was a problem hiding this comment.
I already tried this and I learned, that we can not completely substitute check() with SS validator, because check package will throw error "not all arguments of publication are checked with check()".
And I like more verbose schema in my case, because it shows full structure of productFilters argument. Don't mistake ValidatedMethod with publication function. You are offering use the same strategy and imho this is right way, but there is no ValidatedPublication package for now, read here
Try/catch we need, because validate() throws ValidationError and inside publication will fails silently without and log message (for me that is strange). We need throw Meteor error again to stop continue publication with wrong format of arguments
There was a problem hiding this comment.
I have a feeling that we can't use audit-arguments-check and SS.validator() within one app. here
There was a problem hiding this comment.
We can in the way I did. audit-arguments-check only need that all publication arguments were checked using check(). After we can validate structure of any argument using SS validate() and throw error if it's wrong
|
We reviewed this PR in the weekly meeting but we were unable to ascertain whether it was ready to merge as it seems there is an ongoing conversation (which we encourage). We leaving this open pending resolving all issues. In addition this still has Code Climate issues that must be resolved and resolve merge conflict. |
code injection, integration with reaction-filtration
|
Hello, this PR was merged unfortunately 😄 , but anyway, I've merged it into PR #741, and modify |
|
@newsiberian yes, we'll need to clean it up.. we'll review it today, patch as needed for and open a new issue for the publication updates. |
|
@ramusus I've reverted this. I think we need to look at this more. |
Resolves #846 Resolves #870 - ReactionProduct.getProductPriceRange().priceRange updated to return range, min, max. - denormalize function updated to add price range, min, max - PriceRange added to product schema - Add filtering to the tags, as originally conceived for #743 — allow for multiple tags in query params The format is: http://localhost:3000/reaction/tag/shop?price.min=100&price.max=200
I don't know should we merge this PR into the core at this stage. May be there is way better to do the same. This is the way how is possible to integrate my package https://github.com/ramusus/reaction-filtration with current development branch of reaction core.
Guys, what do you think, Is there any better way to inject filtration functionality into the core?