Accounts.removeEmail is not a function

1

Hi! I’d like the ability to edit a User's Email. This is for Meteor.users (The users Collection).

Each document contains an array of Emails and I’d like to replace one of the subdocs in the array.

I’m trying Accounts.removeEmail(existingProfile.userId, existingProfile.userEmail); Accounts.addEmail(existingProfile.userId, profile.userEmail);

This actually seems to update in the DB. However, I get Server errors of Accounts.removeEmail is not a function. I’m attempting to hit this code in a Collection Helper and I’ve imported

import { Accounts } from 'meteor/accounts-base' into the module. Does anyone know why this would happen? Thanks!

2

Are you calling it in a meteor method? I bet you that method is also running on the client in a stub. It’s likely that the client stub throws the error (where removeEmail doesn’t exist), but the call to the “real” method on the server works, which is why you see an error thrown even though the call seemingly works. Just guessing, though!

Try putting a console.log before the call and check your browser console to see if it’s logging there. If that’s the case, you can move the method to a server folder (so that it only runs on the server), or surround the call to removeEmail in an if (Meteor.isServer) ....

3

@moberegger Yeah, that was my hunch too and it seems to be the issue. I’m confused now though, so do meteor methods really run on both client and server, unless specified (whether through folder directory or Meteor.isClient/Server calls). Also, I now get Meteor.isServer() is not a function.

4

Meteor.isServer isn’t a function, it is a boolean variable

2 Likes
5

Also, a method only runs both on the client and the server if it has been defined on the client as well (I think this was referred to as latency compensation?). A method that is only defined on the server will only run on the server.

Here is an example for a method defined on the client and the server

Meteor.methods({
 someMethod(arg) {
  if(this.isSimulation) {
   // we are still on the client and could do some stuff, like disabling buttons, etc.
  } else {
   // this part runs on the server
  }
})
6

I prefer the other name for it, “Optimistic UI”.
Meaning the client modifies local state with the assumption that it will be successful on the server (because it is 99% of the time) and then resolves any conflicts when the server does finally respond.
Makes your app feel much more responsive as you don’t need to wait for the server to respond for each action

3 Likes
7

I always get the terminology for the minimongo updates and client side methods confused :wink:

1 Like
8

Thanks! This solved it

9

Official Meteor Tutorial refers to it as ‘Optimistic UI’. Thing I never understood is what happens in that 1%? Wouldn’t there be an odd flicker of where things get reverted?

10

It depends on how exactly your code is structured

If the client and server are both successful, but with different results, you’ll get a flicker as the server version replaces the client one.

If the server throws an error, you have the opportunity to handle it and display a message to the client.

The first point is why I try to share as much code as possible between server and client, so the result is the same.
One notable exception is uploading images attached to another object, on the client I set a placeholder image url on the client, and the server asynchronously generates a thumbnail and updates the document, at which point the client updates, replaces the image url and loads the thumbnail.
It does flicker with the image being replaced, but it’s an expected replacement so not an issue

1 Like