We commonly use IList<T> for such properties, just know that you miss out on personalization, permissions, and display options etc for each item.

Performance-wise it would have minor impact for rendering, but depending on requirements the IList<T> version could be faster for editors during publishing (fewer clicks).

The IList<T> approach may also be simpler for developers when implementing rendering, as the items are available without first having to filter and get the content for each content area item.

Hi Deepa,

I suspect there would be slightly better performance using a list property though that will depend on the implementation and, importantly, it comes with trade-offs.

If you create a property which is an IList<AccordionItem>, the data for each of the accordion items is stored serialised as part of the page so there are no furter calls required to get the data from a ContentReference which makes this probably the best performing of the options. The downside of this approach is that the content of the accordion items isn't reusable and you would need to put in extra effort to make the list neatly editable in on-page edit view. Additionally, PropertyList<T> properties are described as "unsupported" in the documentation. 

You could create the accordions using an IList<ContentReference> property which would resolve the issue of content reuse and, as I recall, is a supported property type however you'll now need to get the content for each ContentReference in order to render the item and, as with the first approach, you'll need to put in the effort yourself to ensure that the property renders nicely and is editable in the on-page editing view. In terms of performance, This could possibly be marginally better performing than a contentarea as you could potentially shortcut the template resolution process and you won't have the same filtering applied that you get with a ContentArea though I'm not convinced any performance gains would be that noticeable.

My personal preference would be to use a ContentArea for a few reasons, the main ones being:

• Content reuse - individual accordion items can be reused across different pages and blocks
• Editor experience - by using a content area you get the best on-page editing experience, even more so with the "quick edit" functionality in newer versions of the CMS
• Personalisation - with a ContentArea you can target content using visitor groups
• Flexibility - If needed, you can intersperse the accordion items with other content (e.g. headings, images, etc). You can also allow different display options to be chosen for each
• Maintainability - The ContentArea property type is fully supported and, if you need to change or extend your accordion item content model, that's much easier to manage for a block than for a type used in a PropertyList.

And, given the internal caching used when retrieving content from the CMS, I don't think the performance is much of a deciding factor.

We have used  IList<T>  extensively where contentarea with multiple blocks is not feasible.

Ex:

Guided Jourmey with Steps: https://www.michiganbusiness.org/services/entrepreneurial-opportunity/guided-journey/

Data Wizard: https://www.michiganbusiness.org/incentive-filter/

Blog Article: https://world.optimizely.com/blogs/ram-kumar-k/dates/2020/12/guided-journey--developing-a-wizard-component-using-episerver-cms/