Help converting examples from `nightly` to `stable` about leptos HOT 6 CLOSED

Just curious, wouldnt it be better to have both? Personally I always use nightly because I like not having the .get() or .set() syntax (and I can use stuff like the parallel frontend in the compiler) but I understand why its a good idea to show that it works fine in stable, so why not keep both?

But yeah, I think I can take care of the hackernews examples and maybe some of the counter ones

from leptos.

Personally I always use nightly because I like not having the .get() or .set() syntax (and I can use stuff like the parallel frontend in the compiler)

Me too, which is why it's been the default until now.

but I understand why its a good idea to show that it works fine in stable, so why not keep both?

My main concern is actually CI-related. We have not had many problems until fairly recently, but the instability of nightly APIs means that occasionally, things break and need to be fixed in CI in ways that can be confusing for people trying to use the examples.

One small case study that prompted me to open this: A few months ago, we found that rkyv was throwing clippy warnings on new nightly versions, which was breaking our CI during cargo check on leptos_reactive featurs that pulled in rkyv. I probably should've investigated more deeply at the time (it turns out just disabling the copy feature on rkyv would've fixed it) but we just pinned to a nightly version that worked, instead.

Then some time in the last few weeks, an Axum patch update was released that was only compatible with more recent nightly compilers — but rkyv still wasn't. This meant we were in an uncanny valley where there was no nightly version of the compiler that could actually cause our CI to pass. I ended up spending a few hours of my day yesterday just dealing with the consequences of that combination and updating to a new nightly.

Ultimately this stuff is just a pain, and it will continue to be a pain as long as we have nightly examples that we're running CI against — hence why I'd rather replace them than just add more stable examples.

But yeah, I think I can take care of the hackernews examples and maybe some of the counter ones

Thanks!

from leptos.

Okay, I'll work on error_boundary.

from leptos.

My main concern is actually CI-related. We have not had many problems until fairly recently, but the instability of nightly APIs means that occasionally, things break and need to be fixed in CI in ways that can be confusing for people trying to use the examples.

One small case study that prompted me to open this: A few months ago, we found that rkyv was throwing clippy warnings on new nightly versions, which was breaking our CI during cargo check on leptos_reactive featurs that pulled in rkyv. I probably should've investigated more deeply at the time (it turns out just disabling the copy feature on rkyv would've fixed it) but we just pinned to a nightly version that worked, instead.

Then some time in the last few weeks, an Axum patch update was released that was only compatible with more recent nightly compilers — but rkyv still wasn't. This meant we were in an uncanny valley where there was no nightly version of the compiler that could actually cause our CI to pass. I ended up spending a few hours of my day yesterday just dealing with the consequences of that combination and updating to a new nightly.

Ultimately this stuff is just a pain, and it will continue to be a pain as long as we have nightly examples that we're running CI against — hence why I'd rather replace them than just add more stable examples.

Yeah, CI breaking because small issues at random due to breaks in nightly can become a huge pain when piled on, I get why you would want to move it and after converting a few examples, aside from having to move errors into closures tbh it wasnt that different

from leptos.

I'll work on counter_url_query

from leptos.

Thanks to everyone for contributing! I think this is all of them. Much appreciated ❤️

from leptos.