Proposal: Integrated html vue type file

Proposal: Integrated .html/.vue-type file for HaxeVx components' markup + CSS modules (with compile-time strict-typed checking).

<template>
 <div class="dot-big">
	<div @click="doClickMe()" :wonderful="123" class="${STYLE.abc} ${dddStyle.wonderFl} dot-big-pulse"></div>
	<div class="dot-big-shape"></div>
</div>
</template>

<style var="STYLE">
.abc {
	color:#ff0000;
}
.wonder-fl {

}
</style>

<css>
	<i file="filename/fawf.css" var="GLOBAL" />
	<i file="blahblah/awfaw/ffss.scss" var="CSTYLE"/>
	<i className="com.blahblah.some.StaticClass" var="dddStyle"/>
</css>

A file format spec specifically suited for frontend designers especially, since it only contains markup and CSS only.

<style> tag refers to the module style solely relevant to the component. For <style> tag, if var is left undefined, it's assumed to be STYLE by default (according to convention). Unlike regular Vue, HaxeVx assumes all <style> refers to the CSS module tied to the HaxeVx Vue component. To force-declare a global <style> in certain cases, there's a consideration to be able to use a global attribute like <style global>. However, it's better for global styles to be written elsewhere instead of the component file generally, or even better, set up a relavant global/shared style module accordingly so everything is namespaced accordingly. (Note: Currently, I don't have any pipeline supporting global attribute for component styles, which is a bit of an oxymoron to me...).

I'm currently seeing how to best support accessing other CSS modules within the <style> tag though....

---

Format is similar to .vue spec (at a very basic level), but the <css> imports part is added to support importing CSS module singleton-cached instances as component class's static var {{varName}} references accordingly.

But of course, the Haxe codebase is still in a seperate .hx file that coders will have to view split screen in their IDEs.

The .vue-like template is parsed as a form of HTML to XML conversion, than analysed accordingly to validate against the relevant HaxeVx component codebase in the .hx file, according to spec https://github.com/Glidias/haxevx/wiki/Proposal:-Lint-Vue-templates-and-check-bindings-against-Haxe-codebase , so you get full strict-typed compiling when doing development builds, and, depending on your IDE, quick jumping to compile-time error locations in the .vue file, useful for any developer/designer hopefully. So, no more typos or mismatched types with CSS modules and template code bindings.

By default, the build macro will use following file extension priority: .vue .html, if file extension is left undefined.

Components specs proposal:

Some other considerations like <components> imports might be a good consideration to have, but currently this responsiblity is left soley to the .hx file instead as of now. I'd rather not mix-and-match both, so it's either one or the other, though having the option to exclusively declare your Components() (ie. Vue's components: in component definition) as of below, might be useful for often-used reusable components.

<components>
	<i className="some.thirdparty.ComponentName" name="my-cool-component" var="Comp_MyCoolComponent" />
</components>

name refers to the literal component tag name to use. var is optional, but if included, a static inline var reference will be created where you can use something like <${Comp_MyCoolComponent}> instead to avoid typos with component name literals. Of course, the danger is in declaring a variable that is already declared in the Haxe codebase (though the compiler will catch this), so you need to use some conventions on your own to ensure uniqueness of component var name references. If name is left undefined, a long name is used instead based on the className.

Other considerations would be to support custom constructor/factory method/component factory parameters as well, and not mere singleton caches, since some Component specs may be dynamically initialised with different parameters per instance.

Drawbacks with combined .vue file

A lot of IDEs don't provide full Intellisense within the <style> tags of .html/.vue files, unfortunately. Hopefully, this will change in the future.