Definition types

Like the underlying HTML language itself, Modulo is declarative. This means that the central concept to Modulo is that of Definitions: Almost all of your code will be "declaring" that things are defined in a certain way.

Introduction to types

Components consist of configuring one or more Component Part definitions. These powerful tools let you create interactive and data-driven reactive components.

Configuring global Modulo setitngs and content is done by setting Core Definitions at the top level. Core Definitions provide tools for global operations with includes, configuration, global data, and content.

Know thy name; know thy data: All definitions get stored in the global variable modulo.defintions. Note that the keys includes parent names spaced by underscore, e.g. names like library_App_template. If you ever doubt about naming or data, bring up a JavaScript console and look there!

Component Parts

To keep things consistent, you may want to follow this order convention within a given Component definition:

1. Props
2. Template
3. Style
4. [Other Component Part(s)]
5. StaticData
6. State
7. Script

The rationale for this ordering is to "sort" by "most simple, most external" to "most complex, most internal". This will seem the most logical for others reading or using your libraries.

Core Definitions

Which ones to use? Most users of Modulo will use the Component definition the most. The other definitions listed here are useful most when you want to extend Modulo with custom JavaScript behavior, or integrate with third party code.

In addition to Component itself, Modulo comes with several other global or core definitions:

1. Configuration and Include - (Extending or configuring Modulo and including third-party JavaScript libraries)
2. ContentList (Include lists of files for preloading metadata and site builds)
3. Library - (Importing component libraries with non-conflicting namespaces or aliases)
4. Artifact - (Customizing build behavior or specifying additional build artifacts)

Loading

Load order

You are free to order Core Definitions and Component Parts in any order.

However, note that ordering can make a big difference: Modulo will load, process and execute definitions, top-to-bottom, in the order provided. You might find it necessary to change the ordering because of specific needs, e.g. to ensure aspects of Modulo get configured before they are used.

Loading with -src=

The -src="..." is the first most important definition processor. It lets you load many file types with a similar behavior to how in plain HTML you can easily use <script src="..."> or <link rel=stylesheet href="..."> to ensure the page loads with given dependencies. See below:

Naming

Default naming

All definitions have a name. By default, all definitions get named in lower-case (e.g. StaticData becomes staticdata). If there are multiples, they will get incrementing numbers affixed. Generally, you do not want the numbered naming behavior, since it's hard to remember, and should instead be specify the name. For example, the two State parts get the names state and state1 below:

Naming with -name=

The -name attribute lets us name and distinguish duplicate parts, and prevents the numbering behavior.

Example 1: Explicit Naming (State)

For example, here we can have two State Component Parts, each with the same abc attribute, but different names:

Example 2: Explicit Naming (Template)

This is also handy for breaking apart large templates. Here we name two extra templates template_a and template_b, which we include in a final template: