Expand description
An anchor can only be 1 or 2 levels deep as “type” and “text”.
The second level is optional and the Strings use the standard TryInto
for path Component
internally.
Anchors are required to be included in an application’s [ entry_defs
] callback and so implement all the standard methods.
Technically the Anchor
entry definition is the Path
definition.
e.g. entry_defs![Anchor::entry_def()]
The methods implemented on anchor follow the patterns that predate the Path module but Path::from(&anchor)
is always possible to use the newer APIs.
Fields§
§anchor_type: String
§anchor_text: Option<String>
Trait Implementations§
source§impl<'de> Deserialize<'de> for Anchor
impl<'de> Deserialize<'de> for Anchor
source§fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
source§impl From<&Anchor> for Path
impl From<&Anchor> for Path
Anchors are just a special case of path, so we can move from anchor to path losslessly. We simply format the anchor structure into a string that works with the path string handling.
source§impl TryFrom<&Anchor> for SerializedBytes
impl TryFrom<&Anchor> for SerializedBytes
§type Error = SerializedBytesError
type Error = SerializedBytesError
source§fn try_from(t: &Anchor) -> Result<SerializedBytes, SerializedBytesError>
fn try_from(t: &Anchor) -> Result<SerializedBytes, SerializedBytesError>
source§impl TryFrom<&Path> for Anchor
impl TryFrom<&Path> for Anchor
Paths are more general than anchors so a path could be represented that is not a valid anchor. The obvious example would be a path of binary data that is not valid utf-8 strings or a path that is more than 2 levels deep.