deploy cloud run service

Getting Started

to get web components working include the component library
warning : 95% stable

mod

the component.js library exposes a mod object, which holds as its keys the component modules, the key is either the element nodename, or its id, the id can be used when the page contains multiple of the same component

var editor = mod['web-editor']; var editor2 = mod.myEditor;

the [ component ] attribute

any elements with a [ component ] attribute will be treated as a web component module

this example demonstrates the web-editor ext-code.com

Boiler Plate ?hdr

Many of the official components, at this time, require some boiler plate code, mainly small dependencies.

http://libs.ext-code.com/js/dom/component/v3.0/component.js?hdr
adding the ?hdr search parameter automatically sets up the default boilerplate, which for most of the official components is all that is required.

When the ?hdr parameter is used, after component initialisation is complete, a user function is called. This function can can be named any of these names :

  • mod.onReady()
  • mod.onready()
  • mod.ready()
  • mod.start()
  • onReady()
  • onready()
  • ready()
  • start()

Here is a simple example that includes the web-console ext-code.com

The code for a component, note :

  • The function that defines the module is wrapped in parentheses () making it a function expression, this is required. (function({mod,host}){ })
  • The arguments to the function ({mod,host}) :
    • mod
      The modules own namespaced component module reference.
    • host
      The root element of the component.
  • The function defines an object that is returned, note : the variable name obj, is purely an internal reference. var obj = { version : 'v2.0' };
    return obj;
  • Any methods and properties that are exposed to the public are added as properties to the obj :
    obj.initmod = function(){} obj.init = function(){} obj.initdom = function(){}

Skeletal function definition :

A typical component / module lifecycle might have :

  • initmod
    This is where local depencies can be passed to the component
    They fundamentally should not be relying on global state to receive their local depencies, this method is not always needed.
  • init
    This is the first entry point to the component, it is an asynchronous function that allows the component to check that it has everything it needs to run, including access to the network to load resources it may need.
  • initdom
    This is where the component is able to set up its ui / dom, internally build live references to run effeiciently, it can be asynchronous.

Components are also effectively namespaced so they are free to load any other components that they may need without having to worry that there will ever be a clash of variables or tag names.

View the full list of components
html component list

View the component.js library documentation and api
component library

Here is a very simple component

and the code to include it

It is entirely possible to have components that do not adhere to the above standard lifecycle :

and the code to include it

Here we have to give the component.js library a chance to load and build the component, mod.stack[] is an array of functions that get run when the component.js library has finished initialising. Also an init function will automatically be called.

The trouble with this approach is that as web pages and components get more complex, they start relyng on co-depencies, or they require the same resources that can potentially be loaded multiple times. The standard lifecycle is a way out of that. Often the component itself needs to load resources to be able to run, the component.js library provides a mechanism to ensure that all components on the page are loaded and available.

Note also that the only way here to access properties and methods of the component is to add them to the host element itself ( this is the way custom web-elements behave ), this is a problematic approach.



The component library just needs to be included as a script tag, it exposes a global property mod, it runs on window.onload, it has a loading stack that allows initialisation to be delayed until the asynchronous loading is complete.



Here is a simple setup that loads the log-mod element. Its function is to log toaster style messages in a webpage.

here is an example of a standard web components
this went some way as to introducing the ability to include complex functionality into web pages, i feel however it fell short on a number of issues i have solved with my component.js library, these are
  • elements were scoped to the global namespace, always a problem when functionality gets ever more complex its only a matter of time before clashes occur
    there is the proposal of
    var registry = new ComponentRegistry();
    but its still some time away
  • methods and properties associated with the component were added to the host node of the element, again thats ok for simple components, but when components get ever more complex its going to be a problem
class newElement extends HTMLElement { constructor(){ super(); var root = this; }//constructor connectedCallback(){} disconnectedCallback(){} static get observedAttributes(){} attributeChangedCallback(name,oldValue,newValue){} adoptedCallback(){} render(){} // A getter/setter for a disabled property. get disabled(){} set disabled(){} // A getter/setter for an open property. get open(){} set open(){} }//class