Allow .current to return CustomUser

[taivo]

If we do Parse.Object.registerSubclass('CustomUser', CustomUser);, parse still serializes the current user in local storage with className="_User". As such, in subsequent loading of the app, the deserialization process will know nothing of the CustomUser class and CustomUser.current() will just return a Parse.User. Thus we lose access to all the cool custom methods. Changing the registration to Parse.Object.registerSubclass('_User', CustomUser) fixes that.

[acinader]

thank you!

[dplewis]

While this does fix your issue, it would introduce another problem.

You would override ParseObject.registerSubclass('_User', ParseUser); here (I don't know what the side effects would be)

I did a PR recently for better support for user subclassing but I missed current.

[acinader]

ugh. I didn't fully understand now that you explain it. revert?

[taivo]

I would hold off on the revert. I traced the sdk code for .current() for about an hour and saw that it's littered with the hardcoded _User string and its association with ParseUser. I noticed the line ParseObject.registerSubclass('_User', ParseUser); and overriding that seems like a less risky option than dealing with all the hardcoded cases without a full understanding of the code. As long as the CustomUser class extends the ParseUser class, that makes CustomUser is a ParseUser.

Also, iirc during my trace, there are times when user processing work is delegated to CoreManager and the this context of CustomUser is lost. Also, parse seems to prevent the setting of the className field. That field gets written to _User so the raw data necessary to deserialize into a CustomUser currently isn't there.

I feel this is a good stop gap solution to help people get their own projects moving even though it's not ideal. I recommend we leave this in place until @dplewis or someone else has a full solution implemented.

And for what it's worth, a complete solution should also cover the various login providers.

[dplewis]

CustomUser here is simple but a more complex subclass could break your SDK. There is an open issue in JSSDK that shows this.

I’ll look into current, fromJSON should return the subclass. I’ll write a test case

[dplewis]

@taivo I just wrote a test case and CustomUser.current() works.

parse-community/Parse-SDK-JS#978

Can you let me know if any changes can replicate your issue?

[taivo]

@dplewis is there a way to test the effect of reloading a page? From what I can see, the object user: CustomUser is retained in browser memory after signUp/logIn and serialized into local storage. Without a page reload, the memory cache of user: Customer gets prioritized. When you reload a page, that cache is non-existent and deserialization from local storage takes place. That's when you see the problem. The crux of it seems to revolve around the className field being serialized as _User instead of CustomUser.
Not sure if this helps, but I spotted this issue while working with an ionic framework app so my thinking revolves around that context. Essentially every time I made a change, ionic reloads the page and boom, my CustomUser is gone and replaced with ParseUser

[dplewis]

@taivo Yes there is Parse.User._clearCache(). I'll update the test.