◁ Introduction ≡ Table of Contents Getting Started ▷
In Seanox aspect-js, the composite is the atomic UI unit. A composite contains its view, application logic and associated resources. The runtime loads and manages these resources and controls the composite lifecycle.
The composite ID identifies a composite and brings its view, resources and application module together. From the runtime’s perspective, these resources form a composite module, which represents them as a runtime module. Composite binding connects the view with the application module without prescribing its internal structure.
Multiple composites can be combined into functional components. An ECMA
module is independent of the Composite system and provides standard
JavaScript modularization using import and export.
The runtime provides the infrastructure required to execute applications built with Seanox aspect-js. It loads and manages resources, creates and manages composites, establishes composite binding and handles rendering, reactivity, routing and lifecycle. For each composite, it loads the corresponding composite module and manages the resources associated with its composite ID. Application- specific behavior remains outside the runtime, which does not define the internal architecture of application modules.
A composite is the atomic UI unit of Seanox aspect-js. It consists of HTML, CSS, JavaScript and optional additional resources and is identified by a composite ID. The runtime uses this ID to find the associated resources, establish composite binding and manage the composite lifecycle. An application module can participate in this lifecycle through callbacks when the composite is attached to or removed from the document.
A composite ID is a unique string that identifies a composite. It connects the composite with its view, application module and associated resources and is used for resource resolution, the application module namespace, the composite lifecycle and composite binding.
In markup, the composite ID is represented by the combination of the id and
composite attributes. It is also used as the logical name of the composite
in files and code.
A composite module is the resource group that belongs to a Composite. It consists of:
The runtime loads composite modules lazily and can cache them for later use. The Composite ID identifies the composite module and its resources. From the runtime’s perspective, a composite module is a runtime module and is independent of the JavaScript module system defined by ECMAScript.
A view is the HTML representation of a composite. It defines the structure and presentation of the user interface and can use expressions and declarative attributes to access application data, handle interactions and control rendering behavior. Application logic is provided by the application module rather than the view.
The application module provides the application logic of a Composite. It consists of the JavaScript provided by the Composite Script and has no predefined internal structure.
Its structure may consist of an object, function, class or multiple classes. The Runtime does not prescribe an architectural pattern. It may contain presentation logic, a ViewModel, a Controller, a Service or other application-specific structures.
Composite Scripts execute in an isolated module scope. Objects that participate in composite binding must be explicitly exported.
A Component is a functional unit composed of multiple Composites and/or other Components. It groups Composites into a larger functional unit without replacing the Composite as the atomic UI unit.
An ECMA module is a standard JavaScript module defined by the ECMAScript
module system and uses import and export. It is independent of the composite
system and does not participate in the composite lifecycle. The ECMAScript
import and export can be used together with the #import and #export
mechanisms of a Composite Script.
The three module concepts have different roles:
Composite binding connects a view with its application module. The runtime establishes this connection for a composite and provides synchronization between view elements and module properties, event forwarding and method invocation. It does not define the internal structure or architectural role of the application module. The binding is associated with the composite ID and follows the composite lifecycle.
Declarative Markup provides additional attributes that can be used on HTML elements. These attributes define runtime behavior such as conditional rendering, event handling, synchronization and resource loading.
The markup describes the structure and behavior of the view, while application logic remains in the application module.
The expression language allows expressions to be used in HTML markup and attribute values. Expressions can access application modules, JavaScript values and functions. The runtime evaluates these expressions during rendering and uses their results to update the view.
The runtime manages the lifecycle of a Composite from loading its resources through binding and rendering to its removal. During this lifecycle, the runtime creates and connects the composite, processes its View and application module, and removes their runtime connections when the composite is detached.
Application modules can react to lifecycle events by subscribing to events or using interceptors. Both mechanisms allow application modules to respond to lifecycle changes, but neither can control the lifecycle or influence rendering.
Rendering updates the view based on the current application state. During this process, the runtime evaluates expressions and processes declarative markup to create or update the corresponding parts of the document. Rendering can be triggered explicitly or, when reactivity is enabled, automatically by changes to reactive data.
Reactivity connects changes in application data with updates to dependent views. When a reactive object changes, the runtime is notified and can update views that use the affected values in their expressions. Reactive rendering is optional and can be combined with explicit rendering.
Routing controls navigation between Views within an application. Routes are based on paths that identify Views and their hierarchy. The Runtime uses these paths to manage the active Views and the corresponding Composites.
A Composite brings together a view, an application module and their associated resources under a composite ID. The runtime loads and manages these resources as a composite Module and connects the View and application module through composite binding.
Multiple composites can be combined into Components, while ECMA Modules provide JavaScript modularization independently of the composite system. The runtime provides the infrastructure for managing these elements throughout their lifecycle.