X

Technical Articles relating to Oracle Development Tools and Frameworks

  • JET
    November 23, 2018

JET 6.0.0 Notes for Component Authors

Duncan Mills
Architect

In my usual roundup, let's have a quick look at what's new an noteworthy for JET Custom Component Authors in JET 6.0.0 which was released recently. 

What's in a Name?

If you read the documentation and have a look at the cookbook, you'll notice that there is a subtle re-naming operation slowly taking place.  We're talking less about "CCA" and more about Custom Web Components in those places.  There is nothing to worry about here though, they are both the same thing, but we're just switching to use the more industry standard term to refer to the custom components that you create (Yes you are creating real Web Components). Throughout my blog articles I'm sure I'll slip up from time to time and revert to using CCA (because it shorter!),  but I'll do my best...

Changes to Deployment 

A subtle but valuable change has occurred in what happens when you do an ojet build or ojet serve command on a project that includes Custom Web Components.  As you will know, if you use the ojet create component command your new component will be created in the /src/js/jet-composites folder, this has not changed, but two slightly different things happen when you deploy:

  1. You will see that in the deployed structure for the project (the /web folder) that rather than mirroring the exact structure of the /src folder, the custom components are now deployed into a sub-folder which is defined by a version number.  Thus the loader file for a component e.g. /src/js/jet-composites/demo-comp/loader.js would end up as /web/js/jet-composites/demo-comp/1.0.0/loader.js where in this case 1.0.0 is the version number in the demo-comp component.json file. This change is intended to set us up for the future and to handle the case where you might have multiple versions of the component and want to switch between them.
  2. To complement this change in location in the deployed component code the build process now automatically creates a RequireJS path for you that points to the correct deployment location. This path has the same name as the component (e.g. demo-comp) and will point to the correct runtime location for the component automatically.

So what does this mean to you?  Well the major point is that when you consume a component in a view, in your define() block, rather than referring to the component by an absolute path e.g. jet-composites/demo-comp/loader, instead you can just use the path with the same name as the component e.g. simply demo-comp/loader. Over time this will be a good thing because it will allow you to carry out tasks such as bundling, or deploying your components to a CDN and not have to touch any of your code that relies on that component because all you will have to do is to tweak the RequireJS path for "demo-comp" (in this example).

Changes to the Loader Script

The final topic to discuss for the 6.0.0 release is a change you will see in the loader script generated for you by the ojet create component command.  In earlier versions you'll be familiar with loaders that look very much like this:


define([
    'ojs/ojcore',
    './viewModel',
    'text!./component.json',
    'text!./view.html',
    'css!./styles',
    'ojs/ojcomposite'
], function (
    oj,
    viewModel,
    metadata,
    view) {
        'use strict';
        oj.Composite.register('demo-comp', {
            view: view,
            viewModel: viewModel,
            metadata: JSON.parse(metadata)
        });
    }
);

Whereas in 6.0.0 and above you will see this, with the  ojs/Composite class now "in charge" so to speak and no need to import ojcore:


define([
    'ojs/ojcomposite',
    './viewModel',
    'text!./component.json',
    'text!./view.html',
    'css!./styles'
], function (
    Composite,
    viewModel,
    metadata,
    view) {
        'use strict';
        Composite.register('demo-comp', {
            view: view,
            viewModel: viewModel,
            metadata: JSON.parse(metadata)
        });
    }
);

This change is part of a larger simplification / cleanup that you'll see over the next few releases to remove the need to use the oj. namespace as a root to access everything. Both forms still work, and if you want your components to be compatible with older versions of JET then you can revert to the pre-6.0.0 format without a problem. Tis is particularly important if you are creating components for versions of Visual Builder Cloud Service that are using these earlier versions of JET.


JET Custom Component Series

If you've just arrived at Custom JET Components and would like to learn more, then you can access the whole series of articles on the topic from the Custom JET Component Architecture Learning Path

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha