Since there were these post here…
I think many of you will have problems to work with the following APIs…
- Authentication-API:
-
login()
-
onLogin()
-
perhaps register() ,too.
- CurrentMember-API:
- getMember()
These are the two APIs which are involved in the described issue of the posts (on my opinion).
And after some further analasying researches, i want try to explain the issued sutuation.
To answer the following questions:
-
Why does the new Member-API do not work 100%?
-
What exactly is the reason for the instability of the new Member+Authentication-API?
-
How to fix the problem, without beeing forced to use the old and depricated Wix-Users-API?
Well to be able to explain the issued situation a little bit better, i have prepared a little TEST-ENVIRONMENT, which should simulate the issued situation, when it comes to the usage of the Wix authentication + wix-members-API.
https://mt2-king.wixsite.com/website-3-1/blank-3
So give Mr-Persident a like, if he could help you to solve your issue …
…
How to use the example to see the ERROR?
-
Login with the given LOGIN-TEST-ACCOUNT.
Take a look onto console.
Log out again. -
Activate the SWITCH of the currentMember-API and do the same again, do not forget to take a look onto the given CONSOLE-LOG-RESULTS!
Log-out again! -
Now activate both SWITCH-BUTTONS to activate all included APIs and run the test again.
Take a look onto given CONSOLE-LOG-RESULTS!
To understand what this example wanted to tell you → you can show additional information by a click onto → SHOW-DETECTED-ERRORS-button.
So, i hope this example makes the issued situation more understandable for everybody.
I already tried to explain this in several different posts, but i think i was not able to give a precise and good understandable answer.
One person was already able to use this knowledge as a workaround…
Back to the questions…
Why does the new Member-API do not work 100%?
Well, like you perhaps have seen in the example, you don’t have any chance to get the ID after login the direct way.
The authentication . login - function…
https://www.wix.com/velo/reference/wix-members/authentication/login
import { authentication } from 'wix-members';
$w('#login').onClick(async () => {
const email = $w('#email').value;
const password = $w('#password').value;
try {
await authentication.login(email, password);
console.log('Member is logged in');
} catch (error) {
console.error(error);
}
});
Don’t give you anything back as result, after you have logged-in.
Because of that, you will have to use (additionaly) → the getCurrentMember() - function/API…
import { currentMember } from 'wix-members';
// Sample options value:
// {
// fieldsets: [ 'FULL' ]
// }
currentMember.getMember(options)
.then((member) => {
const id = member._id;
const fullName = `${member.contactDetails.firstName} ${member.contactDetails.lastName}`;
return member;
})
.catch((error) => {
console.error(error);
});
To get informations about the current logged-in user.
But even this do not work → 100%. The example demonstrates exacly this issue.
Using the following SETUP…
…you still won’t be able to get the → ID ← of the current logged-in-member …
…because → .then((member) => { ← do not provide any results after loggin!
!!! AND THIS IS PERHAPS EXACTLYTHE POINT, WHERE THE ISSUE STARTS !!!
!!! And here → onLogin()-function comes into game !!!
import {authentication} from 'wix-members';
authentication.onLogin(async (member) => {
const loggedInMember = await member.getMember();
const memberId = loggedInMember._id;
console.log(`Member ${memberId} logged in:`, loggedInMember);
});
Using the example and log-in with both activated functions, the login-starts to work and gives back USER-ID and all other data as RESULTS…
@Marlowe (Wix)
Perhaps you can connect to the right developement team, to test my example and proove my theoretical thoughts.
My conclusion:
Either the VELO-API-DOCs have to be changed, or the API itself has to be optimized → regarding either the login()-function of the → AUTHENTICATION-API, or regarding the → getMember()-function of the → CurrentMember-API (Members-API).
In the time of working on this API, we believed that due to performance considerations, it’d be better to leave the developer the choice on whether he would like to query for the member’s details or not. We’re definitely open to rethinking this design decision, and will do so. Can you please share more details on how the ID (or other member details) may serve you? I would like to understand your use-case better.
).
thanks for reply, very apreciated! Now i know that some kind person did a good job. 
In the time of working on this API, we believed that due to performance considerations,…
