Add useful methods to UseStateHandle & UseReducerHandle#3422
Add useful methods to UseStateHandle & UseReducerHandle#3422Madoshakalaka merged 4 commits intoyewstack:masterfrom
UseStateHandle & UseReducerHandle#3422Conversation
|
Visit the preview URL for this PR (updated for commit 987291a): https://yew-rs--pr3422-add-handle-methods-odfhugyl.web.app (expires Sat, 11 Apr 2026 10:42:08 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Benchmark - SSRYew MasterDetails
Pull RequestDetails
|
Size ComparisonDetails
✅ None of the examples has changed their size significantly. |
| /// Returns the inner value of the handle. | ||
| pub fn get(&self) -> Rc<T> { | ||
| // Safety: `UseStateReducer<T>` is `repr(transparent)` and only contains `T` | ||
| unsafe { transmute(self.inner.get()) } |
There was a problem hiding this comment.
Can we avoid the transmute somehow?
There was a problem hiding this comment.
not really, this transmute converts between Rc<UseStateReducer<T>> and Rc<T>, there's not much you can do with a value inside an Rc
There was a problem hiding this comment.
You would need to convert Rc<UseStateReducer<T>> -> Rc<T> (assuming T is not guaranteed to be Clone) some other way then (maybe via Any?). I think using repr(transparent) was a brilliant idea for Rcs and now I hope Rust makes it like a safe trait / Rc function.
futursolo
left a comment
futursolo
left a comment
There was a problem hiding this comment.
I am not in favour of this pull request.
We have discussed in some previous pull requests. How a state is stored should be an implementation detail. Not exposing this allows us to switch the underlying implementation at a later time.
e.g.:
To implement concurrent mode, we will need to have multiple schedulers and states need to be associated with a scheduler ID .
I am not exactly settled on how this would be associated.
This pull request rules out the following possibility.
struct UseStateReducer<T> {
inner: T,
scheduler_id: Id,
}
|
The PR does restrict the flexibility in implementation, but on the other hand, how likely is the implementation to change? The current approach works just fine, obtaining/setting the value doesn't require much indirection, and the new methods will allow for easier usage of non(-trivially)-clonable types in the aforementioned handle types. |
|
@futursolo Provide other solutions of being able to encapsulate/not clone
#[derive(Clone, ...)] // also ImplicitClone
struct UseStateValue<T> {
inner: Rc<T>, // using same `repr(transparent)`/`transmute` trick
}
impl Deref for UseStateValue<T> {
type Target = T;
...
}
Also possible that |
|
The medium case isn't good because oftentimes the value needs to be cloned after getting it out of the state, forcing T to be Clone when it can be avoided. It's either that or recreating the Rc that we just took the value out of. Yew playground has a component that suffers from this exact same thing today when attaching the change listener to Monaco editor Concurrent mode, when implemented, will most likely come with breaking changes of its own. I'd rather remove these methods then, providing a suitable alternative, than not add them in the first place |
|
Btw, just as an idea, the fact that those new methods return an Rc does not mean they lock us to one impl, even if we switch to an impl that'll make those structs contain just an interned ID, as long as there's a way to access the interned value, we will be able to provide it in an Rc, either by cloning the Rc if that's how the object will be stored, or by allocating it in an Rc, after which we'd add a warning to the docs of those methods regarding their perf implications |
- Renamed get() to value_rc() on both UseStateHandle and UseReducerHandle to avoid shadowing Deref targets that define their own get() (e.g. Cell, RefCell, Option). - Updated UseReducerHandle::value_rc() and into_inner() to work with the new current_state: Rc<RefCell<Rc<T>>> internals. - Reverted the no-longer-needed disambiguation in suspense/hooks.rs. - Added explicit transmute type annotations to satisfy clippy. - Updated timer_functional example to showcase into_inner(). - Added docs for value_rc() and into_inner() in en, ja, zh-Hans, zh-Hant.
Madoshakalaka
force-pushed
the
add-handle-methods
branch
from
174d139 to
e58d02d
Compare
Benchmark - coreYew MasterPull Request |
- The use_state_works test compared value_rc() against Rc::new(0), but value_rc() reads the live shared state which advances across re-renders. Changed to assert_eq!(*counter.value_rc(), *counter) which holds on every render. - Added hidden # import/component boilerplate to all code snippets in state.mdx (en, ja, zh-Hans, zh-Hant) so the website-test doctest harness can compile them.
|
Thanks for the PR @its-the-shrimp, and thanks to @ranile, @futursolo, and @kirillsemyonkin for the discussion. I've taken over this PR to rebase it onto current master and address the feedback. Here's what changed: Renamed The original Adapted to new Since this PR was opened, Addressing @futursolo's concurrent mode concern It's been over two years since the discussion about concurrent mode potentially requiring a Additional changes
|
…eHandle` & `UseReducerHandle` (yewstack#3422) * added (UseReducerHandle/UseStateHandle)::(value_rc/into_inner) * add docs * Updated timer_functional example to showcase into_inner().
5 participants
Description
This PR adds:
UseStateHandle::get&UseReducerHandle::getthat return the contained value of the handle in the form in which it's stored internally: in an Rc; These 2 methods will make it easier to work with non(-trivially)-clonable types in said containers;UseStateHandle::into_inner&UseReducerHandle::into_innerthat consume the handle and return its 2 main parts: the inner value and the setter/dispatcher associated with the handle. These methods will allow for avoiding cloning in certain contexts where one would have to useget()+setter()/dispatcher()otherwise.Checklist