CParts
Custom CParts? Here we describe core CParts used by component developers, which are sufficient for most common use-cases. However, if you are instead looking to extend this core functionality with custom CParts written in JavaScript, refer to the Custom Component Part examples on the demos page, at least until more thorough CPart API documentation is developed.
The central concept to Modulo Components is that of Component Parts. In this documentation and code it will be often shortened to CParts. Every component definition consists of configuring one or more CPart definitions. Modulo comes "batteries-included" with about 6 CParts, which provide the core functionality of building Modulo Components, and are documented here.
Conventionally, when defining components, CParts are listed in the following order within a given Component definition:
The rationale for this ordering is to put Props and Template first since they are often the first CParts that are important to read when trying to understand or debug the behavior of a Component, while putting Style last as it's typically the least important to read. Note that ordering makes a difference: They will be processed in the order given.
Typically, you will not need to have more than one of the same type of CPart in a given component. However, in some cases for particular CParts it might make sense, such as to mix in multiple Styles into a single Component. In the case of duplicate CParts of the same type, often the behavior is that "whoever gets the last word in wins", or the configuration specified by the final CPart takes precedence (although this depends on the CPart in question).