Hangman updated - Critisisms should be fixed

[agreyyy]

I didnt know how to convert the way I used use_memo into a use_effect, so only that hasnt been fixed.
The Hangman component has been simplified to be super simple and not over engineered like before. But I think this one should be good now. Also I added a small README.

[agreyyy]

idk how git works rn and I blew up the original branch by accident sorry.

[ealmloff]

Instead of a reset flag and a use memo, you could move the key_states hook into the parent component and pass it down to this component. Then when you currently set the reset flag, you can just set key_states directly:

fn Home(cx: Scope) -> Element {
    let key_states = use_ref(cx, || {vec![ vec![false;10], vec![false;9] , vec![false;7]]});
    // ...
        KeyBoard {
            // This will clone by ref so it is cheap
            key_states: key_states.clone(),
            // ...
        }
        // ...
        button {
            class: "play-again",
            disabled: !*game_ended.get(),
            onclick: |_| {
                key_states.set(vec![vec![false;10], vec![false;9], vec![false;7]]);
            }
        }
}

pub fn KeyBoard<'a>(cx: Scope, onguess: EventHandler<'a, char>, key_states: UseRef<Vec<Vec<bool>>>, disable_all: bool) -> Element<'a> {

[agreyyy]

Should be good now. I didn't know you could directly pass UseStates and UseRefs to components, thanks for showing me that.

[ealmloff]

It looks like there are some conflicts between the different examples in the repo. You may need to bump the rest of the examples to dioxus = 0.4

[agreyyy]

It looks like there are some conflicts between the different examples in the repo. You may need to bump the rest of the examples to dioxus = 0.4

What does that mean, are all of the other examples except for mine out of date?

[agreyyy]

Do any of them actually need changes internally, or does each individual Cargo.toml needs to be updated to have
dioxus-deskotp = 0.4.0?

[ealmloff]

Do any of them actually need changes internally, or does each individual Cargo.toml needs to be updated to have
dioxus-deskotp = 0.4.0?

I think they just need the number changed to 0.4.0. If they need more than that, I can take a look at updating them

[marc2332]

Yeah, we should update the other examples to 0.4, #37

[agreyyy]

I think we can use the dependancy = { git = git repo adress } syntax inside the Cargo.toml to have them auto update.

[agreyyy]

I think we can use the dependancy = { git = git repo adress } syntax inside the Cargo.toml to have them auto update.

This way, we wont have to change the versions of all the dioxus-based dependancies, when they go out of date. maybe it can be a rule for any new entries into the examples repo to have all their dependancies laid out like this so this issue can never arise again? Idk how else to get Cargo.toml to auto update stuff, i think there might be another way.

[ealmloff]

I think we can use the dependancy = { git = git repo adress } syntax inside the Cargo.toml to have them auto update.

This way, we wont have to change the versions of all the dioxus-based dependancies, when they go out of date. maybe it can be a rule for any new entries into the examples repo to have all their dependancies laid out like this so this issue can never arise again? Idk how else to get Cargo.toml to auto update stuff, i think there might be another way.

Because the example projects are in a different repo, they have a locked dioxus version. The git version of Dioxus will eventually have breaking changes. I think it is better to keep this repo working in some version of Dioxus rather than automatically updating the version and breaking the examples.

The other alternative is moving this repo into the main Dioxus repo (#25) and switching to the git version of Dioxus. This would mean that the examples are constantly checked against the new breaking changes and kept up to date

[agreyyy]

I think we can use the dependancy = { git = git repo adress } syntax inside the Cargo.toml to have them auto update.

This way, we wont have to change the versions of all the dioxus-based dependancies, when they go out of date. maybe it can be a rule for any new entries into the examples repo to have all their dependancies laid out like this so this issue can never arise again? Idk how else to get Cargo.toml to auto update stuff, i think there might be another way.

Because the example projects are in a different repo, they have a locked dioxus version. The git version of Dioxus will eventually have breaking changes. I think it is better to keep this repo working in some version of Dioxus rather than automatically updating the version and breaking the examples.

The other alternative is moving this repo into the main Dioxus repo (#25) and switching to the git version of Dioxus. This would mean that the examples are constantly checked against the new breaking changes and kept up to date

It might be better to keep the examples always up to date with the latest breaking changes though in my opinion. This might mean that there will be less examples inside the repo, but it will make sure that people who come to learn dioxus through looking at the examples are learning usable information (code that is not out of date). Plus as Dioxus matures, there will be less breaking changes over time, right?