Timestamps trigger template renders with {} instead of actual timestamp about meteor HOT 3 CLOSED

CoffeeScript :(

You realize that developers would prefer to read and debug JavaScript right?

from meteor.

No, sorry, I didn't.

Additionally, although I did think about people who wanted to read JS, I forgot that the deployed thing had the minified (and hence useless) JS.

Would you like me to push the code somewhere so you can run it in development where you could see the changes live?

I have since changed the code to work around this using a helper function, but the basic idea should still be pretty obvious. Basically humaneDate raises TypeError because of a missing method, because it expects either a string representation of a date or a Date object, not {}. humanTime just catches that and returns "just now" (because it only happens when the messages are shiny new)

Both the coffeescript and the compiled JS are available in a gist.

Just to be clear: it works fine for older messages, it only fails when I insert a new Message and that causes an update of conversation.messages.

from meteor.

This is not supposed to work.

Here's what's probably happening.

new Date() on the client returns an Object. Minimongo only stores JSON values. So the insert is dropping that (should be an error) and you get an empty timestamp field.

The insert RPC to the server stringifies its arguments, so you're actually sending the string representation of the date to the server. (This is also probably wrong.) The server inserts a document into the MongoDB collection, then publishes it back to the client, which replaces its copy with a new version that includes the timestamp field. Hence the flicker.

Closing this bug. We should throw errors on minimongo insert and update where the doc isn't JSON. And we should clarify the behavior of the wire protocol.

from meteor.