Relm4
Feedback on Relm4's view macro. #461
Replies: 4 comments 3 replies
-
|
Let's summarize the previous discussions about declarative and what features could be implemented in Relm4. Architectural changesDeclarative does not require a trait nor a built-in runtime for interactivity, whereas Relm4 requires you to use messages to modify state. The underlying code generation is not fundamentally different, but rather it is about where the code is put by the macro. Declarative (ab)uses Rust's attribute macros to do something like this: #[view { /* enter your widgets here */ }]
fn some_function() {
// This is still part of the macro
}This solves the problem that you need both the Instead, I would rather like to explore using different traits, maybe a even more reduced version of the old Syntax changesIf you use a Attributes are replaced by custom syntax or are instead written as lifetimes. The reduction of attributes makes the code look more elegant, but does not necessarily improve the readability. This alone should probably have it's own dedicated discussion and I don't have time to summarize everything, currently. In declarative, arguments are passed by specifying the method after the widget type and then using And also Conditional widgets++Conditional widgets (using Replacing synThis has nothing to do with the previous discussions, but I'd like to replace syn in the future. Syn still feels like a workaround even after years of development and has a lot of rough edges. To be fair, this has also to do with the limited APIs of the Rust compiler, but I think it's about time to challenge the status quo. I think a successor to syn should be more opinionated. Good macros should always have three stages: parsing, internal logic and code generation. Syn makes it possible to mix everything together, but parsing and code generation could be largely automated by macros and only the internal logic should be imperative code. Syn supports parsing files, but doesn't parse comments and blank lines which makes it basically impossible to build a formater for Relm4 without duplicating the parsing logic of the macro. Together with the automated parsing logic, it should be possible to define where you want line-breaks and offer formatting at almost no extra effort for the user. ConclusionThere is still a lot more to be discussed, but I don't have more time now, so feel free to complete this summary and share your thoughts! We might even need to split this discussion into smaller topics to keep track of everything in the future. |
Beta Was this translation helpful? Give feedback.
-
View syntaxThe use declarative::view;
#[view { /* widgets here */ }] // first view
#[view { /* widgets here */ }] // second view
fn function() { // or an impl
expand_view_here!(); // first view
let closure = || expand_view_here!() // second view
}Although normally a single view would be used.
I assume you figured this out by using Logically the use declarative::block as view;
fn function() {
view! { /* widgets here */ } // first view
let closure = || {
// `block!` (ie `view!`) is not autowrapped
// in braces like `expand_view_here!`
view! { /* widgets here */ } // second view
};
}Builder mode
Actually the For now I am not interested in making the marks the most visible (precisely I want to avoid the boilerplate) and that they make sense to those who do not know the macro (the examples are documented for a reason). I use Also builder mode not only avoids relm4::view! {
my_flap = adw::Flap {
set_flap_position: gtk::PackType::End
set_fold_policy: adw::FlapFoldPolicy::Never
#[wrap(Some)]
#[name(the_flap)]
set_flap = >k::Box {
// content
}
#[wrap(Some)]
#[name(the_content)]
set_content = >k::Box {
// content
}
}
}In declarative::block! {
adw::Flap my_flap {
set_flap_position: gtk::PackType::End
set_fold_policy: adw::FlapFoldPolicy::Never
gtk::Box the_flap #set_flap(Some(&#)) {
// content
}
gtk::Box the_content #set_content(Some(&#)) {
// content
}
}
}In declarative::block! {
adw::Flap my_flap !{
flap_position: gtk::PackType::End
fold_policy: adw::FlapFoldPolicy::Never
gtk::Box the_flap #flap(&#) {
// content
}
gtk::Box the_content #content(&#) {
// content
}
}
} // in this case there was no need to use #: #; @: or @;Attributes
Don't spend time on that either. While for Relm4 the attributes are just custom syntax, for declarative::block! {
adw::ApplicationWindow {
#[cfg(debug_assertions)] // real attribute
add_css_class: "devel"
gtk::Box #set_content(Some(&#)) {
set_orientation: gtk::Orientation::Vertical
#[cfg(feature = "with-sidebar")] // real attribute
adw::Flap sidebar #append(&#) {
// content
}
}
}
}You can see that I only add the I try to support attributes anywhere, which you can try by expanding the example z_besides (doc comments are attributes). If it happens to you that the attribute macro doesn't fully expand, you can try moving the content of the attribute to Composition and returns
Before everything In addition, However we have not taken into account the methods that return. To start the interpolation doesn't have to go after the widget declaration, but also inside the scope like so: gtk::Stack {
gtk::Box {
set_orientation: gtk::Orientation::Vertical
set_spacing: 6
#add_child(&#) // any position within the scope
adw::Bin #attach(&#) { }
}
}In gtk::Stack {
gtk::Box {
set_orientation: gtk::Orientation::Vertical
set_spacing: 6
#add_child(&#) 'back returned_page {
set_name: "page_name"
set_title: "Page title" }
}
adw::Bin #attach(&#) { }
}
}Currently in Relm4 I am forced to edit the return always at the end. More about Signals and cloning
In fact what is
For now I am not sure about cloning with brackets from the view macro so I dedicate a separate If you're curious, the struct of a component in Conditional widgets
Relm4's “reactive conditional” (or “dynamic case”) is really syntactic sugar for a How strange that Rust throws a warning because I use The project consists of examples, each suffixed with Now the interesting example is |
Beta Was this translation helpful? Give feedback.
-
|
Greetings. You will excuse the idiomatic errors since I use the translator a lot. I guess I'm correct in saying that while Relm4 focuses on giving more through more features, the So Eventually I will answer some issues with |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @ejaa3 for your comments! I wrote down some of my thoughts here, but I had limited time, so some ideas might not be complete yet. View syntaxI don't think Relm4 should use attribute macros like declarative does it. When looking at the rust lang reference, it becomes clear that attribute macros are supposed to work similar to built-in attributes and should have only few additional parameters (also, declarative even breaks syntax highlighting in some editors because nobody even considered the possibility to (ab)use macros like this). I don't know a single crate that does things differently except for the current version of declarative. Therefore, I think we should always wrap the macro around a trait implementation to avoid unidiomatic code, roughly something like this: #[some_view_macro(some_params)]
impl SomeTrait for Data {
view! {
// widgets...
}
fn some_method() {
expand_view_here!();
}
}Placing namesI think allowing to name widgets after the type like declarative and blueprint do it is a good idea. It removes the need for the name attribute and would also remove the old gtk::Box my_box {
gtk::Label my_label {
// ...
}
}Placing methodsRelm4's syntax is similar to Rust (struct initialization), JSON and blueprint which makes it easy for beginners to understand the macro and also makes it very consistent. Therefore, I don't like the old C-style of doing things in the opposite order and rather like to have the type after the method name. I think that the idea with the argument specification is really nice though. gtk::Box my_box {
append(&#) = gtk::Label my_label {
// ...
},
// It probably makes sense to add a shorter syntax and
// automatically add a reference because that covers at least 90% of all use-cases
append = gtk::Label my_label {
// ...
}
}Builder pattern syntaxI really like the idea of making it easier to use builder patters, but I'm still not convinced by the approach declarative uses. While waiting for my train, I thought of another interesting approach: We could just allow the user to return a builder type (or any other type) by using relm4::view! {
adw::Flap::builder() my_flap {
flap_position: gtk::PackType::End,
fold_policy: adw::FlapFoldPolicy::Never,
gtk::Box the_flap {
// content
},
gtk::Box the_content {
// content
},
// FlapBuider -> Flap
#build(),
set_flap_position: //...
}
}AttributesI don't have a lot of time, so I'll just write down my thoughts quickly. I think gtk::Box {
@update
set_margin_all: model.margin,
gtk::Label {
@update if let Some(text) = &model.text
set_label: text,
},
gtk::Label {
// Apply update to both properties
@update if model.update_label
> set_label: model.label,
> set_margin_all: model.label_margin,
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Well, here are some reasons why View syntax
I don't see it clearly. It just says “The first TokenStream is the delimited token tree following the attribute's name, not including the outer delimiters”, and that is exactly what the
The only way for a macro to “break” syntax highlighting is because it has hygiene issues. The hygiene information also allows for proper semantic highlighting, and in fact it is Relm4 who is breaking the syntax unlike
You may want to open the image in a new tab to see it larger (100 % zoom to avoid blur). I'm using VS Code and I have it configured to highlight methods in blue and modules in pink, but in Relm4 weird things happen (I point it with red arrows). The first problem is the arrow pointing to Of course, there is also non-semantic syntax highlighting, which is usually based on regular expressions. And an incomplete regular expression may fail to highlight a VS Code has both ways of highlighting: semantic and not, and I think the non-semantic uses regular expressions. And I found that non-semantics is poor when it comes to highlighting attributes like The point is that
Maybe no one knew that attribute macros were pretty powerful. Now with Wrapping in a traitI'm not sure. impl AnyThing for AnyType {
#[view {
// widgets
}]
fn function() {
expand_view_here! { }
}
}The same with a mod module {
#[view {
// widgets
}]
fn function() {
expand_view_here! { }
}
}I can also apply Placing methodsYou might find the gtk::Box box_name {
// this seems “consistent” with the `gtk::Box` above:
adw::Bin bin_name #append(&#) {
// content
}
}In addition, sometimes it will happen that the interpolation is long, like here. And I see better read this: gtk::Grid {
Child::new("Name", this.clone()) my_child {
#attach(&#.data.get().unwrap().0, 1, 2, 3, 4)
// properties
}
}Than this: gtk::Grid {
attach(&#.data.get().unwrap().0, 1, 2, 3, 4) = Child::new("Name", this.clone()) my_child {
// properties
}
attach( // or maybe so
&#.data.get().unwrap().0, 1, 2, 3, 4
) = Child::new("Name", this.clone()) my_child {
// properties
}
attach(&#.data.get().unwrap().0, 1, 2, 3, 4) // or so
= Child::new("Name", this.clone()) my_child {
// properties
}
}In gtk::Grid {
match variant {
Variant::Switch => Child::new("Name", this.clone()) {
#attach(&#.data.get().unwrap().0, 1, 2, 3, 4)
// properties
}
}
}You can see that the gtk::Grid {
match variant {
Variant::Switch => attach(
&#.data.get().unwrap().0, 1, 2, 3, 4
) = Child::new("Name", this.clone()) {
// properties
}
}
}Also Out of curiosity...I use the gtk::Box my_box {
#[first]
adw::Bin my_bin {
#[second]
#append(&#) // syn will send an error on `append`
'back returned { set_name: "name" } // suppose it returns
@gtk::Box::append(&#, &returned)
}
}Basically because it would expand like: let my_box = gtk::Box::default();
#[first]
let my_bin = adw::Box::default();
#[first] // outermost attributes apply internally
#[second]
let returned = my_box.append(&my_bin);
#[first]
#[second]
returned.set_name("name");
#[first]
// here #[second] does not apply because the @extension is not inside 'back
// however it did apply to `returned`, and that is a severe error
@gtk::Box::append(&my_box, &returned);If gtk::Box my_box {
#[first]
#[second]
adw::Bin my_bin {
// syn does not allow attributes for something starting with #
#append(&#) 'back returned { set_name: "name" }
@gtk::Box::append(&#, &returned)
}
}And now the That is, I take advantage of the fact that syn does not allow attributes for something that begins with Trimming syntax by 4 characters:
|
Beta Was this translation helpful? Give feedback.
-
Wrapping in a traitAt least to me it looks pretty clear that attribute macros are supposed to extend built-in attributes. And Rust's syntax for attributes is in fact very limited as the reference and the syn crate show. Just because we get a Therefore and also because there are no big downsides, I'd prefer a trait implementation or maybe we could actually use modules as well. Placing methodsIf I understand you correctly, there is no good reason against putting the method first. The idea of allowing the user to specify the interpolation within the bracket is pretty good as you demonstrated. Builder pattern syntax
No, the |
Beta Was this translation helpful? Give feedback.
-
Wrapping in a trait
If by that you tried to say that attribute macros are not supposed to have that much content, I think that's just your assumption.
I just read in the reference: “The attribute consists of a path to the attribute, followed by an optional delimited token tree whose interpretation is defined by the attribute” In The crate syn fits that. That is, the However I could think of implementing something like Placing methods
So you misunderstood me. I tried to say that there is no good reason in favor of putting the method before the type, except that it looks like Blueprint and JSON. And implementing both ways is just unnecessary maintenance. Builder pattern syntax
You know that because your eyes can see everything in braces as if nothing, but the macro doesn't know what's coming unless it unnecessarily constantly scans a lot of code ahead for a But there are even times where I don't even need to put a Now, from the start I didn't like the // the below cases expand to
adw::Bin::builder().margin_start(4).margin_end(4).build()
adw::Bin !{ // or adw::Bin::builder() !{
margin_start: 4 // chained
// first case: autocompletion
#margin_end: 4
// second case: no autocompletion
margin_end: 4
#:build;
// third case: autocompletion but expands at the beginning
#!margin_end: 4
// fourth case: no autocompletion but expands at the beginning
margin_end: 4
##build;
}The previous cases but with a child: // the below cases expand to:
adw::Bin::builder().margin_start(4).child(&_gtk_box).build()
adw::Bin !{
margin_start: 4
#gtk::Box #child(&#) { } // first case
gtk::Box #child(&#) { }
#:build; // second case
#!gtk::Box #child(&#) { } // third case
gtk::Box #child(&#) { } // fourth case
##build;
}The only difference between the first two cases and the last two is the position where they are expanded (sometimes it is necessary to place a builder at the beginning). The cases are ordered in descending order of usage probability, which is why I think those symbols are fine. |
Beta Was this translation helpful? Give feedback.
-
Please read #450 for context.
Beta Was this translation helpful? Give feedback.
All reactions