Invoice list modes

[dennisreimann]

Proof of concept and WIP — putting this out here to invite discussion and ideas for something that was wished for by @dergigi: Having the ability to quickly scan the invoices list and see the LNURL/Value 4 Value info, without having to toggle the details.

This POC introduces the concept of "view modes" for the invoices list, which can be toggled ­— similar to what an OS offers in the Finder/Explorer. Would need more UI tweaks and also technical refactoring, but this WIP state can be used to discuss the idea in general.

[dergigi]

Oooh, I love it! Thank you! 🧡

Any suggestions in regards to naming the various views? I'm not against the "V4V" label at all, but maybe something that delineates along easier to understand use-cases would make sense as well? Something like "Merchant" view vs. "Donation" view, or something like that. Could also have a 3rd one: "Messages", which would filter for comments only, so you'd have a spam-less DM system based on lightning addresses. (Should probably be a filter, just like "settled invoices" is a filter.)

Just spitballing here 😅

Once more: thank you for working on this! Soooo good 🤗

[dennisreimann]

I think in the end it'd be best to have icons or maybe rethink how to ideally present these. My mental model for that is something like this:

One more thing to figure out when we get to redesign the invoices list – @dstrukt has mocks already, but this mode concept hasn't been discussed yet, so I wanted to put it out there, because imho it makes sense to assess it.

[dergigi]

I like it! Could be [ List / V4V / Mail ] for the use-cases described above (V4V being top-up invoices aka donations).

[dstrukt]

Love the idea, and tend to agree, icons (with a potential label on hover) probably make the most sense, and as we start to add more to these views, is a reasonable method to handle these cases.

Definitely a few things to discuss with the larger invoice list view, but think what you guys are proposing here is great!

[woutersamaey]

Having more control over the invoice grid is good, but I think we need to do more so that plugins can also add custom columns to grid for example. This means grids should become models with classes for columns and renderers, not just plain templates.

[dstrukt]

Interesting @woutersamaey do you mind walking through a plugin use-case?

Might be out of scope for this PR, but would be curious to hear some details to make sure I'm grasping the scope of what you're suggesting.

[dstrukt]

Pinging @woutersamaey .. mind elaborating?

[woutersamaey]

Yes. Sure.

For example, suppose I have a plugin that auto-forwards the invoice payment to another address. This would be a per-invoice action so it would be handy to have an extra column on the invoice list page where I can see the forwarded to address, the forwarded amount, maybe some status, etc.

Same could be for auto-converting to fiat. Having an extra column on the invoice list that shows that status would also be nice.

It could also be simpler. Maybe I just want a column with some metadata field in there like the customer ID or some other column we don't have right now.

Same goes for all grids/lists basically.

The eCommerce software I work with during my day job has this kind of functionality. Columns can be added, moved, removed, sorting options can be added, different filter styles (i.e. search for text match in a column, but could also be from and to date if it's a datetime column).

Hope this helps give you some ideas of where grids/lists can go in tbe future.

For now the only option we have is to create a new page in the plugin and make our own (mostly copy-pasted) grid/list.

[Sjors]

Nice! I would perhaps drop the invoice ID column to make more room for the comments. It's also nice to have a filter to get only the invoices with comments.

I assume this already filters out invoices that are not v4v/boost/zap related?

[Carolynmaspn]

[dstrukt]

Will revisit this now that #4914 is about to be merged!

[id81214293-del]

I don't understand

[dennisreimann]

Closing this as it'll most likely need to get reimplemented, but it served as a useful prof of concept and kick-off for the discussion. Something we can maybe revisit in one of the upcoming releases, @dstrukt.