Closed CaptainN closed 3 years ago
Hello Kevin, sorry for the delayed response. I can see a valid use case and this was already discussed in https://github.com/Meteor-Community-Packages/meteor-collection2/issues/62. I don't see why can't include such a change but we need to have proper tests to avoid breaking any code.
I actually stopped using Simple Schema and Collection2 right after posting this (so I could get more fine grained control - using JSON Schema and some custom supporting functions). I'm not sure I'll be able to swing back to this.
🤣
Feel free to reopen if you'd like to get back to it
The problem:
Collection2 would specifically avoid running autoValues during simulation (I think for a secondary concern about propagating client autoValues to the server?). For certain types of queries, this causes a flash of incorrect data when the simulated run is committed in the local collection before the complete result comes back from the server. This can most obviously be seen in a list sorted on an autoValue
createdAt
field, or similar.This PR changes the behavior to allow autoValues in simulation, while also attempting to prevent propagation of the autoValues (using the same check as before - which isn't precisely isSimulation) to the server, by disallowing (or really, working around) mutation during simulation.
This is a breaking change. AutoValues did not used to run on the Client side for collections with remote connections. It should get at least a minor version bump, but also some documentation. There is also a test failing, which will need to be updated. But I wanted to start the conversation about this feature. It's important in my use case at least.