Implement a floem cli with dev hot reload/live preview

[XHanL]

I'm excited about everything in floem, it meets 90% of my expectations!

• If floem could make improvements in hot reloading/live preview, it would be more attractive than several other frameworks.
• This is an immature idea, and I'm uncertain about its feasibility and whether floem is suitable for it.
• If this is impossible, unreasonable, or not worth doing, please feel free to comment, welcome to discuss!

Structure

• File watcher

  • watch project file changes

• Style/component compiler

  • Compiles only signals/styles/components into some representation (like a component tree)
  • Leaves the rest of the Rust syntax to cargo

• Independent runtime

  • Execute the framework's runtime separately, free from compilation
  • Allow Rust to interact with the runtime in some way
  • Ability to dynamically replace components

Process

• For .rs files, use a simple parser to extract code describing styles/components, convert styles/components into a component tree
• When a .rs file is modified,
  • If the .rs file only involves changes to styles/components, update directly through the runtime
  • If other Rust code has changed, recompile

Fallback plan

implementing just these parts would also be a significant improvement for floem

• Hot reload only for styles
• Live preview of components/styles only (open a preview window, no Rust compilation process, similar to slint preview)

[dzhou121]

Thanks for bringing this up, and hot reload is much desired feature in Floem, myself included.

Your ideas are probably 99% matching I've been thinking about how hot reloading is going to work in Floem.

I think a good first step is to support styles reloading (and probably easiest), and the way how Floem style update works actually make it quite easy to update the style from a different process, and the key information would be the View Id. The tricky part will be the "parser" where it listens to file changes and extract the updates from file changes and then send the updates to Floem.

[dzhou121]

Style in Floem is a very complex struct, so probably the "updater" needs to sit with the core, so that you don't need to serialise/deserialise it. Probably the "updater" would receive the diff, parsing it, and directly update the style.

[XHanL]

I've done some code review, primarily checking src/style.rs and some examples.

Can I simply assume that the parser's goal is to transform various statements in .rs files like:

.style(|s| s)

into something like this:

pub struct ReloadStyle {
    pub key: String, // but how to get the unique id of each style?
    pub view_key: String, // maybe we need, maybe not
    pub map: HashMap<StyleKey, Rc<dyn Any>>, 
}

[XHanL]

and Style::new(), tracking them across files may not be easy..

[jrmoulton]

each style can be uniquely identified by the combination of a view id and a stack offset (a view holds it's styles in a "stack" where when a style is updated it always updates the same location in that stack)

[jrmoulton]

We would probably have to require that some communication runs between app and the cli.

We could tag a style with a .track("unique string name") method which figures out a way to communicate to a running cli what the viewid and stack offset are.

Then the cli could maybe specifically look for those .track methods and use the unique string name to know what styles to reparse and which style to update