Use Simple Schema + Collection 2 properly about todos

[stubailo]

I'm not a fan of autovalue after working with it for a while - personally I would prefer using SS only for schema validation?

[tmeasday]

I'm inclined to agree TBH.

I think the way to do something like an autovalue more explicitly is to subclass the (say) update function and do it there. So you'd do

class ListsCollection extends Collection2 {
  update(query, mod) {
    mod.$set.updatedAt = new Date();
    super(query, mod);
  }
}

What do you think @stubailo? Also, are you ok with default values?

[stubailo]

Hmm... perhaps for something like that, yes. For default values I'd prefer to just have them in the insert method.

[tmeasday]

Oh, sorry that was two questions.

So question 1. was do you think the "subclassing" approach to replace autovalue is correct (the alternative is to put that logic in every method body which is gross).

Question two is around default values -- so I guess I mean do we want to put:

A) default values in the schema

B) default values in the insert method, ala the above

I prefer A) for simple stuff like defaultValue: false.

[stubailo]

1. I feel like overriding update will be super duper hard - like, the example you gave is super simple, but how are you going to ensure other things? Update operators are hella complex.
2. Default values in the schema make sense, but the issue is that autoValue isn't a default value - it's actually run on all updates as well. I wish there were something like autoValue but that only ran on insert.

[tmeasday]

Re update operators --

I'm not saying you allow arbitrary updates. Everything still goes through a method that you tightly control. It's just that it makes sense to do completely common stuff (like updatedAt as a canonical example) in one place.

[stubailo]

Let's look at an example - say you want to make sure that a certain field is always denormalized - for example, you want to make sure that fullName = firstName + lastName. How would you do that by overriding update?

[tmeasday]

I think it's tricky. In that case, if there was a single method that updated firstName or lastName, perhaps you'd do it in the method body?

Alternatively, if you knew that you were only going to $set in update() (and you enforced that), then you could do it there.

I can see that there's an issue about deciding where to put it.

[tmeasday]

Ok, based on our denormalizer discussion, we will make any "hooks" that are based on the shape of the modifier happen at the method level. Perhaps someone will write an awesome package that fully understands mongo operators and we can move it back to the mutator[1]

Another possibility that's more in line with our approach in the past would be to add a mutator to the collection called something like:

setOnSingle(id, attributes) {
  check(id, String); // i.e. enforce a single document
  this.update(id, {$set: attributes});

  // now I can do denormalizations with a lot more confidence
}

When you know that
a) it's only one doc
b) it's always a $set

You can actually do it without needing to be too clever (at least if you don't support dotted operators).

[1] Maybe minimongo is this package somehow (using LocalCollection._modify). But I think it's tricky in general with esoteric operators like $addToSet, and updates that may affect more than one document.

[tmeasday]

See #42

[tmeasday]

I think the final two points can be left for now and just remain on the guide code issues list