service portals

[vodnalar26]

hello everyone,

When to use c. and $scope in service portals scripting?

[Tanushree Maiti]

Hi @vodnalar26 

• Use c (controller alias, e.g., var c = this;) for:
• Widget data (c.data)
• Widget options (c.options)
• Methods/functions (c.save(), c.loadData())
• UI state (c.loading, c.showModal)
• Variables used directly in the template (ng-click="c.save()", {{c.data.name}})

• Use $scope only for AngularJS-specific features, such as:
• Event broadcasting

$scope.$broadcast('eventName');
$scope.$emit('eventName');
$scope.$on('eventName', function(event, data) {
  // handle event
});

• Watchers

$scope.$watch(function() {
  return c.data.value;
}, function(newValue, oldValue) {
  // react to changes
});

• Deep watches

$scope.$watch('c.data.items', function(newVal) {
  // ...
}, true);

• Cross-widget or parent-child communication using AngularJS events
• Accessing Angular lifecycle features that require $scope

Refer: https://www.servicenow.com/community/developer-forum/service-portal-updating-the-record/td-p/1343221

https://www.servicenow.com/community/developer-forum/in-service-portal-widgets-why-do-we-use-the-c-v...

[Tanushree Maiti]

Hi @vodnalar26 

Check this article as well:

ServiceNow Service Portal: Choosing Between c.server.get() and c.server.update() the Right Way

[lauri457]

Do you mean which to use when binding data in the template? Eg. 'ng-if="c.showThis()"' vs 'ng-if="showThis()"'.

You might want to read on the "controller as" syntax from the angularjs documentation to form your own opinion but ultimately it does not really matter functionality wise. Less so in the context of service portal when using widgets and not directives defined in angular providers.

You can search for discussions on the benefits of the pattern but one reason  to use it is to clarify where values originate from when you have nested directives on your app. Think 'parentCtrl.someValue'  & 'childCtrl.anotherValue' vs referencing the property name only when it is a property of scope directly. The controller as syntax makes the controller function a property of scope so you avoid prototype inheritance issues with primitives by design as well.

I'd say only inject $scope and use $scope for it's own api ($on, $emit, $watch etc) when needed. Declare everything else on the controller for consistency since this is where the server and data objects are bound. The OOB widgets don't really follow any particular pattern.

[Sachin_Nasa]

Hi @vodnalar26 ,

In my experience, c should be the default choice for widget development because it keeps the widget self-contained and easier to maintain. Most data binding, server calls, and client-side functions can be handled through c.

I typically use $scope only when I need Angular-specific functionality such as:

• $scope.$on() to listen for events
• $scope.$broadcast() or $scope.$emit() for widget communication
• $scope.$watch() to monitor value changes

As a best practice, avoid storing widget data on $scope unless there is a specific AngularJS requirement. Using c helps reduce scope-related issues and makes the code easier to understand and support.

If you found this helpful, please mark it as Helpful and Accept as Solution so it can reach others too.

[Sujit Jadhav]

Hello @vodnalar26 ,

When to Use c. and $scope in Service Portal

Use c. (Controller As Syntax)
- Store variables and functions
- Access widget data (c.data)
- Call server scripts (c.server.get(), c.server.update())
- Recommended by ServiceNow

Example:
var c = this;
c.message = "Hello";

Use $scope
- Listen to events ($scope.$on)
- Watch value changes ($scope.$watch)
- Broadcast or emit events

Example:
$scope.$on('record.updated', function() {
// logic
});

Best Practice:
- Use c. for most widget development.
- Use $scope only for AngularJS-specific features such as events and watchers.

Simple Rule:
Data & Functions = c.
Events & Watchers = $scope

"If you found my answer helpful, please like and mark it as an "accepted solution". It helps future readers to locate the solution easily and supports the community!"

Thank You,

Sujit Jadhav