logo

NJP

Stepping beyond the portal: Transitioning your skills to the Now Experience

Import · May 09, 2022 · video

Transcript

X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Welcome to Stepping Beyond the Portal. I'm Travis Toulson. In this session, we're going to be discussing how to transition your skills from the Service Portal to the Now Experience. So first of all, I want to cover a couple of things that we're not going to be covering in this session. And that's going to be NodeJS, now-cli, Component Project Scaffolding. For help on any of these things on getting started, you can check out the developer site, where there's a URL at the bottom. And there's a fantastic guide to help you get started down that road. So first up, let's talk about the editor experience. And for this, we're going to compare some of the features and attributes between the Service Portal editor versus what we are now working with in the Now Experience Components. So with the Service Portal editor experience, we're all familiar with that three-panel layout. And of course, there's a couple of hidden panels we can switch in. Widget source code is stored in ServiceNow in HTML, CSS, and ES5. The source code is combined primarily in a single record with the sp_widget. There are a couple of other widgets off of that. But for the most part, it's all governed within that single widget. Of course, the editor is browser-based, unless you're using the VS Code plug-ins. And whenever you save changes, you immediately get that update in the instance. You can immediately reload the page and see your results. And of course, one of the key features of Service Portal is that your server code and your client code sits side by side in the same widget, so you can rapidly iterate and build out those widgets on both sides of the network. Now, the UI Component editor experience really changes the game on this. First of all, your components are now stored in source code, basically in local files and folders on your local dev environment, using JSX, SCSS, and ES6. The source code is spread across numerous files. It's no longer consolidated to just one record. And you can bring your own code editor, which I highly recommend VS Code. Those changes also have to be deployed to the ServiceNow instance. So you're actually developing on a local environment. And you'll see those changes in the local environment. But if you want anybody else to see those changes, you're going to have to deploy your component up to the ServiceNow instance. Also, the UI component only contains the client code. So there's no server code inside of these components. And that's a very big difference between the two. So where do I put this code? Well, in the Now Experience, we're working primarily with JavaScript files and SCSS files. So your ES6 modules, in the form of JavaScript files, basically equate to your HTML templates, your Angular ng-templates, and pretty much all of your client-side JavaScript code-- the link function, the client controller, instance options, your angular providers. Basically any of this client's JavaScript that you would have put in Service Portal in various records is now all going to go into JavaScript files. And your SCSS equivalent, basically you'll have an SCSS inside of your local dev environment. And you will import those SCSS modules into your JavaScript modules. So it is a little bit different from what we're used to dealing with. But for the most part, there's really strong equivalent to the SCSS fields and the CSS dependency tables in your service portal widget. And as I said, there really is no equivalent for the server-side JavaScript. Basically, you can use UI Builder data resources or REST endpoints with the HTTP effect. But you really won't have the actual server code stashed in your components. Your components are strictly client-side. Now, in terms of how this looks in your local development environment, on the left-hand side, I've got the File Explorer for VS Code as the sample project that I'm currently working with. And you can see that the ES6 modules and the SCSS modules all fall under that SRC folder. And you can see the index.js and the styles.scss, which is part of your boilerplate project. Now, you can add additional files, additional folders, import things in. You can get as wild and crazy with the folder structure and file structure as you want. And that's one of the key advantages, is you can build larger projects in a very structured way, as compared to what we used to be able to do in Service Portal. So let's take a look at a sample project. And let's start out with the HTML template. So you can see in the laptop on the side there the example of what we're going to be outputting with the code. And so the view typically is done in the HTML template in the Service Portal. But let's look at how we would accomplish this in a Now Experience component. So in the Now Experience component, you can see the code on the right-hand side. And basically, if you look at that orange bar, you'll see a view function. Now, this is using the ES6 arrow function syntax. But trust me, it's basically just a function. So the HTML templates are going to be written in JSX. You'll notice the HTML inside of that view function. Now, JSX is a syntax extension to JavaScript. It's not actually HTML. We're not returning HTML out. Officially, your returning JavaScript objects that represent DOM nodes. But that's a little complicated for this session. The important part is to note that it is not HTML. And it has more equivalence to calling JavaScript functions. It does get compiled to JavaScript functions. And each view function can only return a single top-level element. And the last thing that I'll note is the parentheses after the return statement and at the end there. Those parentheses are very important when you're dealing with multiple HTML nodes. So you absolutely have to have that. And it basically creates the expression. So now let's talk about data binding. So in this one, you'll notice that I've changed the message from Hello, World to Hello, Travis. So basically, how would we bind that dynamic data? Now, in Service Portal, we used one way binding. And that used the double curly brace syntax in the HTML template. So let's take a look at how that's going to be done now. Again, on the right-hand side, you'll see the code. And you'll see in the first orange bubble that there's a var name equals Travis. So we're setting up a local variable. And then on the second red bubble there, you'll see a single curly brace with that name variable inside of it. Basically, since views are just functions, we can declare variables in them the same way we would in any JavaScript function. And that little single curly brace syntax is part of the JSX expression that embeds-- or binds the data to that particular expression. So it's very similar to our double curly brace syntax from Service Portal. And that's going to make the transition really easy. Now typically, we're going to want to get that dynamic data from somewhere else. We're not just going to use a static variable name. So let's take a look at how we can pass some instance options and hold internal state. And basically, this is going to be functionally equivalent to passing instance options into your widgets. Now, the one thing I want to highlight, though, is that there is a bit of a difference. Because in Now Experience components, the properties are much more powerful and a much more prevalent part of components than what they were in Service Portal. So once again, the example is there on the right. And let's take a look at the code. So first of all, take a look at that second orange line down there, where it specifies the properties inside of that createCustomElement call. And you'll see that we've defined a property called name. So this whole scaffolding is setting up our Now Experience component. This is some of the boilerplate scaffolding that is required. And the properties are basically equivalent to instance options. That name property is then being passed in to the view function via the state property. And you'll see on that first orange bubble, the Hello, state.properties.name. So the properties are exposed via that state variable-- or that state parameter. And you can use this in any of your custom components. Any properties that you add in that createCustomElement syntax is going to be available inside the view. And those properties can be updated as we perform different events and actions. But that, basically, is how you are going to pass data into your components in order to expose them within your view. So since we mentioned events and changing that data, let's go ahead and talk about, where's the ng-click? Where are these events? So once again, you'll see on the right-hand side, I have an example view with a button that says Change Name. So instead of changing that manually to Hello, Travis, we're going to change it when we click that button. So instead of using the on-click handlers in Service Portal, you usually use ng-click. And there's a bunch of other events we can use. But the short of it is that that triggers a digest loop, which reprocesses the view and updates it for you. Components are a little bit more straightforward. So once again, we're going to be using that view function. Everything basically goes inside this view function. It makes things very easy. And instead of the ng magic, you're actually going to bind events using on, dash, eventname, Just like you would traditional HTML and JavaScript events. And what's really powerful about this is that it even works with custom events. So if you define custom JavaScript events, you can just use on dash whatever event name you created, and it still works. Basically, behind the scenes, that on dash is just instructing the Snabbdom renderer to call element.addEventListener, where you pass the event name. So it's just a declarative syntax for that. And it makes it really easy to bind any event. So you really don't have to memorize any special magic ng incantations to make it work. You just have to know your event name. And you can see in the updateProperties where we are-- or sorry, we're passing in the updateProperties on that first orange dashed as a co-effect. And then on-- and I'm not going to go too much into that particular topic. You can find more on that in the guides. But we're going to call that update properties in order to update the name parameter to World. And that way, when we click on that button, that on-click event will fire. What's really cool is that we're still just dealing with JavaScript. JSX is just JavaScript. There's nothing particularly fancy about it. So we can create event handler functions the same way that we would in vanilla JavaScript. And this is going to be roughly equivalent to your c.handle something in Service Portal, c.updateName. So if you look at the second orange dash there, you'll see the updateName handler being called in the on-click. And up on that first orange dash, you'll see the updateName function being created. And because it's done within the view function, it has access to the updateProperties co-effect that we passed into the view function. All of this is handled by the Snabbdom renderer and by the overall Now Experience framework. So you just have to plug-in the right pieces in the right places. And the rest just fires and works. And of course, you'll also note that we're still using that curly brace syntax. Basically, any kind of dynamic binding that you will use will be done using the curly brace syntax, which makes it really easy to remember. Now, of course, no component is complete without a little bit of conditional logic. And of course, in Service Portal, we had ng-if ng-show, ng-hide, ng-switch. We had a lot of magical directives that we had to memorize in order to set up some of these conditional statements and some of these conditional templates that show and hide the view. So basically, in this one, when we click the button, we're actually going to hide that button. And once again, we're just using pure JavaScript here. So you'll see that, on the second dash there, the second orange dash, we call a getButtonTemplate function, where we pass the state parameter in. And then you'll see in that first long orange line, you'll see the getButtonTemplate that passes in the state. Now, the important part there is the if statement inside of that template function. So if state.properties.name name is not equal to World, then we will return that button template. So this is how we set up a conditional template inside of our view function. And you'll notice it's just plain JavaScript. It's just an if statement. This will work with switch statements. This will work with ternary statements. So basically, it's just JavaScript. And that really simplifies the learning curve on this. Because once you get a handle on the view functions and some of the magical bindings in the createCustomElement, you're really free to write those components how you want. You're not constrained to the magical directives that AngularJS offers. And also, I'll point out that you can separate the view functions. So you'll notice that I don't have all the HTML in one place. I can call functions to get other fragments of HTML out of it. And this is a really powerful capability. We can also move those functions off to other ES6 modules, which is really going to help us clean up our code and make it very compact and very well-structured. So then we've got lists. Of course, most of what we're dealing with is repeating over a list, repeating the same template over lists. In Service Portal, this is done with ng-repeat to loop over iterable objects like arrays. Once again, components have no problem leveraging pure JavaScript to accomplish this. So in the component, you'll see, first of all, that I'm passing in properties. I'm passing in an array as the default, with five items. And then in the first orange dash, you'll see my little ul tag there with state.properties.items.map. Yeah, it's just JavaScript, array.map function. So we're going to iterate over the array using plain JavaScript. And we will return the list item template that represent each item. So the map function is going to be similar to for each, except that it returns a new array, where each new item in that array is the result of the original item passed to the map function. I'm going to leave it to you guys to go look that one up in a little more detail because I don't have a clear demo of that one for this presentation. But suffice it to say, it works just like for each, except that it creates a new array using the function that you pass it. In this case, we're returning to LI tags that contains the item name. Similar to conditionals, we can separate that template fragment out into its own named function, like the getListItem one that you now see in the code section. And this can make templates much easier to read. And again, we can separate that off into separate files to get a very well-structured project out of it. And of course, we're just getting started with this. There's so much more to add. There's actions. There's life cycle. There's hooks and behaviors. There's a lot of stuff that we haven't really covered today. This is really just a foundation to give you those basic ng-ifs, ng-repeats, how to get data in and out of your components. But for more, you can go to the developer website, where there's a really good introduction, getting started guide, for building out these Now Experience components. But this should really help you get started on your journey in transitioning your skills from the Service Portal to the Now Experience framework. So with that, if you have any questions, you can feel free to reach out to me. My email is [email protected]. Or you can head to the codecreative.io website. Thank you very much. [MUSIC PLAYING]

View original source

https://players.brightcove.net/5703385908001/zKNjJ2k2DM_default/index.html?videoId=ref:CCB1117-K22