JET v8.0.0 Release Notes

25 Nov 2019

To view Release Notes from a prior release of JET, select the specific below

These release notes cover the following topics:

• Things you need to know first
• New Features included in v8.0.0
• Significant changes that have been made to JET since 7.2.0
  • Component Changes
  • API Changes
  • Theme Changes
  • Public Style Class Changes
  • Framework Changes
  • Library Changes
  • Tooling Changes
• Known Issues
• Other v8.0.0 Notes

Things you need to know first

• Library Dependency updates: Make sure you read about these updates and make any appropriate updates to your application as needed.

• New ES6 support with ES5 fallback for IE11 support. This update will effect migration steps. Read More...

• Working with the Visual Studio Code extension for JET Core. Read More...

• New oj-select-single component available and oj-select-one is deprecated. Read More...

New Features included in v8.0.0

New UI Components and Component Features

oj-chart

• oj-chart now has the ability to auto-adjust the position of the data labels when they overlap with the chart's major axes or the legend, or if they go outside the bounds of the chart's plot area. Please see the API doc for the new attribute, style-defaults.data-label-collision, and the Scatter Chart | Data Labels demo for sample usage.

oj-diagram

oj-diagram now supports custom renderers for Diagram links. Please see the API doc for the new attribute - link-content. A corresponding template slot, linkContentTemplate, has been added to provide a declarative way for defining custom Diagram links. Also a new node-content attribute has been added to the component to consolidate custom renderers for the Diagram nodes. The existing custom node renderers should be moved under the new attribute. See the following demos for usage of node and link custom renderers.

• Custom Renderer
• Custom Containers
• Inline Templates

oj-list-view

A new gridlines.item attribute has been added to allow applications to control the visibility of gridlines in ListView.

New colspan-wrap attribute on oj-form-layout

The oj-form-layout component has a new colspan-wrap attribute. This attribute allows applications to specify how to fit components with colspan attribute in the form layout, when there are fewer columns left in the current row than the colspan value specifies.

New label-edge attribute on all form controls (oj-input-text, oj-checkboxset, etc.)

A new label-edge attribute has been added to all form controls to allow form controls to create labels inside themselves. This can be used in combination with the label-edge attribute on oj-form-layout to control different label behavior.

New max-rows attribute on oj-text-area

oj-text-area now has the ability to change its height in response to content change. The new attribute "max-rows" has been added to oj-text-area. Max-rows is the maximum number of visible text lines for the textarea. Please see the API doc for the new max-rows attribute on oj-text-area.

oj-select-single

The new oj-select-single component will replace the existing oj-select-one component. The new oj-select-single component has better DataProvider integration and has more powerful dropdown customization support than the old oj-select-one component. We expect to deprecate the oj-select-one component in a future release. Please see the API doc and demos for the new oj-select-single component for more information.

Significant JET changes since 7.2.0

This section lists significant consumer-facing changes that have been made to JET since v7.2.0. Where bugs or ERs were used to track the change, they are included below. The following list does not include changes that are internal implementations, or changes made to samples, demos, or test collateral. It is expected that application code will not need to be modified to uptake v8.0.0.

Component Changes

oj-progress-list has been deprecated

oj-progress-list and the associated ProgressItem interface have been deprecated. Applications should use oj-list-view with custom item content to handle usecases that were previously addressed by oj-progress-list.

oj-input-date and oj-input-date-time Today button will highlight the day based on the timezone specified in the converter.

In previous releases, the Today button highlights the day based on the user locale. Starting with JET 7.2.0, the Today button will highlight the day based on the timezone specified in the converter. If there is no timezone option in the converter, the Today button will highlight the day based on the user locale.

oj-input-time Now button will highlight the time based on the timezone specified in the converter.

In previous releases, the Now button highlights the time based on the user locale. Starting with JET 7.2.0, the Now button will highlight the time based on the timezone specified in the converter. If there is no timezone option in the converter, the Now button will highlight the time based on the user locale.

oj-input-number renders no up/down buttons when step=0

In previous releases, step must be 1 or greater and oj-input-number always renders the up/down buttons, and the up/down buttons and arrow keys increment or decrement the value by the step. Starting in this release step can be 0. When step is 0 the up/down buttons do not render and the up/down arrow keys do nothing. The default value for step is theme-dependent and for the alta themes that is 1.

This provides another way to get an input field with no buttons for a number type. The other way is for app developers to use an oj-input-text component and bind their own number converter and numberrange validator.

Deprecation of 'async-validators' property for all input components

The 'async-validators' attribute was deprecated to simplify the API and prevent confusion. Please use the 'validators' attribute for validators which implement either the Validators or AsyncValidators interfaces. Any AsyncValidators currently specified in the async-validators property can be safely combined with any Validators specified in the 'validators' property.

Deprecation of 'render-mode' property for all input components

The 'native' mode rendering of the input components namely 'oj-date-picker', 'oj-date-time-picker', 'oj-input-date', 'oj-input-date-time', 'oj-select-one' and 'oj-select-many is deprecated because JET is promoting a consistent Oracle UX over native look and feel in Redwood. Since the property 'render-mode' takes only two values 'jet/native', the property 'render-mode' of these components is now deprecated. The theme variables '$inputDateTimeRenderModeOptionDefault' and '$selectRenderModeOptionDefault' are also deprecated for the same reason.

Deprecation of JSON specified converters and validators

Support for JSON specified converters and validators was deprecated because the ValidationFactory and ConverterFactory APIs were deprecated. Please see the API section for an explanation of why those APIs were deprecated.
For all input components, specifying converters and validators via JSON has been deprecated. Please instantiate validators and bind them to the component instead. e.g. instead of:
<oj-input-text id="id1" validators="[[[{type: 'regExp', options: {pattern: 'a-zA-Z0-9]{3,}', messageDetail: 'Enter at least 3 letters or numbers'}}]]]" />
In your viewModel, please instantiate a new validator instance and bind it:
this.validator = new RegExpValidator({pattern: 'a-zA-Z0-9]{3,}', messageDetail: 'Enter at least 3 letters or numbers'});
<oj-input-text id="id1" validators="[[[validator]]]" />

If needed, you can make the json format work again by importing the deprecated ojvalidation module that contains the validator or converter you need: ojvalidation-base, ojvalidation-number, or ojvalidation-datetime.

ojvalidation-base, ojvalidation-number, and ojvalidation-datetime modules deprecated and removed from JET Components' dependency

For performance reasons and to prevent module loading side effects, ojvalidation-base, ojvalidation-number, and ojvalidation-datetime modules have been deprecated. JET Components that imported these modules no longer do.

For example, previously the 'ojs/ojvalidation-number' module was always included as a dependency of the 'ojs/ojinputnumber' module even if all the classes in the module were not used by the oj-input-number component, e.g., even if the numberrange validator was not used for the particular oj-input-number, it was loaded. Apart from the performance impact of loading unused classes, this had the side effect of application code which relied on code in 'ojs/ojvalidation-number' working (e.g. oj.Validation.validatorFactory('numberrange')) simply because 'ojs/ojinputnumber' was used somewhere in the application. Removing 'ojs/ojinputnumber' from one part of the application could therefore cause another part of application to break for hard to debug reasons. Or loading a page in different order could cause the page to break. For example, if page 1 has an 'ojs/ojinputnumber', and page 2 doesn't but uses oj.Validation.converterFactory('number'), it would have worked if page 1 is loaded first, and not work if page 2 was loaded first or 'ojs/ojinputnumber' was removed from page 1. We have always advised against relying on this side-effect module loading.

The validators and converters are now in their own modules, and they are no longer on the oj namespace since we do not want any side-effect module loading. We recommend importing the specific converter or validator module you would like to use. Like, define(['ojs/ojconverter-number'], function(NumberConverter) { var converter = new NumberConverter.IntlNumberConverter(options); }

For more information on the deprecated modules and the new modules that replace them, see the API Changes section.

Because the 'ojs/ojinputnumber' module no longer imports 'ojs/ojvalidation-number' and because validators and converters are no longer on the oj namespace, this code will no longer work:

            define(['ojs/ojinputnumber'],
              function() {
                this.numberRangeValidator = new oj.NumberRangeValidator({min:0, max:10});
              }
            

Starting in v8.0 rewrite it like this

            define(['ojs/ojvalidator-numberrange', 'ojs/ojinputnumber'],
                function(NumberRangeValidator) {
                  this.numberRangeValidator = new NumberRangeValidator({min:0, max:10});
                }
            

Or better yet, use the AsyncNumberRangeValidator. The Async Validators are lightweight. They load their sync validator's module (which contains the validate/getHint logic) only when validate or getHint are called the first time. This results in better load-time performance.

          define(['ojs/ojasyncvalidator-numberrange', 'ojs/ojinputnumber'],
              function(AsyncNumberRangeValidator) {
                this.numberRangeValidator = new AsyncNumberRangeValidator({min:0, max:10});
              }
           
          

*Note: If you want to just get things working while you update your app, please import the 'ojs/ojvalidation-number' and 'ojs/ojvalidation-datetime' modules in the main require call for your application. This will guarantee those modules will be available, the Validator/Converter classes are on the oj namespace and the existing app can work without modification. The downside is those modules will be loaded even if not needed instead of being pulled in lazily later.
If you do not import the appropriate deprecated modules or update your app to use the new modules (*recommended*) and create the validator and converter using its constructor, then you will see errors similar to below:

• ojcorebundle.js:621 oj.Validation.validatorFactory is not available and it is needed to support the deprecated json format for validators property. Please include the backward compatibility "ojvalidation-base" module.
• Error 'normalizedValidators[i].validate is not a function'
• oj.Validation.converterFactory(...) is null

New chroming attribute values for oj-button, oj-buttonset-one, oj-buttonset-many, oj-menu-button and oj-toolbar

The oj-button, oj-buttonset-one, oj-buttonset-many, oj-menu-button and oj-toolbar components are deprecating chroming values 'full' and 'half' and these will be removed in the future. The following new chroming values will be supported. Please use 'solid' instead of 'full', and 'borderless' instead of 'half'.

Additionally, a new chroming style, 'callToAction' will be supported by oj-button only.

Value	Description
'solid'	Solid buttons stand out, and direct the user's attention to the most important actions in the UI.
'outlined'	Outlined buttons are salient, but lighter weight than the solid buttons. Outlined buttons are useful for secondary actions.
'borderless'	Borderless buttons are the least prominent variation. Borderless buttons are useful for supplemental actions that require minimal emphasis.
'callToAction'	A Call To Action (CTA) button guides the user to take or complete the action that is the main goal of the page or page section. There should only be one CTA button on a page at any given time.

Deprecation of 'oj-button-primary' styling class for oj-button

The 'oj-button-primary' class was deprecated and will be removed in the future. Please use callToAction chroming instead.

oj-input-date, oj-input-date-time, oj-input-time, and oj-menu popup behavior change

Previously, oj-input-date, oj-input-date-time, oj-input-time, and oj-menu displayed their popups either modelessly or modally, based on the browser viewport width. Applications could override the viewport width threshold by setting SCSS variables.

This has been changed to base it on the type of device the application is running on, as determined by the new Config.getDeviceRenderMode API. Applications can override the device type by setting data attribute on the document body. Please refer to the documentation of Config.getDeviceRenderMode for details.

oj-list-view behavior change

Previously, changing the value of selection-mode attribute will have an effect on the value of selection/selected attributes. For example, changing selection-mode to 'none' would clear the value of selection/selected. This will no longer be the case going forward, as the selection-mode attribute should only affect how the user can select items, and not what the selection/selected value should be.

In addition, when the value of selected/selection is programmatically set by the application, the value should not be affected by the value of selection-mode. For example, if selection-mode is 'single', programmatically setting the value of selected/selection with more than one items should not be altered because of the value of selection-mode.

Component Metadata changes

• The styleClasses metadata property for describing CSS style classes associated with a JET Web Component has been expanded, and the old metadata format has been deprecated. The new metadata format allows for specifying individual style classes, sets of related items, and templates describing a range of available style classes. To learn more, visit the JET Metadata concept topic.
• JET Resource Components now support a publicModules metadata property that enables a JET Pack developer to provide public utility modules that can be independently imported into a JET application. To learn more, visit the JET Pack Metadata concept topic.

Avatar changes

Avatar now supports a background attribute that allows for customizing the background color of the avatar component.

API Changes

Constructor Functions Replaced By ES6 Classes

As part of our larger effort to embrace ES6, the implementations of the following APIs have been migrated from constructor functions to native ES6 classes:

• ArrayDataProvider
• ArrayTreeDataProvider
• CollectionDataProvider
• DataProviderMutationEvent
• DataProviderRefreshEvent
• DeferredDataProvider
• FlattenedTreeDataProviderView
• IndexerModelTreeDataProvider
• ListDataProviderView
• PagingDataProviderView
• TreeDataProviderView

For typical usages (eg. “new ArrayDataProvider()), this change will be transparent to application code. That is, in most cases, your existing application code will continue to work as is.

There is, however, an atypical use case that worked in previous releases but fails in 8.0.0: invoking the constructor function without using the “new” keyword. For example, both of these calls will fail in 8.0.0, as ES6 class constructors can only be invoked via new:

              const invokeConstructorDirectly = ArrayDataProvider(data, options);
              const invokeConstructorUsingCall = ArrayDataProvider.call(this, data, options);
            

The latter form is sometimes used in order to invoke a superclass constructor function when creating a subclass:

              var CustomArrayDataProvider = function(data, options) {
                  // Do not do this:
                  ArrayDataProvider.call(this, data, options);
              };
            

If the superclass is an ES6 class, this attempt to call the constructor without new will result in a runtime error of the form:

                Class constructor ArrayDataProvider cannot be invoked without 'new'
            

In theory, the fix for this problem is to port the subclass to an ES6 class and use the “extends” keyword to set up the relationship with the superclass. However, as discussed in the next section, our recommended fix would be to avoid subclassing altogether.

Final Classes

While this has not been explicitly called out in our documentation, our intention has always been that JET’s concrete classes (like the DataProvider classes listed in the previous section) should be treated as effectively final. These APIs have not been designed with inheritance in mind, and we have not spent time designing protected APIs to enable customization via subclassing. As a result, any attempt to create subclasses is inherently brittle and prone to unintentional breakage as our implementations evolve. Our preferred approach for extending the functionality offered by JET’s concrete classes is to use composition rather than inheritance.

Although neither TypeScript nor EcmaScript have language support for declaring classes as final, as of JET 8.0.0 our API doc now identifies classes that we consider to be effectively final. This includes the DataProvider-related classes listed above, as well as other concrete classes provided by JET. At the moment, there is no attempt to enforce finality at runtime, though this may change in future releases. In addition, the JET Audit Framework will soon flag attempts to extend final classes.

If you have use cases where you require the ability to extend a JET final class, please raise this with the JET development team and we will help find the best path forward.

Deprecated modules

The modules below were deprecated for performance reasons as they contained several validators and converters each which made them too big. This caused the application to have to include the whole module even if only one converter or validator was needed. The validators and converters have all been put into their own module now. You must import the new module to use its classes. This will prevent the loading side-effect issue. Also note that the old modules put their classes on the 'oj' namespace, whereas the new modules do not. Please read the Component Changes section titled 'ojvalidation-base, ojvalidation-number, and ojvalidation-datetime modules deprecated and removed from JET Components' dependency' for more details.

• ojvalidation-base
• ojvalidation-datetime
• ojvalidation-number

New modules

• ojconverter-color
• ojconverter-datetime
• ojconverter-number
• ojvalidator-daterestriction
• ojvalidator-datetimerange
• ojvalidator-length
• ojvalidator-numberrange
• ojvalidator-regexp
• ojvalidator-required
• ojasyncvalidator-daterestriction
• ojasyncvalidator-datetimerange
• ojasyncvalidator-length
• ojasyncvalidator-numberrange
• ojasyncvalidator-regexp
• ojasyncvalidator-required

Async validator modules

There are corresponding async versions of all our validators now. The benefit of the async versions of our validators is that the validator logic is not loaded until validate() is called or the hint is retrieved. This result in better performance because code is not loaded upfront.

ValidationFactory and ConverterFactory

oj.Validation.validationFactory() and oj.Validation.ConverterFactory() were deprecated because they relied on unstable module load ordering to work properly. The factory schemes created implicit dependencies in navigation order that could not be statically checked and therefore caused users to see runtime errors. For example, the application had to ensure that the registration APIs were called before the registered converters/validators were subsequently used. In practice, this was hard to ensure in a complex application and consequently, the APIs frequently did not work reliably. To obtain instances of converters and validators please import the appropriate module and then directly create the instance via new. Please consult the Validation demos for examples. In addition, registering custom converter/validator types via the above APIs is no longer supported. Doing so will now result in an error logged. For custom converters and validators please directly bind them to the component. To override existing converters or validators, please override the requirejs config. e.g. 'ojs/ojconverter-color' would map to a module which contains your converter override.

Validators' validate() returns void

All Validators' validate() method returns nothing if validate() is successful and throws an Error if not. In previous releases each Validator did its own thing; some Validators returned the same value you passed in, some Validators returned true. This was deprecated in version 6.2.0 in favor of consistently returning void for all JET Validators.

Filepicker layout and translation changes

The layout of the filepicker component has changed. The 'dropzoneText' translation will no longer be used and replaced with 'dropzonePrimaryText' and 'secondaryDropzoneText' translations.

oj-diagram API changes

The top level attributes listed below were moved under the new node-content attribute.

• renderer
• focus-renderer
• hover-renderer
• selection-renderer
• zoom-renderer

oj-form-layout API changes

The label-edge attribute has the following changes:

• Previously the label-edge attribute on oj-form-layout was solely used to determine the label behavior for the form controls. Now a label-edge attribute has been added to all form controls, the label behavior can also be determined by the form controls themselves.
• Previously the label-edge attribute on oj-form-layout has a default of "top". Now the default varies by theme. In the Alta theme, the default is still "top". However, if the application specifies an explicit value for it, it should also specify an explicit value for the label-edge attribute on the form controls.
• A new "inside" value has been added. In current release it doesn't do anything and simply delegates the label creation to the form controls. In future releases, it may be propagated to the form controls so that all label creations can be controlled from oj-form-layout.

Theme Changes

CSS Variables Update

The new Redwood UX Design system support (showcased at Oracle OpenWorld 2019) will likely be available in JET 9 and will support CSS Variables once available. The existing Alta themes will not support CSS Variables.

Sass Variable Changes

The following variables were removed:

• $avatarBorderOffsetBgColor
• $avatarXxsBorderOffset
• $avatarXsBorderOffset
• $avatarSmBorderOffset
• $avatarMdBorderOffset
• $avatarLgBorderOffset
• $avatarXlBorderOffset
• $avatarXxlBorderOffset
• $avatarInitialsShadeColor

The following variables were deprecated:

• $inputDateTimeRenderModeOptionDefault
• $selectRenderModeOptionDefault

Public Style Class Changes

oj-label-accesskey

JET's Accessibility team discourages accesskeys, so this styleclass has been deprecated.

oj-flex-items-pad

The oj-flex-items-pad class is deprecated. People found this class confusing, and it has limited applicability as it only controls a specific value of horizontal padding. The replacement is to place oj-sm-margin-2x-horizontal on the children/descendants where the padding was ending up.

Framework Changes

Library Changes

Required changes to support IE

The JET code is being modernized to take advantage of the JavaScript features of modern browsers. However in order for this code to work on IE11, the JET code is also provided transpiled down to ES5. The majority of Oracle JET applications will have to make the changes to support IE11.
There are two exceptions:

• Hybrid applications that only run on phones or tablets.
• Applications that use the CDN to access the JET code. The bundles-config.js takes care of the required changes.

Note: Please consider using the CDN. The performance should be better and the configuration is simpler.
Note: This modernization is for the core JavaScript language and not browser DOM APIs.

Web Apps that Bundle JET with r.js

If your bundles include JET library code, you should create two sets of bundles, one for modern browsers and one for IE11. The ES5 bundles must map ojs to the *_es5 directories and include paths to the 'corejs' and 'regenerator-runtime' polyfills. It must also exclude the fake module named 'polyfills'.

Changes needed to the require.config()

• Detect whether ES5 code is required.
  The UserAgent is used to detect IE11. Only IE11 requires ES5.

  function _ojIsIE11() {
    var nAgt = navigator.userAgent;
    return nAgt.indexOf('MSIE') !== -1 || !!nAgt.match(/Trident.*rv:11./);
  };
  var _ojNeedsES5 = _ojIsIE11();
                    

• Pick correct ES5 or ES6 JET code
  JET ES6 code will be found in the default directories. ES5 for IE11 is found the min_es5 and debug_es5 directories.

  requirejs.config({
    paths: {
      ojs: 'libs/oj/v7.0.0/min' + (_ojNeedsES5 ? '_es5' : '')
    }
  });
                    

• Add paths for polyfills
  Two polyfill libraries are required. One to polyfill the all of the ES6 runtime improvements. The second one contains runtime support for generator functions.

  requirejs.config({
    paths: {
      corejs: 'libs/corejs/shim.min',
      'regenerator-runtime': 'libs/regenerator-runtime/runtime'
    }
  });
                    

• Define polyfills require module
  Define 'polyfills' module to pull in the polyfills only on IE11.
  Note: if all of the application modules depend either directly or indirectly on the JET library, this define might not be required.

  if (_ojNeedsES5) {
    define('polyfills', ['corejs', 'regenerator-runtime']);
  } else {
    define('polyfills', []);
  };
                    

• Polyfill legacy promise module
  Previous versions used a standalone promise polyfill. The logic is now either supported directly by modern browsers or is a part of a larger polyfill for IE11. If any application modules have a direct dependency on the requirejs 'promise' module, it should be removed. If that is not possible at this time, Add this define as a polyfill.
  Note: if all of the application modules depend either directly or indirectly on the JET library, this define might not be required.

  define('promise', ['polyfills'], function () {
    Promise.polyfill = function () {};
    return Promise;
  });
                    

oj.js removed

The oj.js library that contained all the JET code for use outside AMD has been removed.

Updated versions

dnd-polyfill has been updated to 1.0.1

Knockout 3.5.0

As of the JET 7.0.0 release, JET requires Knockout 3.5.0. Although the Knockout version is not changing with JET 8.0.0, applications that are upgrading directly to JET 8.0.0 from pre-7.0.0 releases should be aware of these Knockout 3.5.0 changes:

• Knockout 3.5.0 requires that a non-null DOM element be passed in as the second argument to the ko.applyBindings() method. Previously, Knockout would tolerate null values for this argument.
• Knockout 3.5.0 requires balanced parens/brackets/braces in expressions. Previously, Knockout would tolerate unbalanced syntax in expressions.
• Knockout 3.5.0 is stricter about sharing observable instances across documents. Previously, Knockout would tolerate use of an observable that was created via one instance of Knockout by another instance of Knockout. This is no longer allowed.

Tooling Changes

Visual Studio Code Extension for JET Core

The VS Code extension for JET Core development has reached general availability! This extension provides support for code completion, code snippets, application audits, and much more. Now available from the Microsoft Visual Studio Code Extension Marketplace! Visit the Marketplace...

Known Issues

The following table calls out specific known issues, with workarounds where available.

Category	Bug #	Description	Workaround (if available)
iOS	N/A	JET hybrid mobile apps created using an earlier JET release may have additional spacing at the top of the page when deployed to iOS 11 devices.	Change the viewport meta tag in index.html to the following: <meta name="viewport" content="viewport-fit=cover, width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1.0, user-scalable=no"/>
iOS	N/A	Using the long press gesture in iOS Safari 13 may result in unexpected text selection in the page.	Users that run into this while interacting with a JET component should try modifying their gestures to avoid triggering a long press in iOS.
iOS	ios-sim 210	ios-sim version 5.1.0 may be installed locally by cordova-ios and serving the app to iOS simulator reports: "Error: Cannot read property 'replace' of undefined"	cd hybrid/platforms/ios/cordova; npm install ios-sim@latest
iOS	ios-deploy 275	Deployment to iOS device succeeds, but the app fails to launch and an error is reported in the terminal.	Upgrade to the latest version of ios-deploy (sudo npm install -g ios-deploy) and use a developer signing identity. Otherwise, launch the app manually on the device.
npm	npm 16901	npm version 5 does not install the oraclejet module when scaffolding a JET hybrid app and building the app reports: Warning: ENOENT: no such file or directory, open 'node_modules/oraclejet/package.json' Use --force to continue	[sudo] npm install -g npm@latest-4
Chrome and Safari on Touch	N/A	In some cases, dragging an object marked as draggable on touch devices may result in simultaneous scrolling of the containing page.	The issue is caused by changes in Safari and Chrome that now treat document level touch event listeners as passive. The workaround for the issue is to add an empty, non-passive 'touchmove' event listener to an ancestor of the draggable element. E.g. ancestorElement.addEventListener('touchmove', function(event){}, { passive: false });

Other v8.0.0 Notes

Specifying Child Content

A number of JET components allow child content to be specified in two ways:

1. Via inline HTML content
2. Via stamped content, driven by a DataProvider

Some examples of JET components that allow this include:

• <oj-checkboxset>/<oj-radio-set>: checkboxes/radios can either be specified either via inline <oj-option> child elements, or via the options DataProvider
• <oj-list-view>/<oj-navigation-list>/<oj-tree-view>: items can either be specified via inline <ul>/<li> child elements or via the data DataProvider.
• <oj-select-one>/<oj-select-many>: options can either be specified via inline <oj-option> child elements, or via the options DataProvider

The inline HTML approach is primarily used for static child content.

For cases where the child content may be mutated after the initial render, the DataProvider-based APIs are the best approach. DataProvider mutations are communicated directly to the consuming component, allowing the component to update its stamped child DOM in an efficient manner.

Note that for the static content case, it is possible to generate the initial child content using binding elements such <oj-bind-for-each>. However, unlike with DataProviders, binding-based mutations to the children are not communicated to the parent component. As such, using the component's DataProvider-based APIs should be preferred.