Struct dioxus_rsx::CallBody

pub struct CallBody {
    pub roots: Vec<BodyNode>,
}

The Callbody is the contents of the rsx! macro

It is a list of BodyNodes, which are the different parts of the template. The Callbody contains no information about how the template will be rendered, only information about the parsed tokens.

Every callbody should be valid, so you can use it to build a template. To generate the code used to render the template, use the ToTokens impl on the Callbody, or with the render_with_location method.

Fields

roots: Vec<BodyNode>

Implementations

impl CallBody

pub fn render_with_location(&self, location: String) -> TokenStream2

Render the template with a manually set file location. This should be used when multiple rsx! calls are used in the same macro

pub fn update_template<Ctx: HotReloadingContext>( &self, old: Option<CallBody>, location: &'static str ) -> Option<Template>

This will try to create a new template from the current body and the previous body. This will return None if the rsx has some dynamic part that has changed.

The previous_location is the location of the previous template at the time the template was originally compiled. It’s up to you the implementor to trace the template location back to the original source code. Generally you can simply just match the location from the syn::File type to the template map living in the renderer.

When you implement hotreloading, you’re likely just going to parse the source code into the Syn::File type, which should make retrieving the template location easy.

Note:

• This function intentionally leaks memory to create a static template.
• Keeping the template static allows us to simplify the core of dioxus and leaking memory in dev mode is less of an issue.

Longer note about sub templates:

Sub templates when expanded in rustc use the same file/lin/col information as the parent template. This can be annoying when you’re trying to get a location for a sub template and it’s pretending that it’s its parent. The new implementation of this aggregates all subtemplates into the TemplateRenderer and then assigns them unique IDs based on the byte index of the template, working around this issue.

TODO:

A longer term goal would be to provide some sort of diagnostics to the user as to why the template was not updated, giving them an option to revert to the previous template as to not require a full rebuild.

Trait Implementations

impl Debug for CallBody

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

Formats the value using the given formatter.

impl Default for CallBody

fn default() -> CallBody

Returns the “default value” for a type.

impl Parse for CallBody

fn parse(input: ParseStream<'_>) -> Result<Self>

impl ToTokens for CallBody

fn to_tokens(&self, out_tokens: &mut TokenStream2)

Write self to the given TokenStream.

fn to_token_stream(&self) -> TokenStream

Convert self directly into a TokenStream object.

fn into_token_stream(self) -> TokenStream

where Self: Sized,

Convert self directly into a TokenStream object.