Adding esbuild script for plain javascript integration

[dinukadesilva]

This introduces the following variable that will be created with default values, which are optional. The index.jsx file will check if ACCESS_CI_UI_CONFIG is defined, and if so, it will generate components based on the configuration. For this functionality to work, the minimal object for ACCESS_CI_UI_CONFIG should be at least {}.

window.ACCESS_CI_UI_CONFIG = {
      universalMenus: {
        loginUrl: "/login",
        logoutUrl: "/logout",
        siteName: "Allocations",
        targetId: "universal-menus"
      },
      header: {
        siteName: "Allocations",
        targetId: "header"
      },
      siteMenus: {
        items: siteItems,
        siteName: "Allocations",
        targetId: "site-menus"
      },
      tableOfContents: {
        headings: document.querySelectorAll("#body h1, #body h2"),
        targetId: "table-of-contents",
      },
      footerMenus: {
        items: siteItems,
        targetId: "footer-menus"
      },
      footer: {
        targetId: "footer"
      }
    }

[yomatters]

@dinukadesilva, thanks for putting this together! I'm not sure using a global configuration variable is going to work in all cases, because often we want to render just a subset of the components (e.g., if the page doesn't have a table of contents). I think it would be more flexible to just expose all the render functions on a global object. Here's what I'm thinking we can do:

1. Add this step to the build process to generate a non-module build with the global name AccessCiUi:

npx esbuild ./dist/access-ci-ui.js --bundle --minify --outfile=./dist/access-ci-ui.esbuild.js --global-name=AccessCiUi

2. Update the readme to provide these instructions to modify the example for non-module deployments:
   a. Remove type="module" from the <script> tag.
   b. Add a new script tag before the current script tag to load the global AccessCiUi object:

   <script src="https://unpkg.com/@access-ci/[email protected]/dist/access-ci-ui.esbuild.js"></script>

   c. Replace the import statement with an assignment that destructures the global AccessCiUiobject:

   const {
     footer,
     footerMenus,
     header,
     siteMenus,
     tableOfContents,
     universalMenuItems,
     universalMenus,
   } = AccessCiUi;

Does those changes seem like they would address the need?

[dinukadesilva]

@yomatters Actually, even const and object extractions still do not support all browsers, at least not legacy versions. So, the intent here is to support those. So, I would not agree about replacing it with an import.

However, I just made a commit that would allow the generating of a subset of components. So that it will create components only for those defined in the configuration. The minimum value for each component is either {} or true.

[yomatters]

Thanks @dinukadesilva. Most major browsers have supported the features you mentioned since at least 2016. Very few modern websites are going to work well on web browsers that old, so I'm not sure we need to be too concerned about supporting them.

That said, we can easily change the instructions for non-ES deployments to avoid using const or object destructuring:

var footer = AccessCiUi.footer;
var footerMenus = AccessCiUi.footerMenus;
var header = AccessCiUi.header;
var siteMenus = AccessCiUi.siteMenus;
var tableOfContents = AccessCiUi.tableOfContents;
var universalMenuItems = AccessCiUi.universalMenuItems;
var universalMenus = AccessCiUi.universalMenus;

I'd prefer not to add logic to the library to deal with a global configuration variable if we don't have to, since it's another thing that will have to be updated whenever new components are added. It's also not a typical pattern for JavaScript libraries as far as I'm aware. (Usually functionality from a library is activated by calling functions provided by the library, not by assigning a global configuration object.)

Let me know if that approach sounds okay. Thanks!