Is there a way to turn web CurrentUser into a class-based instance with methods

Hey all, I’m hoping to attach simple convenience methods to the current user object to keep the code cleaner. For example, methods like getAvatar = () => this.avatarUrl || this.DEFAULT_AVATAR or isSetupNeeded = () => /*infer from several other existing properties*/

Is there a way to do this cleanly with type safety in RedwoodJS?

If there isn’t one, in your opinion is this not the right way to approach Node, React, Redwood type of projects?

Thanks for your help.


export const User: UserRelationResolvers = {
    getAvatar: (_obj, { root } )  => {

           if(!root.avatarUrl) {
               return  DEFAULT_AVATAR

            return root.avatarUrl

Just make sure you define avatarUrl in the sdl and make it optional

There is also RedwoodRecord | RedwoodJS Docs

Like @guledali says, I’d do this on the api side.

Personally, I would not add more content the currentUser since that should really just be for auth.

Instead, I might add info to either:

  • user_metadata

or even have a new model Profile that keeps track of things like avatars and profile completeness etc.

This could be a new Prisma model, or just a sdl type and service method that gets populated with info from the User.

Correct me if I’m wrong but I think in general Redwood.JS perfers functions over classes.

Maybe people with OOP background might struggle with this concept anyway I found this book to be really good explaining how to approach node development and functional programming

Thanks for taking the time to answer! Is RedwoodRecord still being actively developed? I wasn’t able to find many references to it other than the docs page saying it’s experimental so I was hesitant to make the leap.

I don’t have a good feel for the lay of the land just yet and am learning incrementally. Where would I put this resolver in order to connect the plumbing directly into currentUser on the web side?

@dthyresson in my limited experience with RedwoodJS and JWT auth so far, I’ve only seen user_metadata being included as a field belonging to the RedwoodUser/CurrentUser object.

Please help me get a better feel for things. Do you mean to say that the right way to handle things is to completely separate that object from the current user (and query it separately)?

Or do you mean that non-essential properties should be accessed as currentUser.user_metadata.someProp instead of currentUser.someProp?

This is excellent. Thank you for the link!

You’re right, I’m definitely struggling a bit with wanting to have methods attached to data models. It currently feels more natural to me and seems to be a good OOP value-add to the functional approach, especially for methods that respect the host object’s immutability. I probably just need to spend more time to build a different set of mental habits though :grinning: