[Code template] Platform initialization with layout restore

io.Connect Desktop
,
1

This is a small, self-contained snippet you can adapt to test io.Connect integration patterns or reproduce issues without sharing proprietary code.

All code templates | Why we’re publishing these

import IOConnectFactory from "@interopio/desktop";
import * as WorkspacesFactory from "@interopio/workspaces-api";
import * as os from "os";

export const setupGlue = async () => {
    const glue = await IOConnectFactory({
        libraries: [WorkspacesFactory.default],
        layouts: "full",
        application: "clientlist", // replace with your app name
        channels: true,
        auth: {
            username: os.userInfo().username,
            password: "",
        },
        gateway: {
            ws: process.env.IO_CD_GATEWAY ?? "ws://0.0.0.0:8385",
        },
    });

    console.log("Glue initialized");

    glue.layouts.onRestored(async () => {
        console.log("Layout restored");
        // your post-restore logic here
    });

    return glue;
};

(async () => {
    const glue = await setupGlue();
    console.log("Restoring layout...");
    await glue.layouts.restore({ name: "workspaces-test" }); // replace with your layout name
    console.log("Starting app...");
    await glue.appManager.application("clientlist").start({}, {}); // replace with your app name
    console.log("Done");
})();

The layouts.onRestored handler fires after a layout is restored, and if you do heavy async processing inside it (e.g. fetching data, waiting on services, reinitializing state), the platform waits for it to complete. If it takes too long, subsequent calls like app.start can internally timeout. If you’re seeing unexpected timeout errors during startup, this template can help you isolate whether it’s the async work in your onRestored handler causing the delay.