Syncing UI<->data

[brillout]

There seem to be fundamental question about how the UI should be synced with the data it shows.

So far, I think the best approach is to treat the filesystem (more precisely speaking, all the Git repos) as the single source-of-truth.

The potential downside is that we'll need filesystem watchers. So far I think it can work reliably though: Vite shows that watching all the files of a project works, and we'll only need to watch The Framework's .the-framework/* data (of all Git repos).

The follow up question is about Telefunc. How can we use Telefunc to automatically sync the UI with .the-framework/* data? @nitedani Ideas?

@suleimansh In then meantime, for the MVP, I guess it's enough if the UI requests the data at load time (no syncing, user has to F5 the page to get fresh data), while the main view is synced via Telefunc Stream.

See also:

• Database #313

[suleimansh]

The MVP shape you described is already what's running (verified live on a daemon just now):

• Load-time fetch: every list/rail reads over a Telefunc RPC on mount — projects (onProjects), run history (onRuns), docs (onDocs), project log (onProjectLog), queue (onQueue), overview (onOverview). Most also poll every 4-5s, so in practice they're fresher than F5-only.
• Main view: the live run feed is a Telefunc Channel (onEvents) that pushes one FrameworkEvent per new .the-framework/events.jsonl line. The main event view + the choice/views rails are all projections of that one stream.

So: filesystem as source of truth, F5 (or the poll) for the lists, Telefunc Stream for the main view.

The open piece is live auto-sync of the lists without a poll/F5: fs.watch each repo's .the-framework/* -> push over Telefunc so the sidebar/rails update the instant a file changes. @nitedani that watch->channel design is the part for you; happy to wire the client side once there's a signal to subscribe to.