Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing #2

Merged
merged 40 commits into from
Jun 12, 2016
Merged

Testing #2

merged 40 commits into from
Jun 12, 2016

Conversation

kristiankyvik
Copy link
Contributor

Unit tests for chatter core

… API to take in room Ids when adding users to rooms
…ed to befoe wrapper, stub created for the Metero.users.findOne() call
…serId instead of passing parameter, moved many updates to the model layer
…actored many of the describe statetements, added proper meteor Error messages as well as custom validations to models
};

Chatter.configure = function (opts) {
_.extend(this.options, opts);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Certain that this will be set to the right context, and not to the caller's context? Might need to extend Chatter.options instead

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does seem to work after testing it!

}

return Chatter.UserRoom.upsert({
userId: chatterUserId,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which userId is this? If you name chatterUserId the same as Meteor's own userId you will quickly confuse yourself and the users of chatter. You might want to rename all variables that are chatterUserIds to chatterUserId to avoid this confusion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. This has been on my list for while. I have changed all variables to chatterUserId, and chatterUser. Will that suffice or should I also rename the attributes of the chatter models, so that when creating new instances in becomes this:

return Chatter.User.upsert({

  • chatterUserId: chatterUserId,
  • roomId: roomId
    });

rather than this:
return Chatter.User.upsert({

  • userId: chatterUserId,
  • roomId: roomId
    });

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would a chatter user have a chatterUserId? Wouldn't it be just _id in this case? And you also don't need to duplicate the variable name if key and value are the same.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The goal is to distinguish the two types of userIds that belong to different collections.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood. Just realized it was a stupid question. :)

@@ -1,7 +1,8 @@
Chatter = {
options: {
messageLimit: 30,
nickProperty: "username",
roomLimit: 15,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the max number of rooms a user can have, or a limit to the number of users in a room, or messages in a room?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed this. Now only a set number of rooms are loaded initially, and all rooms loaded after user clicks on "show more button". This set number of initially loaded rooms should be customizable through chatter options.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess same thinking can be applied to messages, like whatsapp, if you scroll far back and want to see older messages you can load more messages

…ces, user variable changed to chatterUser to avoid confusion, updated all methods names, removed database cleaner, removed need for multiple before statements...
…sts, alos renamed count attribute to unreadMsgCounter
@fumbleforce fumbleforce merged commit a848074 into fumbleforce:master Jun 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants