IDEA: V1 FINAL PATCH

[ghost]

A thought for backwards compatibility to think about....
This is the thought I was having while I was setting up branches for the v2s docs.

I was having thoughts of putting in one final change branch to the v1 repo so that it would scrub xtag and it's dependent methods and present them differently to the window's object so that v2 could read the prior version and inherit it's features.

For instance, when you load xtag into the global scope you could search the header dom for a meta tag with the appropriate name/content information. Like:

var _h = document.querySelector("meta[name='x-tag']"),
     _v = _h.content ;
if(_v==="2") { _DEFINE_METHOD(); }
else{ NO_CHANGES_KEEP_LATEST_V1_ }

I am not sure if this is a direction you ever thought of going, but an advantage to using a method that utilizes meta content is that it would be more flexible to other developers wanting to mix-in their own code or dependencies that require features on versions of other libraries by making that info readily available.

[ghost]

I have been thinking about this a lot more lately and have dived into the raw core 1 source.

I have went the route of providing a _prevent parameter for the register method.

xtag.register('my-elem', {
  lifecyle: {
    created: function(){ console.log("Choned"); }
  } 
}, 
class{
  constructor() {}
  onBuild(){}
  onRender(){}
  // templates ect using v2 parser for extensions
} );

The preventClassParam, will allow you to pass an onBuild and an onRender method to it, as well as allow you to implement templates.

[ghost]

I call this V2-ish

[ghost]

To Do:

• need to add template examples that use the V2 extension parser

[ghost]

Thinking about:

1. Allowing link preload detection to initiate the correct pollyfill for the requested build.