search

framesurge / perseus

A state-driven web development framework for Rust with full support for server-side rendering and static generation.
https://framesurge.sh/perseus/en-US
MIT License
2.15k stars 89 forks source link

Suspense fails #225

Closed arctic-hen7 closed 1 year ago

arctic-hen7 commented 1 year ago

Discussed in https://github.com/framesurge/perseus/discussions/187

Originally posted by **afidegnum** September 14, 2022 I have introduced the dynamic block using [transitions](https://github.com/afidegnum/sycatest/blob/master/src/main.rs) into[ the component ](https://github.com/commune-org/linksapp/blob/main/src/components/index_hero.rs) and I'm facing the following perseus compilation error: ``` warning: `linksapp` (bin "linksapp") generated 11 warnings Finished dev [unoptimized + debuginfo] target(s) in 51.78s Running `dist/target_engine/debug/linksapp` thread 'main' panicked at '`spawn_local` called from outside of a `task::LocalSet`', /home/afidegnum/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/task/local.rs:316:25 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` What could be the cause?
github-actions[bot] commented 1 year ago

This repo is set up to triage issues with Tribble, but this issue couldn't be processed. If you deliberately didn't use Tribble to report this issue, you can safely ignore this warning. If you did, something's gone wrong here.

arctic-hen7 commented 1 year ago

Investigating this further, Perseus is actually respecting Sycamore's scope boundaries perfectly, and the structure of the render core in Perseus makes it impossible to do anything else (we have to call those functions with a Scope anyway). The problem here seems to be, from a quick RUST_BACKTRACE=1, that Tokio doesn't like the fact that Perseus builds everything in parallel. It seems to be that that is somehow causing this error.

@lukechu10 can you shed any light on why this might be in terms of Sycamore's internals?

arctic-hen7 commented 1 year ago

The most obvious temporary solution to this would be to create a Perseus wrapper for Suspense that just renders the loading state on the engine-side, since I'm willing to call that a Suspense should never be evaluated on the engine-side (the state platform replaces that).

afidegnum commented 1 year ago

ok, The issue is still not resolved from my end.

arctic-hen7 commented 1 year ago

@afidegnum yes, I've just been postulating a fix. It's non-trivial to fix this at the moment, since Perseus' build system seems to render this impossible right now. I imagine there is a way to fix this, but I haven't gotten around to it yet. It should be done by the next release.

arctic-hen7 commented 1 year ago

Okay, #242 introduces proper suspended state in Perseus' state platform, which provides a more Perseus-y way to achieve this, without needing to use Sycamore's Suspense component. This will be closed once that PR is merged!