Web components should be isolated, self-contained, modular, consistent, pluggable, injectable, renderable, updatable, and testable. These things mean different, but separate, solutions for different people - but those differences between developers shouldn't hold hostage the stack and course of development in order to accomplish small website features and frontend solutions for larger applications. Data layer interactions, state management, api interactions, and the setup and teardown of components shouldn't be handled by the components themselves; this is a given.
To think that language, stack, or framework used to create a component should also dictate the implementation of the stack is limiting as well. As long as you know how to get access to the data, can make api interactions from a common core, be able to attach to global events, and have your render managed externally then you should be enabled to implement your component however you see fit. With the advent of transpilers like Babel and compilers like Sass, in addition to tools that do minification and tree shaking and code splitting, we can do a lot more to support the wide range of developer experience and comfort with different stacks and tools to build their frontends.
The architecture of view and view model separated by how data is stored and retrieved and how the combination of the two is rendered has always been littered with business rules and data processing before and after long term storage retrieval. There must be a way to separate business rules from the process of rendering and using data as we have been able to separate view from model.
Quasar is much like webpack or browserify in that it compiles code into a singular output from various resources. However, what Quasar does differently than these packages is that it provides a server for real-time rendering of templated code into singular outputs from templates developed in any sort of architecture. Quasar has no front end dependencies outside of the templates allowing developers of templates to define the stack and the user to simply input data into each build. The "build process" for quasar was my original reason for calling this a runtime and it was originally built on top of an express application using an HTML webform. The build process in Quasar comprises the following steps:
Run
Validate Required Input Arguments from the input [receipt]
Copy files from sources [local, web]
Setting additional arguments from the input using the source files [.zip files]
Injecting code associated with the template [debris]
Injecting data into the template [arguments]
Compiling all js, css, and html elements into a singular text based output [template assets]
Uploading files to the cloud [aws s3, dropbox, google]
Deploying code to endpoint [google ad manager, placements]
End
Each Quasar, a type of middleware, has a build task file and a template folder associated with it. Quasar loads these files and uses some data, like defined arguments for template data, from these files to build the webform and webapp which serve as a user interface to create Quasar build jobs. This runtime was originally developed as an express web application which uses gulp to watch a local filesystem folder for new job files (.json) created by the web api endpoint which receives the receipts as json data. The Quasar Webform and Webapp are also generated by Quasar and I have developed those two stacks on React, which can be generated on the fly when starting up the web api which serves the form (on localhost:3000).
The architecture of this platform is as follows:
The Quasar SDK - the runtime actions and tools that allow quasar developers to use any front-end stack they want to produce a singular html output that is cross-browser compatible.
The Quasar CLI - the command line interface to the SDK which can run builds and spin up the Web Api.
The Quasar Web Api - the express application which hosts and receives requests for running Quasar builds.
The Quasar Electron App - the electron application which runs the Web Api and serves the webform or webapp in an application window on OS X, Windows, or Linux.
The Quasar Lambda Function - an AWS Lambda implementation of the Quasar SDK for running builds in a serverless environment.
The Quasar Webform - a longform UI of all the inputs for each Quasar in an environment. This was the original way to use Quasar and is now more of a developer tool.
The Quasar WebApp - the platform application for the Quasar ecosystem in a scalable environment which allows users to login, manage builds step by step with a wizard, update and invalidate files uploaded to external storage, preview outputs in environments where Quasar widgets live, deploy widgets to production websites, and see usage statistics of quasars in production.
When writing a quasar
quasars are build tasks that associate user provided data with template files in a pipeline to produce a single text file output. The output can have dependency files associated with it, or it can be a single, self contained, piece of code.
The base class for a quasar can be overloaded for your custom specifications or used in place and extended. By default, the build pipeline will run the following methods sequentially:
validateRequiredArgs
build
cleanUp
And, by default, each of those methods will follow the build pipeline from downloading or unpacking source files, verifying and setting required data, and cleaning up after moving and staging files. The build method in the base class, by default, does not produce an outputFile as this is a scaffolding class and the logic behind an outputFile is too specific to the implementation, in most cases, to be handled dynamically.
When writing debris
debris are text based assets that are injected into quasars in an ordered fashion as they are included, or directly as comments within the quasars template files using the convention below. Debris can be the file itself or it can be a manifest that points to a file src to either be included as a tag or downloaded and replaced inline with wrapping code (.uri file). Debris do not have access to template data at build time, so they must follow the practice of creating an initializing method for templated data to pass params to if they are needed.
To require or include debris in your template files use the following convention. A file that is included with require will only be included if it has not been included before. Files included with include will always be included.
//=require vendor/**/*.js
//=require relative/path/to/file.js
/*=include relative/path/to/file.css */
<!--=include relative/path/to/file.html -->
When writing a template
templates are the target files for each quasar build and can comprise the entire source of the quasar build or be partial components that wrap external sources for the desired output. Data is injected into template files during build time following the convention.
Template files can be lodash or _ (underscore) templates and data is typically inserted in that way. These templating methods can be used in any template file type (js, css, html).