3

Many of the applications that I've seen or browsed through need to handle multiple different types of users whereby all users login / signup on one UI

For example in an E-commerce app you would have marketplace operators, sellers and buyers These users would all have different types of content depending on what type of user they are

Conditional Rendering is one of the options that would immediately come to mind.

But I would like to ask if there are any best practices when handling all these different user requirements/types in react native?

sheppard
  • 67
  • 8

3 Answers3

1

Of course, presumably when the user logs in you know if they are a seller or a buyer. Just store that somewhere and show different UIs accordingly.

You can re-use the same screens and just have different content, though that is kind of ugly, re-use the same navigation structure and render different components based on what type of user is logged in, or just have two different navigation structures that parallel each other.

Lots of options in-between those as well.

Reference: https://www.reddit.com/r/reactnative/comments/ecbs37/react_app_with_multiple_users/fbawdiv?utm_source=share&utm_medium=web2x&context=3

Md. Robi Ullah
  • 1,703
  • 3
  • 20
  • 32
0

I would classify your problem into whether you want to show entirely a different page for a different user / you want to show some specific extra things for that user in the page.

If its 1.

You can have a splashScreen, where you check the type of user / after login of user , then navigate accordingly to that stack of pages. Like if a pro user logs in, then navigate to. rewards page etc. ANd if a non pro user logs in, you navigate to How to avail a pro subscription etc.

If its 2.

As you mentioned, conditional rendering is the best for this sort of things.

A lot actually depends on how your designer will implemnet the UX part of it, since its crucial for your approach to be implemented.

Hope it helps. feel free for doubts

Gaurav Roy
  • 11,175
  • 3
  • 24
  • 45
0

I'll answer this question from a perspective of a regular web react app to give the idea, you can collect my ideas into your react native apps. even though I'm not a react native dev.

@ the login page, your app will send a POST request to the server, in which the HTTP service will respond back with the user document as a JSON object, in this JSON object, there are many fields, in one of those fields there must be a field with the name of something like "accountType" or "user_role". You can use that field and store it globally somewhere in your react/react native application.

Then, you will create two separate folder structures, with the names of the roles, ex: "seller/", "buyer/", "admin/".

inside these folders, you'll write the UI for based on every user role from the ground up.

during that, you'll find many components that can be reused, these components should go in a directory outside the role folder.

The reason I think it is the best approach for UIs that has too many differences based on their user roles is that I used to think that these roles UIs must be separated into different react applications,

for example, a react application for admin, a react application for user.

however the problem with this architecture is that you'll have a third react app just for the login page.

and in this third app, when a user logs in through it, you'll have no way to pass the state object from this react app to the other react apps.

you could pass it through the web browser local storage or something like that, but that's too much messy and not desired,

also there are limitations on how much space the local storage key and value can stores in the browsers.

you could use the second approach, but you should then send a GET request to the server through the user or admin react application to get the user document (or data), so you can render the content for that. which is a bit better than the approach of passing to local storage.

For recat on the web

I would only recommend the second approach if you don't want the regular users to know the api keys, URIs URLs or like that of the admin page. some stuff must be private and should not be served to the client, even if the api itself has restrictions. the front end should also restrict some stuff and not to show some data in its source code sometimes.

Normal
  • 1,616
  • 15
  • 39