[wip] Display object module

[damirka]

• Full proposal text is here: https://forums.sui.io/t/nft-object-display-proposal/4872
• Adds the sui::display module which allows setting a display for the T by the publisher of the T

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
explorer	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 22, 2023 at 8:14PM (UTC)
frenemies	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 22, 2023 at 8:14PM (UTC)
wallet-adapter	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 22, 2023 at 8:14PM (UTC)

1 Ignored Deployment

Name	Status	Preview	Comments	Updated
explorer-storybook	⬜️ Ignored (Inspect)			Feb 22, 2023 at 8:14PM (UTC)

[Suficio]

This sounds like a great initiative and is a big step forward for display standards in SUI!

I would like to structure my feedback in two, how this structure affects OriginByte NFTs and perhaps proposing an alternative approach.

Displaying OriginByte NFTs thus far works based on DisplayDomain which contains the bare name and description fields. There are additional domains such as UrlDomain which allow more composability of display properties.

A collection using OB NFTs does not have to use these domains and may opt to instead provide its own methods of storing display information. Since domains are indexed by type, not string, and are dynamic objects, I'm not sure if this proposal will allow for indexing into them like so: {DisplayDomain.name}. This is not a deal-breaker as we can always provide these fields in the core Nft type.

In the same vein, will dynamic fields with string keys be supported for this indexing?

As I mentioned initially, we would like to propose an alternative approach.

Since Display in essence provides a struct that provides a "view" into the object, here at OriginByte we were wondering if there are alternative ways to make that happen.

An initial solution that comes to mind is allowing entry functions (or view functions) to return view structs that contain fields otherwise available in the Display VecMap. For OriginByte, this would allow collection creators to define such a view function that would serialize all of their fields of interest. In a more general view it enables creators more flexibility to implement just in time transformation of their data.

These view functions would run immutably and be limited in complexity, and be run on the same module that would otherwise populate the template fields in Display<T>.

[damirka]

Hey @Suficio! Thank you for your feedback. I've replied on the Sui Developers (link to the reply).

Hopefully this answers all of the topics raised in your question, please feel free to disagree or ask if anything is unclear.

[jovicheng]

@damirka Hi, is there any update regarding template syntax (df or dynamic_field_key)?

[damirka]

Hey @jovicheng. We're at full capacity already; more updates will be coming next year. But yes, df and vectors and a lot more will be there!

[jovicheng]

Hey @jovicheng. We're at full capacity already; more updates will be coming next year. But yes, df and vectors and a lot more will be there!

Thank you for your reply. I would like to confirm again, currently, this feature is not supported, correct?

[damirka]

@jovicheng

I would like to confirm again, currently, this feature is not supported, correct?

Correct, you can't fetch dynamic fields just yet.

[jovicheng]

@jovicheng

I would like to confirm again, currently, this feature is not supported, correct?

Correct, you can't fetch dynamic fields just yet.

thanks, looking forward to this new features."