Closed vldm closed 1 year ago
Thanks to @LLBlumire wildcards are now allowed in close tags, so it is now easier to use "blocks" in element name.
Currently wildcard is limited to already valid NodeName, so:
//this works:
<{"foo"}> </_>
//this doesn't:
<@{"foo"}> </ @>
Because there still might be needs for special puncts in element name place, i decide to keep this issue open for a while.
Probably one way to add custom punctuation support is to allow NodeName
extension through the config.
I would be interested in working something probably related, I need a custom syntax in the tag, in my case, I want to support <for variable in expr>
for for
loops. (I have similar ideas for if let, etc.
) these currently would only work with an additional brace around the expression, which I do not like.
This could probably be similar to custom blocks, though the parser supplied here has more responsibility, as it needs to terminate at the closing >
on its own, and it would either need to produce a valid NodeAttribute
, or OpenTag
requires direct support for storing plain tokens.
If you have an idea how you want this to be implemented, I'd be happy to contribute.
Maybe we could replace the syn::Block
in NodeName::Block
with a NodeBlock
, that way it could store arbitrary tokens, and a transform_tag
could just return Result<Option<NodeName>>
, if it is Ok(Some(_))
this is the value used for the OpenTag::name
, if it is Ok(None)
the tag will be parsed as a normal tag.
Alternatively, we could make OpenTag
an enum, but we already have the NodeName
enum, and I think it would work quite well.
(Perhaps we could even parse the remaining tokens in the tag as NodeAttribute
s, though I don't have a use case for that, and really only want to do fully custom tag syntax).
@ModProg hi, in my opinion it could be done by extending enum Node
.
Probably we can add variant KeywordElement
/BuiltinElement
with custom body.
And trait with methods:
peek_element(ParseStream)-> bool
parse_element(RecoverableContext, ParseStream) -> Option<KeywordElementInner>
So that adding new type of elements would be moved outside of rstml.
There is two challenges that need to be solved:
I guess a reasonable default would be Vec<Node>
being what NodeElement
's body is.
Another question, would this custom node necessarily be open tag, body, and optional closing tag, or should it be able to parse any syntax, i.e. even one not starting with <
.
Technically this is something that is already supported by reparsing RawText
, though a fully custom parser could probably do a bit more, i.e. allow usages of <
that would be invalid in normal raw text.
if we were to support the peeking to be called even without a leading <
, it could make sense to not have any NodeElement
releated types here, i.e. making the Variant Node::Custom(T =Infallible/!)
.
If we go with the fully custom node, I think it would make sense to expose part of NodeElement::parse_recoverable
to allow custom nodes to easily parse bodies and closing tags.
Yew support "Dynamic tag" https://yew.rs/docs/concepts/html/elements#dynamic-tag-names Which allows writing
Current implementation of
syn-rsx
, instead force you to write same code in following syntaxTo support yew syntax, we should extend transform_fn for blocks to also support outer punctuation.
Can be related to https://github.com/rs-tml/rstml/issues/8
To avoid duplication in current syntax (in open and closed tags), we can also avoid matching them if node_name has
Block
type, this allowing to support syntax like: