Reduce the entity selector ajax response size

[cedric-anne]

Checklist before requesting a review

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

Partially fixes !41719.

The purpose of this PR is to drastically reduce the entity selector AJAX response size by:

• using common <form> tags, including _glpi_csrf_token and is_recursive inputs, to not repeat them for each entity;
• compact spaces to prevent sending too many extra spacing chars.

The response size could also be reduced by replacing the class attributes by dedicated CSS rules with precise CSS selectors, but I cannot afford enough time to this subject for the moment.

Another solution would be to use the renderTitle callback to remove the title from the response and generate it directly on client side. The response size would be really small, but I cannot tell if the title computation would be done for all nodes at once (with a risk of freezing the browser for some seconds), or would be done only when the corresponding node is visible in the virtual DOM viewport.

[orthagh]

Another solution would be to use the renderTitle callback to remove the title from the response and generate it directly on client side. The response size would be really small, but I cannot tell if the title computation would be done for all nodes at once (with a risk of freezing the browser for some seconds), or would be done only when the corresponding node is visible in the virtual DOM viewport.

This was the case initially in older versions, and I remember moving to get the full html response (simple links at the time) from AJAX to avoid client performance issue.

[cedric-anne]

Another solution would be to use the renderTitle callback to remove the title from the response and generate it directly on client side. The response size would be really small, but I cannot tell if the title computation would be done for all nodes at once (with a risk of freezing the browser for some seconds), or would be done only when the corresponding node is visible in the virtual DOM viewport.

This was the case initially in older versions, and I remember moving to get the full html response (simple links at the time) from AJAX to avoid client performance issue.

In GLPI 10.0, we switched from the JSTree to fancytree. Was the performances issues happening with fancytree or with the previous lib?

[orthagh]

It's a bit old in both case, but as both doesn't leverage a virtual Dom, I suspect it will be the same results regarding performance.

We may restart the work on #16617 by passing the json only, make the virtual part mandatory and implements AJAX loading on scrolling. I don't remember what @cconard96 at what point was on the PR

[cedric-anne]

It's a bit old in both case, but as both doesn't leverage a virtual Dom, I suspect it will be the same results regarding performance.

Are you sure of this? A comment in the code says the opposite.

glpi/templates/layout/parts/profile_selector.html.twig

Lines 168 to 173 in 79b0e60

	// enable virtual dom, it requires the grid (table extension) plugin
	table: {
	indentation: 20, // indent 20px per node level
	nodeColumnIdx: 0, // render the node title into the 1st column
	mergeStatusColumns: false,
	},

[orthagh]

Additional note, moving to a Vue component, we may not need anymore the Ajax loading. With the mentioned capacities (virtual dom, rendering on scroll), we may pass the JSON directly on load. Even with big tree (biggest customer I know have 100k entities), it should not be that big (1 big JSONcould be around 1 or 2 Mo) to be loaded directly.

[cconard96]

It's a bit old in both case, but as both doesn't leverage a virtual Dom, I suspect it will be the same results regarding performance.

We may restart the work on #16617 by passing the json only, make the virtual part mandatory and implements AJAX loading on scrolling. I don't remember what @cconard96 at what point was on the PR

The Vue implementation was working locally for me AFAIK but there had been some technical issues noticed on your side.

While looking at adding the selector in the Vue frontend I started to think about how to combine the entity and profile selectors since those selections are linked to give a better UX. Otherwise you can select an entity and have the server choose your new profile without your input. If you select an entity you dont have access to with your current profile, and you have multiple profiles for the entity, then it would ask you to choose. To be discussed? It may not fit with the desired UI design in the core.

[trasher]

As far as I know, we wera waiting for a customer feedback on this; I've not seen it for now.

[orthagh]

As far as I know, we wera waiting for a customer feedback on this; I've not seen it for now.

50Mb -> 28Mb
It's "better"

[cedric-anne]

As far as I know, we wera waiting for a customer feedback on this; I've not seen it for now.

🤷‍♂️

It will not fix the customer case, but it will still divide by 2 the weight of the request.

[trasher]

It will not fix the customer case, but it will still divide by 2 the weight of the request.

I had in mind he could have issues we do not see. Seems OK to me anyway, approved.

[cconard96]

As far as I know, we wera waiting for a customer feedback on this; I've not seen it for now.

50Mb -> 28Mb It's "better"

Just coming back to this now, but I added 100,000 entities to my GLPI to prepare to restart the Vue PR. I checked my Vue frontend for GLPI and it loads 5.7MB of data (compressed to 203kb) in 2.8 seconds with no noticeable delay between the response being received and the list loading. In GLPI, it runs out of memory even when I have a 2GB limit set. If I set a 8GB limit it just fails with a 503 error after 16 seconds, so I don't know how I can actually test this to get metrics on the GLPI side. However, my Vue frontend loads the entity data perfectly fine with the PHP memory limit set back to the original 128M I had it at before.

There seems to be a lot of gains to be had here by not server-side rendering.