npx dockerize-npm-module

Thinking aloud on challenge I am facing as JS developer.

Problem: NPM-based projects often require specific dependencies versions installation and version tune up which is 

  • time consuming ( curse of node-gyp or sass )
  • could mess up machine environment for other projects. 
Such dev and build dependencies could be pre-configured and jailed within docker image exposing only input/output folders and working ports on developer's machine.  

GitHub and other code management repositories are given ability to run continuous integration (CI) steps as Docker container actions

Those actions could be run as part of CI during deployment but also locally to prevent aforementioned problems. 

Solutionhttps://github.com/nektos/act - locally installed "act' app.

PROS: almost complete CI/CD cycle coverage. 

CONS: requires installation and ? per-project tune-up.

Proposal: npx dockerize-npm-module [NPM_SCRIPT_COMMAND]

Seamless as non-installable CLI to run all package.json commands in preconfigured image for docker container.

+ config generation/load

? reuse GitHub container actions  

+ upgrade package.json with safe:xxx scripts meant to run same NPM commands in docker container or add docker CI/CD steps. 


HTML5 SLOT tag for content management explained

Web Components stack includes efficient and well thought through templating solution with TEMPLATE and SLOT tags. While those have been widely adopted in web components world for multiple reasons, the shadow DOM behind of this tech prevents to use it in environments where UI styles managed separately and often driven by heavy legacy content: while styling in shadow DOM has own perks like css insulation, it does not work well with global css styling. 

I would suggest to utilize the concept of slot in template  in content management environments with classic css use. You could implement the convention by yourself with showing/hiding the slot with name  

el.querySelector('slot[name="final"]').hidden = false;

To avoid the UI flickering , make sure the initial HTML includes the visibility state meant to be shown before JS is able to act:

<slot name="initial">Please wait while loading...</slot>
<slot name="final" hidden> initially is hidden, filled by JS and then shown </slot>


NOTE. The hidden attribute behavior is self-explanatory and works out of the box, no need for CSS. But if your environment is a CMS like Adobe AEM, Liferay, or Drupal, the CSS on the page is most likely a product of multiple people/teams over the years. Here the default behavior could be tricked by different CSS rules and you would need to elevate:
slot[hidden]{ display:none!important;}

Of course the page level javascript and HTML would limit only one slot name a time. Wrapping slots combinations into identifiable by JS container would help to handle multiple UI components with same kind of UI pattern(template). Like the avatar in the list and in profile UI. 

The most convenient way to connect JS and HTML element is a custom element, i.e. Web Component with own tag. `this` in its methods would point to html element of own tag which would be triggered every time the tag appear in HTM, initially or dynamically later. In CMS it would prevent the messing with page, document, and script load handlers, a huge win for code maintenance when the code is spread across developers/teams and time.

Web Component does not dictate the use of ShadowDOM and allows to pick any way of template implementation. There are multiple "frameworks" with opinionated ways of templates handling. The HTML content meant to be handled by middle tier in classic CMS. Where the templates also play important role in content lifecycle. Adding another templating engine is not just increasing the complexity but also created the conflict between different approaches and handling the content variations like multi-lingual support or cohort targeting.  Hence ability to reuse the CMS HTML capabilities along with template/slot concept would be most beneficial.

As CMS usually is not designed to serve the dynamic data, the fusion of externally served data and UI from CMS becomes a data plumbing task on UI tier. During this "data plumbing" process the UI should support multiple states including initial waiting, loading, error of multiple kind, and final with rendered data, perhaps with variations on data internals.

slotted-element comes handy for eliminating the coding for data plumbing in simplest cases and simplifying the programming otherwise. 

Here this custom element is a sample for typical data plumbing to CMS driven HTML tasks.

  • switch between slots to be shown. Hide all, display only one. 
  • clone slot content to be filled with data
  • add customized slot. Could be more than once for list.
  • data retrieval layer: url/method/headers/body, status, error handling, fetched data conversion.
  • UI sub-elements access and manipulation convenience methods.

Whether you choose to use slotted-element, extend it, or decide to create own, keep in mind the list ^^. 


Using templates and slots


XSLT 1.0 in-browser Q&A

  • How to get XSLT path from within XSLT?

<xsl:value-of select="substring-before(substring-after(/processing-instruction('xml-stylesheet'),'href=&quot;'),'&quot;')"/>

XML: <?xml-stylesheet type="text/xsl" href="../AsTable.xsl" ?>

Gives: ../AsTable.xsl

  • How to get relative URL of  specific XSLT from XML?

<xsl:value-of select="substring-before(substring-after(/processing-instruction('xml-stylesheet'),'href=&quot;'),'AsTable.xsl&quot;')"/>

    Gives: ../

    • How to get Javascript URL relative to XSLT applied to XML as processing instruction?
    <xsl:param name="baseUrl" select="substring-before(substring-after(/processing-instruction('xml-stylesheet'),'href=&quot;'),'AsTable.xsl&quot;')"  />
    <script type="module" src="{$baseUrl}XmlView.js">/**/</script> 

    Gives: ../XmlView.js

      • list of unique children tags (each last)
      *[ not( name() = name(following-sibling::*) ) ]
      • how to output XSL from XSL
      Add namespace with altered URL, namespace-alias, use the namespace in output:
      <xsl:stylesheet version="1.0"
      * get entries for table presentation and
      * fills in xsl:template mode="DisplayAs" for each
      <xsl:output method="xml" />
      <xsl:namespace-alias stylesheet-prefix="xvxsl" result-prefix="xsl"/> ...
      <xvxsl:template mode="DisplayAs" match="{$xPath}">
      • how to debug XSL? 
      Currently the most convenient way is given by Visual Studio Pro edition. Trial available.


      Semantic Theming - indexed palette

      There are many articles on palette categorizations online, I would skip to semantic relation of palettes to UX elements. 

      Usually palette is selected from basic branded colors base. Usually 2 or 3 is sufficient, perhaps it relates to the heraldic symbols and colors. Remaining colors are chosen with keeping the base ones and emotional palette in mind. 

      There is a catch on selection enterprise and government designs are facing: color set should be "accessible" for various cohorts of people: color blind, light sensitive, etc. Adobe has given a nice tool to help with accessible palette creation. In regards to color "accessible" means that close colors should be distinctive enough even for people with color challenges or in applicable conditions of low/bright light.

      The palettes would have various colors but some of them have to be in straight color transition like bright to dim. Why you would need a color sequence? The answer resides in various states UX component are presented during interaction with UI. Those states are used in sequence: normal follows hovered, which followed "active"(pressed) , the disables should be least noticeable and resides in the end of color sequence. See Buttons and Actions states

      How many color sequences you would need? It depends on how many color variations your application supports: light, dark, high contrast for each, grayscale for ePaper devices, etc. Another factor is munber of variations for UX components. As in Buttons and Actions there are 5 variations proposed, will be more for other types of UX components. Each need to have own entry in one of indexed palettes. 

      While same palette could be reused for different UX components variations, it is better to choose a significantly distinctive different entry point in palette for inside of same color theme variation. 

      For UX components single palette is not sufficient. The indexed palettes usually come in more than one color per row. You would need to make colors as for background as foreground/text, for outline, and for other sub-elements. For action it would be 3 colors: background, text, outline/border. The 4rth is assumed to come from theme variation background which is a basis for selecting proper entry within indexed palette. In this sample you could see the need to alter the text color due to background change:

      Now to the meat of subject. The indexed palette become semantic when one of its entries is associated with one of semantic UX element variation. 

      Semantic theming - buttons and actions states

       While W3C button attributes and CSS has given straight forward combination of possible appearance of actions/buttons, not all have a "semantic" meaning for the user. There is a proposal for state sequence in colors escalation order ( see indexed palette article ).

      NORMAL  (default)

      FOCUSED  :focus css selector

      SELECTED attribute on some elements like OPTION 

      HOVER  :hover

      ACTIVE :active

      DISABLED attribute, not available on A element

      Not all states would affect background and not on all action variations: focused is usually leaves the current appearance with outline, in ghost variation the background by default would be transparent still for accessibility reasons keeping palette changes for other states.


      CDN deployment for JS modules - missing pieces

      There are multiple CDNs which support mirroring the NPM and GitHub sourced modules. They support the semantic versioning of your modules and a bit of additional services for modules owner. The services for web developers at the moment are quite limited and need to be extended in order to support modern web application development and delivery stack. 

      From security point we need assurance of content genuity  which is supported by resource integrity attribute , sufficient to replicate the binary build log, cross-reference to versioned source location. 

      The security scan reports from one or several vendors is essential for keeping the publicly reused code safe. Publishing security scan reports along with binaries would enable transparent review across all modules used in the page without exceptions making 100% coverage as for own content as for dependencies from 3rd parties.

      Test coverage is a significant criteria  of application reliability. In the world of Web 3.0 where apps from different vendors are met on same browser page the page owner does not have any assurance on quality of service overall unless able to review test coverage for all including 3rd party code. By deploying versioned binaries on CDN along with complimentary test coverage report the web application owner and consumer will acquire ability to check and if not satisfied to eliminate/substitute unreliable versions. 

      Licensing transparency.  While legal reuse and re-distribution questions are  boring and complex, publishing the licensing info along with published on CDN binaries would give ability to check whole dependencies tree on subject of (in-) compatible licensing of whole dependencies tree. That would be important for applications vendors, corporate consumers and final users who do not want to support pirating.

      Developers support. When dealing with binaries it is difficult to troubleshoot the internals of published in CDN module. The source map could be published on CDN next to binaries to help the development community and clients who are willing to troubleshoot themselves.  The original source version is also a subject to be mirrored on CDN.

      Build stack with target of CDN publishing would eliminate the need for keeping dependencies in bundles making the build lighting fast as dependencies and own code which already published on CDN does not need to be recompiled/verified/published.

      My goal is to support above features and make given stack available for applications developers.

      Cross-posted on Patreon


      Data layer development via ORM and API Gateway

      Not sure what pushed me to this direction but search "DB with graphql" lead to https://www.prisma.io/ - a tool for auto-generation GraphQL endpoints for DB schemas without programming. Open Surce, Apache 2 licence, MySQL/PostgreSQL capable.

      Prisma is a next-generation ORM that can be used to build GraphQL servers, REST APIs, microservices & more. (222 kB)

      For me DB-first approach is essential . The schema change is reflected in code just by re-generating code by CLI, no coding involved. Of course the discipline of migration for DB schema itself is still in place.

      And last peace of back-end puzzle: ORM integration with API gateway( will serve security, authentication, licensing, analytics ) : Prisma + Apollo https://www.howtographql.com/graphql-js/5-connecting-s

      The generated classes out of DB schema could(and should) be reused as on back-end as in front-end code via versioned (npm?) package.