create-modulo

<!DOCTYPE html><meta charset=utf8><script src=../static/Modulo.html></script><script type=md>--- title: Definitions --- # 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](../part/props.html) 2. [Template](../part/template.html) 3. [Style](../part/style.html) 4. _[Other Component Part(s)]_ 5. [StaticData](../part/staticdata.html) 6. [State](../part/state.html) 7. [Script](../part/script.html) 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](../core/component.html) itself, Modulo comes with several other global or core definitions: 1. [Configuration](../core/configuration.html) _and_ [Include](../core/include.html) - *(Extending or configuring Modulo and including third-party JavaScript libraries)* 2. [ContentList](../core/configuration.html) *(Include lists of files for preloading metadata and site builds)* 3. [Library](../core/library.html) - *(Importing component libraries with non-conflicting namespaces or aliases)* 4. [Artifact](../core/artifact.html) - *(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: ```modulo <Template -src="templates/my-template.html"></Template> <Script -src="js/my-javascript.js"><-Script> <Style -src="css/my-style.css"></Style> ``` # 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: ```modulo <Template>{{ state.abc }} and {{ state1.abc }}</Template> <State abc="first state data"></State> <State abc="second state data"></State> ``` ## 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: ```modulo edit: demo=modulo <Template> <p>first_state.abc is {{ first_state.abc }}</p> <p>second_state.abc is {{ second_state.abc }}</p> </Template> <State -name="first_state" abc="first state data" ></State> <State -name="second_state" abc="second state data" ></State> ``` ##### 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: ```modulo edit: demo=modulo <Template -name="template_a"><h3>First template</h3></Template> <Template -name="template_b"><h3>Second Template</h3></Template> <Template> {% include template_a %} <hr /> {% include template_b %} </Template> ```