Page Variables vs. App Variables on profiles

#1

Hey there, we’re having a little trouble understanding the exact context of app variables (AV) versus page variables (PV). We get that AVs are used for user account settings, etc., but how much does it actually affect what an external users will see? I’ve checked the Doc pages but there’s really not much to go on and this has been a brick wall for us.

For example, I’m currently working on a profile page*** with multiple layout sets (containers styled differently and with unique information) designed to convey the status of a user, both, *to themselves and **when viewed by another user.

Terminology:
Primary User = PU - The individual who is signed in.
Secondary User = SU - A visitor to the PU’s profile, whether they’re signed in or not.

Layouts are:

  1. *A standard profile layout as viewed by the PU with an Edit Profile button in the bio and edit/delete icons with each post.

  2. **A standard profile layout for the SU with the Edit Profile button being replaced with a
    Follow/Unfollow Button and the edit/delete icons replaced with a Report Post button.

  3. A layout explaining that a user has set their profile to private if the SU is not currently following them. Contains a button to follow the user. If the user is already followed by the SU, show #2.

  4. A layout explaining that the user has deactivated or deleted their account.

  5. A layout explaining that the user has been banned by moderation.

• Our primary question is whether app variables are used only by a signed-in user to effect changes to their account such as their profile bio and what they choose to post? Should we think of it as being relevant exclusively to updating their profiles or posting content and not actually controlling what layout is visible depending on their account status?

• ***Second is whether we should just design six different pages that could be attached to every user’s account representing any of the aforementioned statuses with their respective layouts. They would only display depending on what is going on with said user.

Or, should it just be five separate container layouts on a single page with visibility to the SU controlled by… what, page variables or app variables? I’m leaning towards a blend of both there.

Or, is it better to design two “Profile” pages, one representing what the primary user sees and always having the same general layout, and one for what SU will see with its layout relative to the PU’s account status, i.e. private, banned, deactivated, etc.?

I understand it’s a bit convoluted. We’d mostly like to know where app variables and page variables fit in with controlling what is visible to the PU and SUs. Thank you!

#2

Hi! Sorry for the belated answer.

The biggest difference between app and page variables is that page variables are only available on the page they are on, while app variables are available on any page in the app. Both are local and get lost if the user quits the app.

As for what you want to do, it’s an authentication thing, where you want to show certain things to certain users, right? Then you should simply have user groups (the current user’s group stored in the app variable of current user settings) and show/hide certain containers based on the user group of the user. The core here is to use the visibility of the element rather than e.g. styles to hide the element.

So I would lean towards showing/hiding containers, but you could also have separate pages to push based on the user’s user group, that’s up to you. I find the latter to be more copy pasting and annoying if you have to change the layout a little, as you then have to do the changes in more places.

1 Like
#4

Awesome insight, Mevi. Thank you! I wasn’t even sure if that made sense.

So going back to PVs vs. AVs, then app variables are used to contain, display, and modify individual user data on the front end, yes? I say this because we’d briefly had the Appgyer Auth installed and noticed the appearance of a set of user variables (it may have always been there, I’m not sure) for id, username, currentUser, etc under the App Variables tab.

Thus, we’d assumed when we get a backend connected, we would, for example, bind text fields on the primary user’s profile to such variables to display their name, location, and the like. Likewise, on the account settings page of our platform, input fields would be bound to inject information back to those variables upon saving changes. Perhaps, we’re wrong there.

As for the pages, we’d brainstormed this further in the last week and came to a conclusion that a blend of pages and container variables would do:

  1. A universal ‘User does not exist’ page. Being a web app with its address styled roughly as https://www.sitename.com/(username) , this page would function as a default on-platform version of a 404 page. A user would see this any time they enter an incorrect username into the address bar.
  2. A PU Profile page (with an Edit Profile button) which is only visible to the signed in user as it’s their own home page, if you will.
  3. An SU Profile page (with a Follow/Unfollow button) which is what a visitor sees, signed in or not, sees when viewing another user’s page. Would hold a set of master page containers with visibility depending on the user’s status:
    • The default functional profile page layout.
    • The ‘User has set their profile to private’ page layout.
    • The ‘User has deactivated their account’ page layout.
    • The ‘User’s account has been terminated by moderation’ page layout.

This would seem to keep things clean and simplified and, most importantly, places a clear line between what profile page a PU would see for themselves versus for others.

#5

Yes, we tend to use app variables to hold user information. Another option is to have it as a data resource, but that is “too heavy” a solution most of the time, I find. But if you have the user defined very well as a resource in the backend, this might work for you.

Just regarding your point number 1: Not sure if we support routes yet, so not sure how exactly you’d implement this :thinking: But 2.X is coming out very soon and that has some type of routes, which may perhaps work for you.

1 Like