pub struct Capsule<G: Html, P: Clone + 'static> { /* private fields */ }
Expand description
A capsule, a special type of template in Perseus that can also accept properties. Capsules are basically a very special type of Sycamore component that can integrate fully with Perseus’ state platform, generating their own states at build-time, request-time, etc. They’re then used in one or more pages, and provided extra properties.
Note that capsules store their view functions and fallbacks independently of their underlying templates, for properties support.
Implementations§
source§impl<G: Html, P: Clone + 'static> Capsule<G, P>
impl<G: Html, P: Clone + 'static> Capsule<G, P>
sourcepub fn build(template_inner: TemplateInner<G>) -> CapsuleInner<G, P>
pub fn build(template_inner: TemplateInner<G>) -> CapsuleInner<G, P>
Creates a new CapsuleInner
from the given TemplateInner
. In
Perseus, capsules are really just special kinds of pages, so you
create them by first creating the underlying template. To make sure
you get a capsule instead of a template, you just don’t call
.build()
on the template, instead passing the TemplateInner
to
this function.
Warning: TemplateInner
has methods like .view()
and
.view_with_state()
for setting the views of your templates, but you
shouldn’t use those when you’re building a capsule, because those
functions won’t let you use properties that can be passed from
pages that use your capsule. Instead, construct a TemplateInner
that has no views, and then use the .view()
etc. functions on
CapsuleInner
instead. (Unfortunately, dereferncing doesn’t work
with the builder pattern, so this is the best we can do in Rust
right now.)
You will need to call .build()
when you’re done with this to get a
full Capsule
.
source§impl<G: Html, P: Clone + 'static> Capsule<G, P>
impl<G: Html, P: Clone + 'static> Capsule<G, P>
sourcepub fn widget<H: Html>(&self, cx: Scope<'_>, path: &str, props: P) -> View<H>
pub fn widget<H: Html>(&self, cx: Scope<'_>, path: &str, props: P) -> View<H>
Creates a component for a single widget that this capsule can produce,
based on the given path. This is designed to be used inside the
Sycamore view!
macro.
Note that this will not behave like a normal Sycamore component, and it is effectively a normal function (for now).
The path provided to this should not include the name of the capsule
itself. For example, if the capsule path is foo
, and you want the
bar
widget within foo
(i.e. foo/bar
), you should provide
/bar
to this function. If you want to render the index widget, just
use /
or the empty string (leading forward slashes will automatically
be normalized).
sourcepub fn delayed_widget<H: Html>(
&self,
cx: Scope<'_>,
path: &str,
props: P
) -> View<H>
pub fn delayed_widget<H: Html>( &self, cx: Scope<'_>, path: &str, props: P ) -> View<H>
An alternative to .widget()
that delays the rendering of the widget
until the rest of the page has loaded.
Normally, a widget will have its state generated at the earliest
possible opportunity (e.g. if it only uses build state, it will be
generated at build-time, but one using request state would have to
wait until request-time) and its contents prerendered with the pages
that use it. However, sometimes, you may have a particularly ‘heavy’
widget that involves a large amount of state. If you’re finding a
certain page is loading a bit slowly due to such a widget, then you
may wish to use DelayedWidget
instead, which will generate state
as usual, but, when it comes time to actually render the widget in
this page, a placeholder will be inserted, and the whole widget will
only be rendered on the browser-side with an asynchronous fetch of
the state.
Usually, you won’t need to delay a widget, and choosing to use this over
.widget()
should be based on real-world testing.
Note that using other widgets inside a delayed widget will cause those other widgets to be delayed in this context. Importantly, a widget that is delayed in one page can be non-delayed in another page: think of widgets as little modules that are imported into pages. Delaying is just one importing strategy, by that logic. In fact, one of the reasons you may wish to delay a widget’s load is if it has a very large nesting of depdendencies, which would slow down server-side processing (although fetching on the browser-side will almost always be quite a bit slower). Again, you should base your choices with delaying on empirical data!