feat(tabs): provide canActivate and canDeactivate guards

[chintankavathia]

added SiTabComponent.canActivate and SiTabComponent.canDeactivate to control activation/deactivation of tabs similar to angular router guards.

• I confirm that this MR follows the contribution guidelines.

[github-actions]

Documentation.
Examples.
Playwright report.

[timowolf]

Many thanks, while the implementation is great, can you please also add the canActivate to the example. E.g. Does it make sense to show a tab that cannot be activated? Or should it be hidden @panch1739

[timowolf]

LGTM

[panch1739]

Many thanks, while the implementation is great, can you please also add the canActivate to the example. E.g. Does it make sense to show a tab that cannot be activated? Or should it be hidden @panch1739

If I understand correctly, when a tab/route is protected by canActivate, the user may click it and nothing happens because they don’t have access. From a UX perspective this feels broken, since the system is silently blocking navigation.

I would suggest:

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf @chintankavathia would that be possible? maybe we can add a short guide?

[chintankavathia]

Many thanks, while the implementation is great, can you please also add the canActivate to the example. E.g. Does it make sense to show a tab that cannot be activated? Or should it be hidden @panch1739

If I understand correctly, when a tab/route is protected by canActivate, the user may click it and nothing happens because they don’t have access. From a UX perspective this feels broken, since the system is silently blocking navigation.

I would suggest:

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf @chintankavathia would that be possible? maybe we can add a short guide?

@panch1739 sorry for the confusion. Apps can provide the feedback (e.g navigate to info page or show a toast message etc) when tab is clicked but is protected by canActivate.

[panch1739]

Many thanks, while the implementation is great, can you please also add the canActivate to the example. E.g. Does it make sense to show a tab that cannot be activated? Or should it be hidden @panch1739

If I understand correctly, when a tab/route is protected by canActivate, the user may click it and nothing happens because they don’t have access. From a UX perspective this feels broken, since the system is silently blocking navigation.
I would suggest:

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf @chintankavathia would that be possible? maybe we can add a short guide?

@panch1739 sorry for the confusion. Apps can provide the feedback (e.g navigate to info page or show a toast message etc) when tab is clicked but is protected by canActivate.

Ann thanks @chintankavathia! Would it be possible to add this sort of guideline somewhere? I think it would be nice to mention that...

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf what do you think?

[chintankavathia]

Many thanks, while the implementation is great, can you please also add the canActivate to the example. E.g. Does it make sense to show a tab that cannot be activated? Or should it be hidden @panch1739

If I understand correctly, when a tab/route is protected by canActivate, the user may click it and nothing happens because they don’t have access. From a UX perspective this feels broken, since the system is silently blocking navigation.
I would suggest:

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf @chintankavathia would that be possible? maybe we can add a short guide?

@panch1739 sorry for the confusion. Apps can provide the feedback (e.g navigate to info page or show a toast message etc) when tab is clicked but is protected by canActivate.

Ann thanks @chintankavathia! Would it be possible to add this sort of guideline somewhere? I think it would be nice to mention that...

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf what do you think?

@panch1739 @timowolf added some explanation here https://github.com/siemens/element/pull/735/files let me know if this works

[panch1739]

Many thanks, while the implementation is great, can you please also add the canActivate to the example. E.g. Does it make sense to show a tab that cannot be activated? Or should it be hidden @panch1739

If I understand correctly, when a tab/route is protected by canActivate, the user may click it and nothing happens because they don’t have access. From a UX perspective this feels broken, since the system is silently blocking navigation.
I would suggest:

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf @chintankavathia would that be possible? maybe we can add a short guide?

@panch1739 sorry for the confusion. Apps can provide the feedback (e.g navigate to info page or show a toast message etc) when tab is clicked but is protected by canActivate.

Ann thanks @chintankavathia! Would it be possible to add this sort of guideline somewhere? I think it would be nice to mention that...

• By default, tabs should be hidden when the feature is irrelevant to the user’s role.
• If there’s a clear reason for the user to see the tab (for example: to request access, or contact an admin), the tab may remain visible. In this case, navigation should still work but lead to a screen with an info page component with something like:
  “You don’t have access to this feature.
  “Contact your administrator to request access.”

@timowolf what do you think?

@panch1739 @timowolf added some explanation here https://github.com/siemens/element/pull/735/files let me know if this works

@chintankavathia amazing! Thank you. Lets hear what Timo thinks ;)

[siemens-element-bot]

🎉 This PR is included in version 48.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀