Client side Insert approval status

core
1

I watched Slava’s presentation and I’m interested in replicating the What’s App clock/checkmark feature.

Steps:

  1. User inserts a message
  2. Message is displayed with a clock icon
  3. Server confirms the message
  4. UI gets updated with the checkmark icon

I couldn’t find a way to check if the message was accepted or if it’s pending. I would like to use the template to switch the icon. How can I archive this without using 3rd party packages? I would like to use collection.insert() instead of methods.

Solution that I don’t want to ear about: Use collection-hooks package to update a field on collection.after.insert or using a method with this.isSimulation

1 Like
2

Sorry dude, using a method is how you would do this.

1 Like
3

I can’t use Collection.insert()?
This is already calling a method, I just don’t have/know a way to know the current state of operation.

4

@mario Yes you could use a Collection.insert(), but you are still going to need an operation on the server to reset the flag which in turn would update the client. There are basically 2 ways to accomplish this when using a client side insert.

  1. Use collection-hooks
  2. Use Collection2/Simple-Schema with Collection2’s autoValue

Personally I would opt for the Collection2 option since IMHO you should be using it already, but that is just my opinion.

5

Edit: It looks like I misunderstood what you wanted, If you want the change in status purely to reflect if the message has reached the server or not, the only 2 ways are with a Meteor method or a collections transform as stated above. Sorry for the confusion.

You can totally use Collection.insert().
So the way to do it is to have a field on the message that is something like isViewed or isRecieved.

Then on your template you have an if statement that checks that field and if it is false show one icon and if its true show another.

The tricky part is how to update it. The most basic solution is that in the template helper that returns Messages.find(), before returning the messages cursor, loop through the messages and update all of them, setting viewed to true where the author is not the current user. Its that simple.

So what will happen is that on the sender side, the message will be inserted into minimongo immediately will will cause the message template helper to rerun. But since the author of the message is the current user, it will not touch the isViewed field.

While this is happening Meteor will be updating Mongo over DDP in the background and then pushing those changes to all the other clients. On the receivers their message template helpers will rerun since the collection has been updated and when that happens they themselves will update the isViewed field to True since they are NOT the author.

This will then propagate changes back to Mongo and in turn back to the sender, who’s message template helper will rerun yet again since the messages collection has changed. The template will update and since you used the if statement for the icon it will change to the viewed icon.

Remember though that this is a rather basic implementation, for improvements you would want to thing about setting up autoruns on template created for updateting the viewed field and be careful about how many items you try to update, (i.e. focus on limits on queries).

So I gave a talk about meteor at my University and I made a really simple chat application to show off features, and one of those is latency compensation, I implemented it basically as described above. You can view the code at https://bitbucket.org/posnea/meteor-tech-talk
and there is a running version of the site at http://chatterbox-suits.meteor.com/
You can safely ignore the aldeed:collection2 stuff and replace it with input boxes and normal meteor events, I just used to show off an example of a model layer in the talk.

6

I’m not sure if the package will help you, but I just added this capability to my socialize:messaging package. If it’s not what you need, feel free to rip it apart and use what you need.

7

What’s app uses 3 Steps: 1 - Sent to the server (clock) 2 - Confirmed ( 1 checkmark ) 3 - Seen by user ( 2 checkmarks ). With your approach I would know if the message was viewed but I wouldn’t know if the message was receive by the server. Minimongo should provide a way to check for this versus creating a special method to do what minimongo is already doing under the hood.

8

Actually, there might be a different way - did you know that insert provides a callback? Would that help? http://docs.meteor.com/#/full/insert

9

Yes, It would require me to keep a list on the template instance. What I’m looking for is the cleanest approach to solve this.

10

How would you handle errors / retry?
An idea may be to have a separate persistent local-only collection with the statuses of each document sent - which would be populated / updated through the minimongo insert / update callbacks. Eventually coupled with a collection-helper field returning the status of a given doc. Thoughts?