Struct perseus::template::Capsule

source ·
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>

source

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>

source

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).

source

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!

Trait Implementations§

source§

impl<G: Html, P: Clone + 'static> Debug for Capsule<G, P>

source§

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter. Read more

Auto Trait Implementations§

§

impl<G, P> !RefUnwindSafe for Capsule<G, P>

§

impl<G, P> Send for Capsule<G, P>

§

impl<G, P> Sync for Capsule<G, P>

§

impl<G, P> Unpin for Capsule<G, P>

§

impl<G, P> !UnwindSafe for Capsule<G, P>

Blanket Implementations§

source§

impl<T> Any for Twhere T: 'static + ?Sized,

source§

fn type_id(&self) -> TypeId

Gets the TypeId of self. Read more
source§

impl<T> Borrow<T> for Twhere T: ?Sized,

source§

fn borrow(&self) -> &T

Immutably borrows from an owned value. Read more
source§

impl<T> BorrowMut<T> for Twhere T: ?Sized,

source§

fn borrow_mut(&mut self) -> &mut T

Mutably borrows from an owned value. Read more
source§

impl<T> From<T> for T

source§

fn from(t: T) -> T

Returns the argument unchanged.

source§

impl<T, U> Into<U> for Twhere U: From<T>,

source§

fn into(self) -> U

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

source§

impl<T, U> TryFrom<U> for Twhere U: Into<T>,

§

type Error = Infallible

The type returned in the event of a conversion error.
source§

fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>

Performs the conversion.
source§

impl<T, U> TryInto<U> for Twhere U: TryFrom<T>,

§

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.
source§

fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>

Performs the conversion.