Render
The visual component that displays on physical devices and in Studio preview
Render Mount Point
The render mount point is the visual content that appears on physical devices — TVs, kiosks, digital signs, and video walls. It is the only required component of a TelemetryOS application. When a device loads a playlist page containing your application, the platform creates an iframe pointed at the render path and displays it on screen. The same iframe is used in Studio's page editor for preview.
Configuration
The render path is declared in telemetry.config.json:
{
"mountPoints": {
"render": "/render"
}
}The path /render tells the platform to load the application's render entry point at that route. During the build, Vite (or your build tool) produces an index.html at this path, and that file becomes the content shown on devices.
Runtime Context
The render view executes inside a sandboxed iframe embedded in the TelemetryOS player on the device. It also appears in the Studio page editor for preview, so your code runs in both contexts. The browser environment is a managed Chrome instance — there are no cross-browser concerns.
The render view has full SDK access. All four storage scopes are available:
| Scope | Available | Typical Use |
|---|---|---|
application | Yes | Data shared across all instances (global config, shared content) |
instance | Yes | Per-placement configuration (city, theme, data source) |
device | Yes | Device-specific state (calibration, cached credentials) |
shared(namespace) | Yes | Cross-application data sharing |
Beyond storage, the render view can access the media library, control playlist navigation, use the HTTP proxy for external API calls, and interact with hardware (cameras, serial ports, GPIO) through the SDK.
Example
A typical render component loads its configuration from instance storage (written by the settings view) and subscribes to changes so the display updates in real time when an administrator adjusts settings:
import { configure, store, playlist, media } from '@telemetryos/sdk';
configure('my-app');
// Load initial configuration
const config = await store().instance.get<{ city: string; units: string }>('config');
if (config) {
renderWeather(config);
} else {
renderPlaceholder('Configure this application in Settings');
}
// Subscribe to configuration changes
store().instance.subscribe('config', (newConfig) => {
renderWeather(newConfig);
});
// Navigate to next playlist page after 30 seconds
setTimeout(() => {
playlist().nextPage();
}, 30000);
// Display media from the library
const featured = await media().getAllByTag('featured');
renderMediaGallery(featured);Best Practices
The render view runs continuously on unattended devices, so it needs to be resilient and efficient. Always handle the unconfigured state gracefully — display branded placeholder content rather than a blank screen or error when an administrator hasn't set things up yet. This ensures devices look presentable from the moment they are powered on.
Use storage subscriptions for real-time data updates rather than polling. When the settings view saves a new city name, the render view receives the change through a subscription callback within seconds. Polling wastes resources and introduces unnecessary latency.
Optimize for long-running performance. Applications may run for weeks without a page refresh, so avoid memory leaks from uncleared intervals, growing arrays, or DOM nodes that accumulate over time. Test by leaving your application running in a browser tab for an extended period and monitoring memory usage.
Design responsively for multiple screen sizes and orientations. TelemetryOS devices range from small kiosk displays to large video walls, and the same application may be deployed to different hardware. The platform supports landscape, portrait, and rotated orientations configured per device.
Implement error recovery with fallback content. If an external API call fails, show the last known good data with a timestamp rather than an error message. Devices in public spaces should never display stack traces or broken layouts.
Common Use Cases
The render view is the primary display surface for signage content (promotions, announcements, branded media), interactive kiosk interfaces (wayfinding, check-in, self-service), live data dashboards (KPIs, weather, transit schedules), menu boards (restaurants, cafeterias, quick-service), and video walls (multi-screen compositions driven by a single application).
Updated about 1 hour ago