Technical Articles relating to Oracle Development Tools and Frameworks

  • JET
    January 23, 2017

JET Custom Components I - Backgrounder

Duncan Mills

Last Updated Jan 2020 for JET 8

Over the following series of articles I'll be describing the Custom JET Component Architecture, showing how you can create your own components to boost re-use and generally streamline your code-base. However, before we dive into the technicalities I think that it would be a good idea to set the scene a little and provide you with some background.

What's The Point Of A Component Model?

Before we even start, it's worth asking this question, after all, we're already dealing with a nicely structured and standardized language in the form of HTML markup. Isn't adding our own components kinda going against the whole idea and a retrograde (and therefore bad) step?

Simply put no. The need for a custom component model within HTML is well established and as such is the subject of a W3C initiative under the umbrella of Web Components. However, as is often the way of these things, the specifications are as yet (at the time of writing), not fully complete and ratified and we're in a situation where browser support is incomplete as a result (see here).

If you want to learn about Web Components in a slightly more accessible way than W3C Specifications then there are plenty of good sites out there. A good place to start, however, is webcomponents.org.

OK But I Still Don't Get Why I Might Find It Useful...

Fair enough, why is it useful? Well it's all to do, with the original intended use for HTML verses what we actually use it for. HTML was designed to markup text documents that deliver content and images for consumption and provides all of the useful semantic tags to do document-y stuff like defining headings at various levels, paragraphs, footers navigation to other documents and so on. However we're mostly not using it for that, at least, not in the context of a typical JET application, we're generally building interactive Applications not just authoring content to read. We'll still use many of those tags but the core of our code is going to be a whole set of nested <div> elements with various classes applied to lay things out and apply a certain UX over the top. If you take the simple case of an input field and it's associated label you might have some code a little like this:

<div class="oj-flex">
  <div class="oj-flex-item">
    <label for="control1">row 1</label>
  <div class="oj-flex-item">
    <oj-input-text id="control1" value="{{somevalue}}" required="true"></oj-input-text>

In this example, although we're using the standard HTML elements for providing a label and an input field we've got no less that three <div> elements cluttering up the markup just to perform the layout housekeeping. Now this of course is a very simple example and in reality, the number of housekeeping / control divs in your view can easily creep up into the hundreds. Frankly it's just hard for us to read and mentally parse.

Imagine instead the same content in our view was represented as something like the following:

<my-input input-value="{{someValue}}" input-label="row 1" required="true"/>

I think that we can all agree that this is really much easier to understand when you just read the page! (OK this is a contrived example because the <oj-input-text component already does all of this but you get the point!)

Of course componentization is not just about making the elements in your views easier to read. It provides the mechanisms for enforcing standardization of UI and behavior, reducing the complexity of your day to day development efforts (build and test once, use many times) and of course you have the ability to change the component in one place and have that change automatically reflected by all the consuming pages.

A final key point about the importance of Custom JET Components in particular is that they are positioned as the standard mechanism for plugging into the Oracle ecosystem. Once you have created a component, not only will you be able to use it directly in your JET applications, but also in our low-code development tool, Visual Builder Cloud Service, and use them to extend our SaaS applications. (usual caveats apply with respect to the truthfullness and timing of this statement). As such, mastery of Custom JET Component creation will be a key skill-set for Oracle UI developers and partners going forward.

What Next?

So now that we've established that there is some value in introducing some sort of componentization into our developments we can proceed, in subsequent articles, with learning how to do this using JET .

To get you started, go and have a look at the demos in the cookbook for this feature area. These, along with the JS doc provide some great examples of composite components in action, starting with basic demo.

Screenshot of Basic Composite Component demo from the cookbook
Figure 1: A screenshot from the Basic Composite Component Demo in the JET Cookbook

If that all looks a little scary and confusing though, don't worry, in the following series of articles I'll be taking you through Custom JET Components step by step, from the very basic, almost code-less components to advanced usages, exploration of the nuances of lifecycle and more.

A Summary of What Custom JET Components Give You

As you progress through this series you will pick all this up, but to summarize for you now, JET Custom Components give you:

  • A way to define custom HTML elements for use in your application, providing:
    • Custom attributes for the element
    • Custom methods on the element
    • Custom events emitted from the element
    • Function callbacks
  • An encapsulation of all the resources needed to create this tag / element:
    • Template HTML markup
    • JavaScript to drive the component
    • Styles to configure the UX
  • Support for nesting of components
  • Support for injection of application markup into the component (a feature called slotting which I'll discuss in detail in a later article)
  • Lifecycle methods to control the component

But Before You Start...

Throughout this series of articles I'll be assuming a certain baseline skillset, mainly, but not restricted to, RequireJS and JavaScript promises. So if you've not mastered those concepts yet, you would be best to hold off diving into creating components until you are comfortable with those pieces. I'll also assume that you're familiar with using JET itself of course. With that, if you are ready then proceed to Part II to look at some of the basics.

JET Custom Component Series

If you've just started with 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 Learning Path

Join the discussion

Comments ( 2 )
  • guest Wednesday, January 25, 2017

    Hi Duncan,

    With component model approach, would Oracle eventually offer a declarative style of building web pages with JS?

  • Duncan Wednesday, January 25, 2017

    We already do - that's the Application Builder Cloud Service


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.