Only affects Cypress tests on examples/todomvc.

Dependabot alert security/dependabot/30>
Waiting on #cypress-io/cypress/issues/27261

Elements should have a .cache() method that globally caches the node by call site (and key?) and uses clone_node to generate the elements. Will this work for reactive elements?

Hi,

Thanks for creating SilkenWeb – so far I really enjoy the nice macro-less API!

(It's smooth as silk... 😅)

While looking at the source code, I noticed the following function:

fn set_attribute(dom_element: &dom::Element, name: impl AsRef<str>, value: impl AsRef<str>) {
    clone!(dom_element);
    let name = name.as_ref().to_string();
    let value = value.as_ref().to_string();

    queue_update(move || dom_element.set_attribute(&name, &value).unwrap());
}

Basically, you:

1. request something that can be turned into &str
2. convert it (potentially a String) into a &str
3. and then you turn that &str into a String.

That doesn't seem to make sense to me – is there a reason for that?

I believe, ToString would be the right trait to request:

fn foo<T: ToString>(s: T) {
    println!("{}", s.to_string())
}

fn main() {
    foo("bar");
    foo("bar".to_string())
}

@simon-bourne it is nice to see that there is another fast framework existed by Silkenweb 👍
As a curious new visitor, I wonder what is the main difference with other FRP based frameworks like sycamore or leptops.
I think it would be helpful to mention this in a short approach in the README.

BTW:
I really like the "No Macro DSL" approach 💯

Come up with a plan for animations

Once a text input field has been edited by hand (i.e. type something into the field), the displayed input value will no longer be updated from a read signal. The input value is update just fine before the edit, it is only after the edit that it stops.

Example reproduction:

fn main() {
    let message = Signal::new("".to_owned());
    let message_read = message.read();
    let message_write = message.write();

    let app = div()
        .child(input().value(message_read))
        .child(button().text("Overwrite Message").on_click(move |_,_| {
            message_write.replace(|_| "Overwrite worked!".to_owned())
        }));

    mount("app", app);
}

In the example above, the overwrite button only appears to work if you haven't already typed something into the input.

P.S. I'm a big fan. Of all the rust web frameworks I've tried, this is definitely my favorite. I hope you keep up the great work!

Wrap event handlers for Window

Currently Element mirrors the real DOM tree. It only really needs to store a tree of reactive nodes and their reactive children. Is this even worth implementing?

Make sure we've got a complete list from MDN

Look into what's required to support Tauri. Hopefully it just needs an example.

Make it as easy as possible to wrap an existing web components library and provide an example.

Currently, only a few event types are handled. We need to make a complete list and handle all of them.

Currently we just use a thread local queue to emulate the browsers microtask queue on the server. This isn't ideal when calling render_now for 2 reasons:

1. Multiple request handlers could run on the same thread at the same time, so render_now would process tasks from all requests.
2. A request handler could run on multiple threads so render_now could miss some tasks in multi-threaded runtimes.

One possible solution is to use tokios LocalSet and spawn_local. LocalSet implements Future, so we could keep blocking on it until it can't make any more progress.

Currently we don't distinguish between signal initialization and signal changes when mapping over them. TodoMVC storage needs a way to distinguish the 2 conditions. One option is to have a map alternative that's passed an initializing flag.

Investigate how to de-bounce signals in a platform (client/server) agnostic way.

• Using tokio::time on the server?
• Using gloo-timers on the client.
• Provide an example.

Routing is a bit basic at the moment. Currently it just provides a URL string signal. We should provide a more structured URL with methods to access different components. The url library from servo looks like a great parser for server side apps, but would bloat client side apps too much. We need a lightweight wrapper around the browser's URL parser on the client side and a wrapper around the url library on the server side.

I am new to silkenweb, excited with the non-vdom idea.

Are there any simple and quick performance benchmark compared to other rust-wasm frameworks, such as yew, seed, sycamore?

thank you

Wrap the CSS Object Model and allow setting the style property on the document and elements.

There should be an implementation of routing on the server. Url should be wrapped in our own struct with a client and server side implementation provided via a trait. The implementation should be selected at compile time with cfg attrs.

What should the primitive operations on child lists be? We should be able to implement filtering, sorting, mapping etc in terms of the primitives.

Shouldn't actually affect anything. It's used by grass for it's command line, but we're only using grass as a library.

Dependabot alert
Waiting on #connorskees/grass/issues/84

(signal0, signal1).map(...) for larger tuples. Is it easier if we have signal flattening (#4)

I created a super-simple project based on "silkenweb-example-counter" in the examples/counter directory, but it doesn't compile due to:

❯ cargo build
   Compiling silkenweb-macros v0.7.0
   Compiling silkenweb-signals-ext v0.7.0
error[E0603]: trait `CustomToken` is private
  --> /Users/hakesson/.cargo/registry/src/index.crates.io-6f17d22bba15001f/silkenweb-macros-0.7.0/src/parse.rs:10:26
   |
10 |     token::{self, Comma, CustomToken},
   |                          ^^^^^^^^^^^ private trait
   |
note: the trait `CustomToken` is defined here
  --> /Users/hakesson/.cargo/registry/src/index.crates.io-6f17d22bba15001f/syn-2.0.39/src/token.rs:92:16
   |
92 | pub(crate) use self::private::CustomToken;
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^

htmx would be an ideal companion for SSR. Investigate how easy it would be to write the server side component using Silkenweb.

Implementation ideas:

• Integrate directly with a server framework (initially just Axum). Arpy isn't suitable because:
  • it uses it's own RPC protocol.
  • there's no HTML encoder for Serde.
  • htmx handles errors using HTTP status codes.
• Implement Axum IntoResponse for elements, wrapped in a HtmxResponse newtype.
• Implement Axum FromRequest for all Serde DeserializeOwned wrapped in a HtmxRequest newtype.
• Error handling. We should be able to return a Result<impl IntoResponse, impl IntoResponse> from our Axum handler.
• Produce some examples.

Can we implement a flatten method on nested ReadSignals?

    impl<T> ReadSignal<ReadSignal<T>> {
        fn flatten(&self) -> ReadSignal<T>;
    }

Add a log_panics function that defers to console_error_panic_hook::set_once(). Examples should call this. In debug mode, mount and hydrate should also call it.

Support more SVG elements/attributes.

Accumulators should be generalized in terms of actions and inverses. This enables And and Or accumulators which keep a running count of how many items are true.

This is complicated as tokio needs Futures to be Send.

Discord?

Current dependency graph

graph TD;
  silkenweb[<b>silkenweb</b>];
  silkenweb --> base;
  silkenweb --> macros;
  silkenweb --> signals-ext;
  macros --base::css::Source--> base;
  test --base::document--> base;
  test --> silkenweb;

Proposal

1. move base::document and base::window to the silkenweb crate.
2. create a new styling crate with all the CSS-related stuff.
3. create a new styling-macros crate with CSS-related macros.
4. remove base and move its base::css code to the styling crate.
5. create a new runtime crate that contains the runtime (task:: etc) code.
6. remove the signals-ext and move it's code into runtime.

graph TD;
  silkenweb[<b>silkenweb</b>];
  styling --> silkenweb;
  styling --> styling-macros;
  silkenweb --> macros;
  silkenweb --> runtime;
  test --> silkenweb;

The following is achieved with this:

• the runtime crate can be used by business logic so that testing of it can be done without a full silkenweb dependency. This guarantees that the business logic doesn't mix in any UI-related things. I.e. the app-state stuff can be added to the runtime crate.
• styling is separated into its own crate which depends on and extends silkenweb. Like this the styling is optional.

Let me know what you think. I'll create a PR for it.

Note

I'm working on reducing the silkenweb compilation times and the styling (lightningcss, grass, cssparser) is responsible for 40% of it. For my own project, I will use a simple approach of having a parallel css file to each component and at build just appending all these css files into a single main one.

In my_component.rs:

fn my_component<D: Dom>() -> Button<D> {
    button().class("my-component")
}

In my_component.css:

.my-component {
   component specific standard css
}

I might be doing something wrong here. But to reproduce this, we can take counter-list as an example.

If we change the main function to the following:

fn main() {
    let list = Rc::new(MutableVec::new());
    list.lock_mut().push_cloned(Counter);
    mount(
        "app",
        div()
            .text("How many counters would you like?")
            // .child(
            //     div()
            //         .child(pop_button(list.clone()))
            //         .text(Sig(list.signal_vec().len().map(|len| format!("{len}"))))
            //         .child(push_button(list.clone())),
            // )
            .child(hr())
            .child(div().children_signal(list.signal_vec().map(|_| define_counter()))),
    );
}

I would assume there should be a counter that is defined and initialized with 0. but it ends up only showing two buttons and the counter value between is missing.

Thank you!