** Is it prod. ready? No. Not at all. I do think that when 0.1 gets released, it would be at least usable.
** Example
use goober::prelude::*;
fn app() -> impl View { let (counter, counter_set) = create_signal(0);
text(move || format!("Counter: {}", counter.get()))
// set the font's size to be a little bigger
.font_size(50.0)
// bad attempt at making it look like a button (setting the background to something darker)
.background(Color::new(0xffaaaaaa)) // set an ARGB color (0xff is alpha, that means the color fully opaque, i.e. solid) as the background
// set an on click handler
.on_click(move |button| {
counter_set.update(|x| {
,*x = match button {
MouseButton::Left => *x + 1, // if you left click, increment
MouseButton::Right => *x - 1, // if you right click, decrement
_ => return,
}
})
})}
This is a component. It defines a signal (a piece of reactive data)
Now, you could launch it in a window (using ~winit~) with this snippet:
use goober::prelude::*; // <- contains launch and LaunchError
fn main() -> Result<(), LaunchError> { launch(app) }
** How me use framework If you don't want an unstable, experimental and possibly not working framework, don't. Wait for 0.1 or something. But if you don't care about instability, add the framework as a git dependency: *** Cargo command
cargo add goober --git https://github.com/Implodent/goober
*** Cargo.toml snippet
[dependencies] goober = { git = "https://github.com/Implodent/goober", branch = "main" }
*** Features You could add the =nightly= feature, with it you could call signals as functions (example: ~signal()~ instead of ~singal.get()~, ~signal_set(123)~ instead of ~signal_set.set(123)~, etc.).
** Architecture