Luke
Luke
Right now, setting the `NodeRef`, either using the `.set()` method or automatically with `view!` doesn't trigger an update for `NodeRef::get()` Making `NodeRef` automatically reactive would be more ergonomic and better...
To make it more async/await even more ergonomic in sycamore, it should be possible to use async directly inside event handlers. Currently, we need to use `spawn_local_scoped` inside the handler...
**Describe the bug** Undefined behavior can occur in completely safe code when allocating a `Drop` type with `create_ref`. **To Reproduce** ```rust use std::cell::Cell; use sycamore::prelude::*; struct Foo Drop for Foo
The following code currently produces a stack overflow: ```ml type Foo a = | FooA a let f x = f (FooA x) ``` Polymorphic recursion is generally not allowed...
**Describe the bug** When navigating to a new page in the Book, there is sometimes what seems to be a race-condition which causes the following visual bug to happen: ...
This is the natural continuation of #354 and #553. We should strive to make Sycamore's elements system 100% type-checked for maximum type-safety and IDE auto-completion goodness. The main thing that...
The current split is a bit confusing and not very useful. It would be better to merge `HydrateNode` back into `DomNode`. The hydration-specific functionality can still be feature-gated to not...
Finally, after having gone through a v3 version of our reactivity system with #612, it is time we rework the view system. This PR eliminates `GenericNode` that was introduced all...
**Describe the bug** Using `#[component(inline_props)]` does not properly account for using patterns in function parameters. **To Reproduce** ```rust #[component(inline_props)] fn Foo(mut value: i32) -> View { view! {} } ```...
Sometimes, the generated prop type needs to implement additional traits which can be derived using a derive macro. This arises in, e.g. [mdsycx](https://github.com/lukechu10/mdsycx) where the props type needs to derive...