yewstack / yewtil Goto Github PK

Rc and Weak can already be used to share state between parent and child, but the semantics are a little messy.

If you disallow cloning the Rc, you can allow safely dereferencing to &mut T (which will also break weak ptrs, but that's fine, because you are about to re-render anyway)
Likewise, you can safely allow Rc to safely dereference to &T .

Wrapping these types and enforcing these invariants can allow a more ergonomic and hard to break shared pointer use within Yew.

The master branch of this project tracks the current version of yew. It would be nice if there could exist another branch that tracks yew's current state.

I get the following error trying to run the Fetch example:

error[E0433]: failed to resolve: could not find `fetch` in `yewtil`
 --> examples/fetch_demo/src/main.rs:3:13
  |
3 | use yewtil::fetch::fetched::Fetched;
  |             ^^^^^ could not find `fetch` in `yewtil`

error[E0433]: failed to resolve: could not find `fetch` in `yewtil`
 --> examples/fetch_demo/src/main.rs:4:13
  |
4 | use yewtil::fetch::unloaded::Unloaded;
  |             ^^^^^ could not find `fetch` in `yewtil`

error[E0432]: unresolved import `yewtil::fetch`
 --> examples/fetch_demo/src/main.rs:5:13
  |
5 | use yewtil::fetch::{Fetch, FetchState};
  |             ^^^^^ could not find `fetch` in `yewtil`

error[E0433]: failed to resolve: use of undeclared type or module `Fetched`
  --> examples/fetch_demo/src/main.rs:37:47
   |
37 |                 <Fetched<String, Msg>  render=Fetched::render(|s| html!{
   |                                               ^^^^^^^ use of undeclared type or module `Fetched`

error[E0412]: cannot find type `Fetched` in this scope
  --> examples/fetch_demo/src/main.rs:37:18
   |
37 |                 <Fetched<String, Msg>  render=Fetched::render(|s| html!{
   |                  ^^^^^^^ not found in this scope

error[E0412]: cannot find type `Unloaded` in this scope
  --> examples/fetch_demo/src/main.rs:42:18
   |
42 |                 <Unloaded<Msg>>
   |                  ^^^^^^^^ not found in this scope

was there code missing from this commit? thanks for the work you've done on yew 🙂

There may be utility in creating an Rc-like pointer that when calling as_mut or other mutating functions, does not clone the value it points to to ensure unique ownership. The invariant that would need to be upheld is that no references could be held to values owned by the ptr. Because of Yew's distaste for component lifetimes other than 'static, this may already be impossible to violate within expected operation of Yew.
Nonetheless, any mutating function that would otherwise clone in Mrc should be marked as unsafe to indicate that that particular invariant must be upheld. This would have impacts on ergonomics, but this sort of ability shouldn't be used in application code, and would find its use in component libraries as an optimization invisible to the outside world.

Allow deriving components for functions.

With https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#attributes-on-function-parameters, it should be possible to ferry attributes like #[props(required)] from function parameters to a derived props struct.

This could look like:

#[derive(FunctionComponent)]
#[fn_comp_name(ShowThing)]
#[fn_comp_memo] // actively memoize the inputs.
fn show_thing<T: Component>(
    #[props(required)]
    callback: Callback<()>
) -> Html<T> {
    ...
}

Because ComponentLink is now Cloneable, support for futures can be moved out of Yew proper and into this crate instead.

Additionally, this would be a good opportunity to support send_future_batch as well.

This is based on discussion within the following issue:
yewstack/yew#742.

The CI script from yew_router should be a good place start.

Not everything in this crate will be ready for people to use from the start. Newer, unfinished or unvetted items can be kept behind a feature flag, while older and more stable items will be available by default.

Feature flagging every feature might be useful as well. Given that this crate represents a hodge-podge of different ideas, it would be nice for people to be able to select exactly what they want, even excluding stable features.

Something like:

default = ["stable"]
stable = ["feature1", "feature2", "feature3", "etc..."]
experimental = ["feature4", "feature5"]

feature1 = []
# etc...

Currently, the FetchState object represents Get requests really well.
But for Put/Post requests, where some item is held, even during Fetching and Failure cases, the current FetchState does not accommodate this.

Instead we probably need:

// naming need some work...
pub enum UnifiedFetchState<T> {
    NotFetching(T),
    Fetching(T),
    Fetched(T),
    Failed(T, FetchError)
}
//and
pub enum DifferingFetchState<T,U> {
    NotFetching(T),
    Fetching(T, Option<U>),
    Fetched(T, U), // U is a type different than the type that was sent.
    Failed(T, Option<U>, FetchError)
}

This still leaves out the situation where we first must get the value before editing and sending it off, which might use something like: UnifiedFetchState<FetchState<_>> at the moment, but some other enum type might be provided later to handle this case.

Create a Monad / Component pair: FetchState, and Fetch respectively.

The end render code should look like:

html! {
    <Fetch<Data> state = self.fetch_state >
        <FetchSuccess render = |data| html!{data} />

        <FetchNotStarted>

        </FetchNotStarted>

        <FetchLoading>

        </FetchLoading>

        <FetchFailed render = |error| html!{error}/>
    </Fetch>
}

Add a trait where you can specify method, headers, etc... for a given type (the request)
Have an associated type to indicate the response.

A send_fetch_request function that takes an implementer of that trait as an argument and returns a future that returns the associated response type.

Add a struct that stores values in a Vec where the tail element of the vec represents the most recent change.

Notable methods could include:

• forget - drop all elements except the last element.
• reset - drop all elements except the first element.
• dirty - returns true if the len of the vec > 1. (maybe a specific value could be used to mark this)
• make_older - deletes the current last element (???)

Maybe a VecDeque might be a better underlying data structure. That would allow the first element to efficiently represent the "current" value.

Currently, the Emissive derive macro only finds the first field with type Callback<_> and uses that to write the emit function. It should also look for Option<Callback<_>> and write a slightly different emit function that checks if the option is some first.

There is currently a nightly feature for then and then_with functions on bools that allow them to be turned into Options using a provided value or closure.
This in conjunction with unwrap_or_default can be used to easily write "show this html or nothing" sections.

A stable shim trait for this could be added to this crate, have it live in experimental, and then remove it once the actual feature stabilizes.

https://doc.rust-lang.org/std/primitive.bool.html#method.then_with

The trait itself is gone, but references to it are made on the Readme.md and the macro used for deriving it still exists.

Those instances and any other item mentioning it should be removed or corrected.

• NeqAssign - Works as intended
• PureComponents - Ideally they would be used as memoizied functions with a nicer calling convention inside the html! macro. Unfortunately, their application in the case of nested/wrapper components (children) is not feasible, as issues mentioned in yewstack/yew#738 make it any sort of non-display task impossible. It needs child -> grandparent callback handling in order to be useful in the majority of cases.
• Irc/Mrc - Nice, but can't be used in some situations due to a lack of Default impls.
• Lrc - I refer to this smart pointer as "cursed". It is capable of spooky, action at a distance mechanics, and while I think its a very nice and and well thought out piece of code, it mostly serves to enable anti-patterns in user code. Maybe it has some utility in rare cases, but it probably isn't common enough to keep it in a project for "common utilities" for Yew projects.
• History - No comment
• DSL - Too incomplete to be used at the moment.
• WithCallback - Haven't found a use for it yet, and its restrictions due to orphan rules makes it less useful than ideal.