Vyuh

Appearance

Glossary ​

Descriptor ​

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 aspects 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.

Some of the common descriptor types you will encounter include the FeatureDescriptor, ContentDescriptor, APIContentDescriptor, etc.

dart
final feature = FeatureDescriptor(
  name: 'shop',
  title: 'Shopping',
  icon: Icons.shopping_cart,
  routes: () async => [...],
  extensions: [...],
);

Builder ​

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.

dart
static final contentBuilder = ContentBuilder<ProductCard>(
  content: ProductCard.typeDescriptor,
  defaultLayout: DefaultProductCardLayout(),
  defaultLayoutDescriptor: DefaultProductCardLayout.typeDescriptor,
);

Feature ​

Describes a single feature that is a unit of functionality in the application. Features are 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 central to the Vyuh Framework.

A Feature is transferable across any Vyuh-enabled Apps. You can drop a feature into a different Vyuh App and have it work with minimal or no configuration changes. This allows Vyuh to build a family of Apps that share a set of features.

Mini App

Features are also referred to as Mini Apps in Vyuh's terminology. When a feature encapsulates significant functionality, rivaling that of an App, it is referred to as a Mini App.

Think of a feature in a Banking App that handles Investments or Loans or performs a peer-to-peer Payment, like UPI. These are modular features that are sizable and encapsulate a fair amount of UX journeys and APIs. Such features qualify as Mini Apps.

Plugin ​

Plugins 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 vyuh.network) can be used for making API requests such as get, post etc.
dart
// Access plugins via the vyuh global
final user = await vyuh.auth.currentUser;
final response = await vyuh.network.get('/api/data');
final content = await vyuh.content.provider.fetchRoute('/home');

INFO

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

Schema ​

Schema defines the shape and structure of your content-item along with all of its typed-attributes. Schemas are used throughout 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.

CMS ​

CMS stands for Content Management System, more specifically a Headless content management system. It is 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 leverages headless CMS-es like Sanity to make App development an 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.

Studio ​

Refers to the content editing experience offered by the headless CMS. This is where all the content gets created and managed. It may include a set of workflows for approval before publishing content live. Some studios allow greater customization, letting developers provide custom input controls for editing complex content types.

Content Item ​

Refers to an instance of a content-type such as a Product Card, Image, Text or a collection such as a Carousel, List or Grid. There are standard content-items built into the framework such as Card, Group, Divider, Accordion, Portable Text, etc. The framework also allows creating custom Content Items that are specialized for the App.

dart
@JsonSerializable(createToJson: false)
final class ProductCard extends ContentItem {
  static const schemaName = 'shop.productCard';
  final String title;
  final double price;
  // ...
  ProductCard({required this.title, required this.price, super.layout})
      : super(schemaType: schemaName);
}

Condition ​

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.

dart
final class PartOfDayCondition extends ConditionConfiguration {
  @override
  Future<String?> execute(BuildContext context) async {
    final hour = DateTime.now().hour;
    return hour < 12 ? 'morning' : 'afternoon';
  }
}

Route ​

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

Conditional Route ​

A special type of Route that includes a condition to allow runtime branching and switching between two or more Routes. Conditional routes provide a fork in journey based on some condition. A classic example is showing a Login page or a Dashboard page depending on the authentication-state of the user. This can be done with a ConditionalRoute pointing to a Login Page for the false condition and the Dashboard Page for the true condition of the user-authentication state.

Action ​

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.

dart
final class ShowBarcodeAction extends ActionConfiguration {
  @override
  FutureOr<void> execute(BuildContext context, {Map<String, dynamic>? arguments}) {
    // Perform the action
  }
}

Events ​

Events allow you to listen to lifecycle events that happen inside the framework. They can also be used by features to communicate with other features. The eventing system inside Vyuh acts like an event-bus where different features and plugins can communicate with each other with a type-safe event.

Layout ​

Layouts describe the visual structure of a content-type. Every content type (standard or custom) 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.

dart
final class MiniViewLayout extends LayoutConfiguration<ProductCard> {
  @override
  Widget build(BuildContext context, ProductCard content) {
    return Card(child: Text(content.title));
  }
}

Modifier ​

Modifiers are chainable visual behaviors that can be attached to any content-item. You can have one or more Modifiers for a Content Item and they are applied in the same order as specified.

The framework takes the output of the layout, which is a Widget and feeds it to the first modifier in the chain. The end output after applying all modifiers is also a Widget.

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 ​

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