all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>, yew-devel@lists.proxmox.com
Subject: Re: [PATCH yew-widget-toolkit v2] widget: add 'div' macro
Date: Tue, 7 Apr 2026 09:48:44 +0200	[thread overview]
Message-ID: <374a3e86-a0c7-445e-8999-d16e547cdf4a@proxmox.com> (raw)
In-Reply-To: <3570c013-8109-45cb-a054-7072fcea559e@proxmox.com>



On 4/5/26 11:07 AM, Thomas Lamprecht wrote:
> On 02/04/2026 15:43, Dominik Csapak wrote:
>> this is just a simple wrapper around the `Container` widget, but it's
>> very useful in situations where bare strings are used in a flex layout,
>> since e.g. a `Row` with multiple children that are all strings won't get
>> a proper flex layout (since they're not elements)
>>
>> So instead of writing
>> ```
>> Row::new()
>>      .with_child(Container::new().with_child("Text1"))
>>      .with_child(Container::new().with_child("Text2"))
>> ```
>>
>> one can now write
>> ```
>> Row::new()
>>      .with_child(div!("Text1"))
>>      .with_child(div!("Text2"))
>> ```
>>
>> which is much shorter and more readable.
> 
> Yes, but why a macro and not a normal method for this? Macro's are a bit
> opaque, totally fine if there is a benefit for adding them, but here I
> cannot see a big blocker against adding an e.g. TextContainer wrapper or
> an Container::new_with_text (might need better naming, but just to relay
> the idea), especially if that's your main use case. Or for a more generic
> use case we could add a "Container::new_with_child" constructor or also
> a wrapper type (SimpleContainer::new(child)).

it was just the shortest thing i could come up with.
I think the alternatives all don't really save much text vs the original
'Container::new().with_child()'

but if we really don't want to use a macro for this, i could live
with something like

Container::with(...)

or

Container::text(...)

or something like this.

the advantage of the macro was also the possibility to have multiple
elements with very little syntactic overhead (did not go into detail
here in the commit message to be fair)

> 
> And it isn't exactly a plain div, as then one could just use the html!
> macro from yew, so the name as is, is IMO not totally ideal. If we go
> the macro way (what's Dietmars opinion on this?), I'd favor to call it
> container! to better reflect that it uses the pwt container class.
actually it's exactly like a 'div' by default. we just have some
convenience traits built on top.

I think Dietmar also prefers a non-macro way, so i'd send another
patch if one of the methods above would be ok for you.




  reply	other threads:[~2026-04-07  7:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02 13:42 Dominik Csapak
2026-04-05  9:08 ` Thomas Lamprecht
2026-04-07  7:48   ` Dominik Csapak [this message]
2026-04-07  8:49   ` Dietmar Maurer
2026-04-07  9:13     ` Thomas Lamprecht
2026-04-07 13:12 ` superseded: " Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=374a3e86-a0c7-445e-8999-d16e547cdf4a@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    --cc=yew-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal