Using Access Groups for Conditional Visibility

Here's what we're thinking...

At this point our discussions are focusing on two key use cases for Access Groups;

1. Conditional visibility of elements

2. Routing

Modify Your Page by Access Group

Currently, you can check for access-group inclusion by checking the array, e.g.;

user.access_groups.includes('pro');

This technique is demonstrated in the cloneable to apply user access group info to attribute-tagged elements.

<script> 
window.sa5.push(['userInfoChanged', 
  (user) => {
    
    // Check to see if access_groups info is loaded
    if(user.user_data_loaded.access_groups) {
    
      // Make changes to the page when the current user
      // is in the 'pro' access group.
      if(user.access_groups.includes('pro') {
        
        // Do whatever you want to your page
        
      }
    
      // Make changes to the page when the current user
      // is NOT in the 'pro' access group. ( notice the ! operator )
      if(!user.access_groups.includes('pro') {
        
        // Do whatever you want to your page
        
      }    
      
    }
    
  }]); 
</script>

Conditional Visibility

This technique can be used with custom code to hide, show, create, or remove elements.

Displaying certain elements only to users in a specific access group

Let's suppose you have several elements that you only want to appear when the user is in an access group named pro, and you want those elements deleted from the DOM otherwise.

Setup;

• Create a global class, we'll call it access-group-pro for simplicity.

• Assign it to all elements that you want to appear only for your pro access group members.

• Set the style to display: none, so that it is initially hidden, until access group can be determined.

For this type of operation, global classes are quite useful since they can be applied on top of other class arrangements. Alternatively, simply wrap your elements in a DIV and assign your pro-users class.

<script> 
window.sa5.push(['userInfoChanged', 
  (user) => {
    
    // Check to see if access_groups info is loaded
    if(user.user_data_loaded.access_groups) {
  
      // Find all elements tagged [access-group]
      // and set the inner text to YES | NO
      const elements = document.querySelectorAll('.access-group-pro');
      elements.forEach(element => {
      
        if(user.access_groups.includes('pro')) {
        
          // If the user is in the 'pro' access group, remove our global class
          // this will make the element visible
          element.classList.remove('access-group-pro');
          
        } else {
        
          // If the user is NOT in the 'pro' access group, remove the element
          element.remove();
          
        }
      
      });
      
    }
    
  }]); 
</script>

SECURITY: if you are working with any form of sensitive data, this is not a means to secure that data. Even removing the element will not prevent prying eyes from finding it if they simply disable javascript and examine your page source.

Future Ideas

We're looking at adding conditional visibility support to SA5's Data-Binding lib. Currently our thinking is this;

• Add two new attributes;

  • wfu-bind-show will display an element, only if its data-bound value is truthy

  • wfu-bind-hide will hide an element if its data-bound value is truthy

• Add a new internal binding resolver piece to the architecture which is source-aware. Regarding the User Object, it will resolve the access_groups array into a bindable boolean value.

This would support attribute constructions like;

wfu-bind-hide = $user.access_groups.basic

With this you can make elements conditionally visible on the basis of a single access group.

The reason for both a show and a hide variant is that it allows easily for a default state.

Truthy basically evaluates in the same as JavaScript's truthy, however SA5 expands on this slightly.

In the future we may consider more complex specifiers like multiple groups with a boolean AND;

e.g. $user.access_groups.basic+pro

A boolean OR;

e.g. $user.access_groups.basic|pro

And check-modifiers like boolean NOT;

e.g. $user.access_groups.basic+!pro

However at this point you would handle these situations using custom code.

Later, deprecate [wfu-show-logged-in] with an SA5 Data-Binding approach, e.g.

wfu-bind-show = $user.logged_in

Routing

This is a bit of a beefier design change as we've just built a routing engine as part of the upcoming Detect lib. We'd want to separate that into its own module and likely move it into SA5 Core. As a result, we need to design this piece carefully.

Use cases;

• On entry into any page, e.g. /my-page redirect the user based on their presence / absence from an access group.

• Modify URLs and button links depending on a user's presence / absence from an access group.

Zoning

This feature would probably benefit from some concept of zoning as a part of the routing architecture, so that you can broadly group pages and elements into an access zone. This would work in conjunction with Webflow's current access-group gating.