Web Components

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps.

In 2021 we rewrote Responsive UI using a standards-based technology called web components. We’re offering the new web components library as an alternative to the Angular component library. We’re very excited about this move since web component technology opens the door to Responsive UI being used in web technologies other than Angular (as well as in Angular too).

For now, the new web components codebase is separate from the Angular component codebase that we’ve been building over the last several years. We will support both the older Angular components and the new web components. The web components have the same look and feel as the Angular components, with a similar API.

In 2023 we will convert the existing Angular components into thin Angular wrappers around the web components. These wrappers will act as a thin translation layer between the API you’re using today and the new web component API. This will get us down to one primary codebase (web components) with a much smaller secondary codebase for the Angular wrappers, which will help us keep the two in sync more easily. We will work closely with your teams to ensure that these wrappers provide existing Responsive UI products with the same functionality, with minimal change from before. We will keep you posted on this progress and will be asking for volunteers who want to help us test this.

This web components project is a technology shift, but it also opens up some exciting new opportunities for us:

• While the Responsive UI web components fully support Angular apps, they also work in other modern web technologies other than Angular. This provides an opportunity for teams who are more versed in other web development technologies to use Responsive UI without having to learn and use Angular.
• This removes our dependence on a single framework. Web components technology is standards-based, is supported in all modern browsers, and does not require dependence on any one framework.
• We removed all dependencies on Bootstrap and jQuery when we built the web components codebase. We originally built Responsive UI on top of Bootstrap 3 — essentially “paving over” Bootstrap — which generated quite a bit of bloat.
• The web components codebase was a complete rewrite of all the code we had before. This rewrite allowed us to fix some bugs and remove bloat from the CSS. It also provided the opportunity to fix some visual styling inconsistencies. The end result is leaner and cleaner code with more consistent and legible visual styling.
• We’ve rewritten some of the 3rd party components as Jack Henry components. This will allow us to provide enhancements to these components that were not possible before, as they were built by third parties.
• The theming support in the web components codebase uses CSS variables, an approach that opens up some really cool possibilities in our theming.
  • Before, we published CSS classes that applied atomic values in our theming (think individual colors, sizes, spacing) to specific CSS classes.
  • With CSS variables, you’ll be able to apply atomic themed values (say an individual color) to anything.
  • This opens the door to more product-level theming of elements, including new one-off third-party elements you might want to incorporate into your applications.

Do the web components look and feel different from the Angular components?

For the most part, the Responsive UI web components look and behave the same as their Angular component counterparts, although we did make a handful of minor cosmetic improvements in the web components.

The primary differences are in their internal implementation. The web component API is a little different from the Angular component API, but very similar.

You can play with the new web components in the Responsive UI Angular Web Components sample app.

Wait, we followed you over to Angular and now you’re moving away from Angular?

We are not removing support for Angular. We’ve grown a community around Angular development here at Jack Henry and that isn’t going away. The new web components work in Angular just like the Angular components. You can consume these web components directly from an Angular application, and the Angular wrappers we’ll be building in the future will work in Angular too.

So, we are not moving away from Angular, we’re just removing Angular as a requirement for working with Responsive UI, which is a healthier place for us to be.

How does all this affect me and my team?

For now, there is no change for you, unless you’re interested in testing out the new web component version of Responsive UI. We will keep you posted as we work through the Angular wrapper story.

What are my options for Responsive UI components?

You have 3 options for accessing Responsive UI…

The “AA” option

• Angular application + Angular components
• Your app is built using the Angular framework and uses the Responsive UI Angular components, importing the jharesponsive npm package. This is the model most of you are using today.
• Today, these are the same Angular components we’ve been building over the last several years.
• In 2023 we’ll convert these Angular components to thin Angular wrappers around the new web components, with a goal of minimizing disruption to existing products.

The “AWC” option

• Angular application + Web Components
• Your app is built using the Angular framework and uses the Responsive UI web components, importing the new rui-wc and rui-angular npm packages.

The “XWC” option

• Non-Angular application + Web Components
• Your app is built using a technology other than Angular and uses the Responsive UI web components, importing the new rui-wc npm package.

What about third-party support?

Responsive UI is currently about 80% Jack Henry-built components and 20% third-party components. There are certain components (say a data grid) that we would never want to reinvent ourselves. Our support for these third-party components involves creating CSS to style the third-party elements and inclusion in our sample application and our development documentation.

Responsive UI — whether you’re using the Angular components or using the web components — still provides the same styling and documentation support for third-party components as before.

Our CSS variable-based theming makes it easy for you to extend the Responsive UI theming to any elements, including components that you create and third-party components not officially supported by our team.

We’re planning to rewrite our XYZ module soon, which approach should we use?

This is completely up to you and your team.

If you’ve already written Angular applications using the existing Responsive UI Angular components, you can continue to use the Angular components, or you can start using the web components in new development.

If your team has not been using Angular and has a core competency in a different web front-end technology — or if you know Angular and want to work directly with the web components — you may want to consider using the web components for your new development. So far, we’ve only worked with consuming the web components in an Angular application, so there are a few things that haven’t been tested yet in other technologies, but this should be a viable path. Talk to us if you’re interested in this option.

Of course it’s impossible to predict the future, but the new design system will likely take years to design and build. The team building this is starting with the consumer-facing patterns used in the Banno products. You can wait for this option, but it will likely be some time before there’s much for enterprise teams to use. The most likely outcome at this point is the new design system will trickle in new components over the next few years. We’ll be focusing on (a) how to package these generic components to have the same look and feel as Responsive UI and (b) how to pipeline these new components into your applications with minimal disruption.

Can I mix Responsive UI Angular components and web components in the same app/view?

Absolutely. Both act as custom HTML tags. The Angular components use “jha-” as a tag prefix while the web components use “rui-” as a prefix (e.g., jha-record-detail vs rui-record-detail). HTML doesn’t support namespaces, so we had to use different tag names so both types of tags could be used in the same app/view.

How do the web components differ from the Angular components?

The Responsive UI web components provide the same functionality, look, and feel as the Angular web components. Here are the differences between the two:

• The web components are implemented differently internally. We used Angular to build the Angular components and LitElement to build the web components. Regardless of that, you should be able to use the web components in any modern web front-end technology.
• The Angular component tags use a prefix of “jha” while the web components use a prefix of “rui”. We had to use different prefixes so the two different sets of components could coexist.
  • This is important for you at the product level so you can mix the 2 types of components equally in your apps.
  • It’s even more important for the Angular wrappers since they wrap the web components.
  • For example, we couldn’t have an Angular wrapper named jha-display-block that wrapped a web component of the same name, since the browser wouldn’t know how to resolve two different components that have the same tag name. So instead, the jha-display-block Angular wrapper will wrap the rui-display-block web component, providing a built-in translation between the 2 component interfaces.
• The Angular components prefix all component properties and events with “jha” to avoid collisions with other property names. The web components drop this prefix convention.
  • For example, the button style property in the Angular jha-button component is named jhaButtonStyle, but the same property in the rui-button web component is buttonStyle.
  • This practice did result in a few naming collisions, but we stuck with it. For example, some of the Angular components have a jhaTitle property. Removing the “jha” prefix results in that property being just “title”, which collides with the HTML “title” property (used to specify a tooltip for an element). In those cases, we had to change the property name more, so we used “titleText” for those properties in the web components.
• We were able to combine some related Angular components into a single web component in some cases.
  • For example, today we have separate components for toolbars, depending on their location: jha-function-toolbar, jha-function-toolbar-right, jha-display-block-toolbar, jha-display-block-toolbar-right, and jha-group-box-toolbar.
  • We were able to collapse that down to a single rui-toolbar component in the web components. You specify where that component displays using a separate “slot” property on the component.
• Angular supports two-way binding for components that have properties whose state can change internally within the component, such as input elements. Two-way binding isn’t supported in JavaScript; it’s just a convention within pure Angular components. So any web components that maintain state internally require 1 extra line of code to sync the component’s value with the backing value in your app.

As an example, here’s a snippet from a view using the Responsive UI Angular components:

<jha-function-view jhaTitle="Record Detail">

    <jha-function-toolbar-right>
        <jha-button-group class="jha-hidden-phone" [(jhaValue)]="recordDetailSpacing"
            [jhaOptions]="recordDetailSpacingOptions" 
            (jhaValueChange)="recordDetailSpacingChange()"></jha-button-group>
        <jha-toolbar-separator class="jha-hidden-phone"></jha-toolbar-separator>
        <jha-button jhaText="Record Detail Pattern" class="jha-hidden-phone" (jhaClick)="openPattern()">
        </jha-button>
    </jha-function-toolbar-right>

    <jha-display-block>

        <jha-record-detail [jhaIsFullWidth]="recordDetailContainerIsFullWidth">

            <jha-record-detail-block [jhaWidth]="recordDetailSpacing">
                <jha-record-detail-subheader jhaText="Customer Information"></jha-record-detail-subheader>
                <jha-record-detail-field jhaLabel="Name">Nancy Davolio</jha-record-detail-field>
                <jha-record-detail-field jhaLabel="SSN">111-22-3333</jha-record-detail-field>
                <jha-record-detail-field jhaLabel="Birthdate">04/01/1976</jha-record-detail-field>
                <jha-record-detail-field jhaLabel="Active Customer">Yes</jha-record-detail-field>
                <jha-record-detail-field jhaLabel="Interest Rate">8.750%</jha-record-detail-field>
                <jha-record-detail-field jhaLabel="Employer">Vandelay Industries</jha-record-detail-field>
                <jha-record-detail-field jhaLabel="Gross Income">$65,000.00</jha-record-detail-field>
                <jha-record-detail-field jhaLabel="Relationship Level">Silver</jha-record-detail-field>
            </jha-record-detail-block>

And here’s a code snippet for the same view, using the Responsive UI web components:

<rui-function-view titleText="Record Detail">

    <rui-toolbar slot="function-toolbar-right">
        <rui-button-group [value]="recordDetailWidth"
            (rui-button-group-value-change)="recordDetailWidth = $event.detail" class="rui-hidden-mobile">
            <rui-button-group-option value="narrow">Narrow Width</rui-button-group-option>
            <rui-button-group-option value="medium">Medium Width</rui-button-group-option>
            <rui-button-group-option value="wide">Wide Width</rui-button-group-option>
            <rui-button-group-option value="full">Full Width</rui-button-group-option>
        </rui-button-group>
        <rui-toolbar-separator context="function" class="rui-hidden-mobile"></rui-toolbar-separator>
        <rui-button text="Record Detail Pattern" class="rui-hidden-mobile" (rui-click)="openPattern()">
        </rui-button>
    </rui-toolbar>

    <rui-display-block>

        <rui-record-detail [width]="recordDetailWidth">

            <rui-record-detail-block>
                <rui-record-detail-subheader text="Customer Information"></rui-record-detail-subheader>
                <rui-record-detail-field labelText="Name">Nancy Davolio</rui-record-detail-field>
                <rui-record-detail-field labelText="SSN">111-22-3333</rui-record-detail-field>
                <rui-record-detail-field labelText="Birthdate">04/01/1976</rui-record-detail-field>
                <rui-record-detail-field labelText="Active Customer">Yes</rui-record-detail-field>
                <rui-record-detail-field labelText="Interest Rate">8.750%</rui-record-detail-field>
                <rui-record-detail-field labelText="Employer">Vandelay Industries
                </rui-record-detail-field>
                <rui-record-detail-field labelText="Gross Income">$65,000.00</rui-record-detail-field>
                <rui-record-detail-field labelText="Relationship Level">Silver</rui-record-detail-field>
            </rui-record-detail-block>

What’s next?

Please post any questions or comments in the Responsive UI team’s General channel and we can respond to them there. If there’s a lot of interest and questions, we can also schedule an open meeting to answer these for everyone.

Stay tuned for more updates from us as we progress through the different facets of this project.

Our next areas of focus will be:

• Supporting product teams as they begin migrating existing products and building new products using the AWC model for Responsive UI.
• Finishing the Angular wrapper conversion, working closely with you all to ensure that this migration goes smoothly.
• Continuing to support Responsive UI as we are today.

If you’re interested in playing with the new Responsive UI web components, we’ll have full documentation and a dedicated AWC sample application that will help walk you through this. Contact Jim Honeycutt for more details.

Also, let us know if you’re open to testing any of this, whether that’s testing the web components directly or testing the Angular wrappers as we develop them. We need to make sure we get all of this tested in as many environments as possible; your involvement in this testing can help make a huge difference for all of us.