0

I broke down bigger "Razor page" views into to "Partial" views.

From the main views I pass e.g. an image list to the partial view:

<partial name="/Partial/_ImageList.cshtml" model="ImageList" />

These partial views now starts to grow, and gets less simple/clean/readable.

So to solve that, I looked into doing something like this, in either the main or partial view:

foreach (var item in Model.ImageList)
{
    <partial name="/Partial/@item.some_property_view" model="item" />
}

With this I can have several smaller partial views, some also reusable cross different types of lists, instead of many if-then-else statement in a bigger view one.

To keep things simple/clean/readable, it appears (to me) this is the way to do it.

Given I have no long term experience with these things, and based on my own knowledge, where one learn about do's/dont's not found in any documentation;

  • Is there is anything else to consider, pros/cons when breaking down a bigger view to many smaller, that any of you ran into overtime?

My main concern is of course performance, though for a small number of items, 10-20, it likely wont matter, but will it if there are +200 items?...or at +1000?

I am aware of View Components, though I assume compiling many smaller of those, compared to Partial views, would have similar benefits/issues, but if not, please let me know.

Update

An ImageList item has about 5-8 properties, 1-2 is a header (50-100 characters each), 1-2 is a text (250-500 characters each), 1-2 is an image link and 1-2 is a hyperlink/anchor link.

Asons
  • 84,923
  • 12
  • 110
  • 165
  • 1
    If partial views are getting out of hand, looking into writing custom tag helpers. Tag helpers allow you to have any complexity of code and are very clean in your markup. – Jonathan Wood Jul 03 '22 at 06:23
  • @JonathanWood -- Thanks, I did, but I really need the templating functions, where I pass a model to be mapped to a HTML structure, where I can make use of "if-then-else" to select which element to be used, and with what value. – Asons Jul 03 '22 at 08:35
  • @JonathanWood -- Also, today I do some "home-made-mapping" using a HTML snippet and `string.Format`, though much more work to adjust when the model changes, and, given my system is a CMS solution, I can't reuse cross clients unless they both want the same properties. And start doing "if-then-else" in a tag helper seems to defeat its purpose...right? – Asons Jul 03 '22 at 08:46

1 Answers1

2

As you noted - rendering a large amount of items is not recommended on both client and server side.

Why?

  • Server Side - require high computing + networking resources for a single connection and may overload the entire solution
  • Client side - overload the DOM with too much of HTML elements - most of them are not even viewable by the user in a given moment

Because this is a known issue, there is a solution to solve it - virtual scroll (aka infinite scroll) - which is the "modern" way to do pagination. In this excellent article there is a comparison between "classic" pagination and "modern" virtual scroll (at least in terms of user experience)

To the point: Microsoft provides a built-in virtualization mechanism to assist you solve this problem with ease (no need to implement your own pagination mechanism). The docs also provide a simple example to assist you keep going (before and after virtualization)

Based on the code you share I assume that you will change your loop from this

foreach (var item in Model.ImageList)
{
    <partial name="/Partial/@item.some_property_view" model="item" />
}

to this

<Virtualize Items="Model.ImageList" Context="item">
    <partial name="/Partial/@item.some_property_view" model="item" />
</Virtualize>

Because I really don't know how much data you load into you ImageList and if you need to reduce the number of items there - please refer to this part of the documentation in order to have a better control over your pagination mechanism (by loading current "page" of items instead of virtualizing the entire data set)

Good luck!

ymz
  • 6,602
  • 1
  • 20
  • 39
  • Thanks, you made a good point here, bringing up `Virtualize` as an aspect. FYI, the "how much data into `ImageList`" is generally 10-20 items, that holds 5-6 properties each (will update my answer with that, as it might affect how to go about this), which likely is not make any noticeable performance hit, though, as I wrote, at what amount might it ? (+200, +1000, +...). – Asons Jul 10 '22 at 09:45
  • 1
    Thanks. to your question: as a rule of thumb - when you are getting more than 150 items you are entering a realm of high-loads. keep in mind to properly split your data into pages in order to better control loads and provide a better user experience (user will prefer to get partial but faster results then having to wait for a long period of time) – ymz Jul 10 '22 at 09:59