Struct dioxus_rsx::CallBody
source · pub struct CallBody {
pub roots: Vec<BodyNode>,
}
Expand description
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§
source§impl CallBody
impl CallBody
sourcepub fn render_with_location(&self, location: String) -> TokenStream2
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
sourcepub fn update_template<Ctx: HotReloadingContext>(
&self,
old: Option<CallBody>,
location: &'static str
) -> Option<Template>
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§
source§impl ToTokens for CallBody
impl ToTokens for CallBody
source§fn to_tokens(&self, out_tokens: &mut TokenStream2)
fn to_tokens(&self, out_tokens: &mut TokenStream2)
source§fn to_token_stream(&self) -> TokenStream
fn to_token_stream(&self) -> TokenStream
source§fn into_token_stream(self) -> TokenStreamwhere
Self: Sized,
fn into_token_stream(self) -> TokenStreamwhere
Self: Sized,
Auto Trait Implementations§
impl Freeze for CallBody
impl RefUnwindSafe for CallBody
impl !Send for CallBody
impl !Sync for CallBody
impl Unpin for CallBody
impl UnwindSafe for CallBody
Blanket Implementations§
source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
source§impl<T> Instrument for T
impl<T> Instrument for T
source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
source§impl<T> Spanned for Twhere
T: Spanned + ?Sized,
impl<T> Spanned for Twhere
T: Spanned + ?Sized,
source§fn span(&self) -> Span
fn span(&self) -> Span
Span
covering the complete contents of this syntax tree
node, or Span::call_site()
if this node is empty.