Definition of various terms in the context of the Vyuh Framework


A way to describe a modular piece of content or functionality. Descriptors are used to define a feature and its exported content types. They are also used to describe other aspect of the framework such as custom content, layouts, extensions, etc.

On the CMS side, descriptors are used to describe various content types and configurations that can be used on the CMS Studio.


Builders are used to collect a set of related descriptors and build a feature or content. On the CMS side, builders assemble and create the schema for a single content-type. They collect all the related descriptors and use them to build the final schema.

On the Flutter side, builders collect all the related descriptors, build a type-registry and help in rendering the content at runtime.


Describes a single feature that is a unit of functionality in the application. Features are usually user-facing and include elements such as content types, routes, layouts, actions, and conditions. A feature also has metadata about its name, icon, title, and description.

The ability to describe a feature in a modular manner is what makes Vyuh unique.


Plugins are a way to provide cross-cutting functionality that can be used by any feature in the app.

For example,

  • The auth plugin (accessible via vyuh.auth) can be used for accessing authentication related APIs

  • The network plugin (accessible via can be used for making API requests such as get, post etc.

A Plugin in the context of Vyuh is just a pluggable API and should not be confused with plugin from the Flutter framework.


CMS stands for Content Management System, more specifically a Headless content management system. It's a way to manage (create/store/edit) structured content with a pre-defined schema.

CMS itself is a plugin inside Vyuh and accessible via vyuh.content. It is used to describe dynamic content with a known schema. Vyuh takes special advantage of headless CMS-es like Sanity to make App development a very exploratory process. You can use the CMS to describe diverse content types such as an E-Commerce Product, a News Article or a Menu Item for a restaurant.

Other aspects of an application such as routes, actions, conditions, etc. are also managed on the CMS.


Actions specify what needs to be done after a certain event. For example, navigating to a page on clicking a card, or showing a success animation after checkout, etc.

Vyuh has several built in actions such as Navigation, Script execution, Restarting, Changing themes, etc.

You can add your own actions and make them relevant to your app.

Like everything else in the Vyuh Framework, Action has counterparts on CMS and on the Flutter side.


Conditions are runtime elements that evaluate to a boolean or some enumeration. They are used to control the flow of the application as well as the availability of certain elements.

For example,

  • A platform condition may only allow certain widgets on certain platforms.

  • An app version condition may only allow certain paths on a specific app version or a range of app versions.

Conditions are used for routing, visibility, layouts, actions, and other dynamic aspects of the app.


A route represents an identifiable screen, dialog or page of the application. The path attribute is used to uniquely identify a route. Route is possibly the most important content-type in a CMS driven Application.


Layouts describe the visual structure of a content-type. Every content type must have a default layout and can also include multiple other layouts. They are particularly useful for routes, and content types like Card or Group. Whether a Group should be shown as a vertical list or a 2-column grid is controlled by the layout. Layouts can be switched for different platforms, screen sizes, or based on runtime conditions.


Schema defines the shape and structure of your content-item along with all of its typed-attributes. Schemas are pervasively used in Vyuh to define various elements such as actions, layouts, routes, and custom content-types.

The Schema has a Dart counterpart in Flutter, which deserializes the content and renders on the screen.

All of these elements are part of the FeatureDescriptor, which describes the feature.

Feature Registry

Feature Registry is a store of all the features that are available in the app. As described earlier in the Feature section, it is an atomic, transferable piece of functionality.


Platform is the deployment target for the app. It can be iOS, android, web or any of the supported platforms of Flutter.

Last updated


Copyright Šī¸ 2024, Vyuh Technologies Pvt. Ltd.