[Live] Rendering a list of nested components

[StrahilRuychev]

Live Components version 2.5
In the parent component I am rendering a list of translation objects inside a table with a table row for each translation. Inside each row, in one of the td elements I am rendering a child component that implements functionality to edit the text property of the translation object.
The parent component has a form with several fields to search for specific translations on top. All of these fields have data-model attributes and cause the parent to re-render and thus refresh the list.
When the list is refreshed, there are sometimes child components with empty content.
Example:

Here is the list after entering a couple of more symbols in the search field:

[weaverryan]

Hi @StrahilRuychev!

A lot of under-the-hood changes occurred with live components 2.5, so this is most certainly a bug. Question: is the child element normally attached to the <td>? Or is it attached to the <div> inside the <td> (as shown in the screenshot)? Also, do you have any JavaScript errors?

Thanks!

[StrahilRuychev]

Hi @weaverryan
The child component is attached to a div which is inside a td element.
No JavaScript errors that I can see.

[weaverryan]

Thank you! If you're able to build a reproducer repository, that would be very helpful. Otherwise, I will try to build one soon so that we can dig into the root problem.

[StrahilRuychev]

@weaverryan Hi,
here you are:
https://gitlab.com/straho99/translations-demo

One more question. With version 2.5 I get way more ajax requests than with version 2.4. Before I had only one request to update the parent component. Now I get one ajax for the parent, and one per each of the child components (which can be in the hundreds). The child ajax requests in this case are really not needed as there is no change of state for them. Is this something worth looking into?

[weaverryan]

EDIT

I'm checking through your excellent reproducer now. In fact, there is some bug in live components that is causing all those Ajax requests. The above situation might be valid for some users, but you simply shouldn't be getting all of those requests.

I've found a few issues, I'll create a PR shortly (hopefully tomorrow) to fix them. I've got your reproducer working super nicely locally :).

Original Comment below.

---

Before I had only one request to update the parent component. Now I get one ajax for the parent, and one per each of the child components (which can be in the hundreds). The child ajax requests in this case are really not needed as there is no change of state for them. Is this something worth looking into?

I expect we'll need some new "mode" to handle this. In 2.4, when the parent component re-rendered, that re-render included all of the children as well. So, it included the full HTML for the parent component. In 2.5, when a parent component re-renders, if you looked in the HTML returned from the server, the "child" component elements would be empty elements. Then, if needed (it's "needed" if re-rendering caused any props passed to the children to change), the child components will make a separate Ajax request to render themselves.

Why did we do this? Because, in some cases, the child components might be very "heavy" to render, which is why you include them as a separate component. This allows for the parent to be re-rendered quickly, and then the children are rendered independently, but only if they need to be (again, if a parent re-renders, and that doesn't cause any "props" that were passed to the child to change, then the child doesn't need to be re-rendered, and it won't be).

However, this is not always the behavior you want. In your example, I'm guessing (?) that sometimes when the parent component re-renders, this causes some prop to change that is passed to the children? So you get the behavior where (1) the parent component Ajax call finishes then (2) all the children make their own Ajax call. Is that about right? We likely need some "mode" where you can say that you want a child component to "re-render eagerly". What this would mean is:

When my parent re-renders, please also send up my data so that I am also rendered during that Ajax request.

Does that sound like what you need?

[weaverryan]

Fixed in #596!

[weaverryan]

Oh, but, by, when you use data-live-id, pass a string that doesn't start with a number. So I used something like 'data-live-id': 'translation-'~translation.id in your reproducer. That wasn't what was causing your issues (the bugs were the issue), but it is something that you would still need to update in your code after #596.

[StrahilRuychev]

Oh, but, by, when you use data-live-id, pass a string that doesn't start with a number. So I used something like 'data-live-id': 'translation-'~translation.id in your reproducer. That wasn't what was causing your issues (the bugs were the issue), but it is something that you would still need to update in your code after #596.

Thanks, will keep that in mind :)

[StrahilRuychev]

However, this is not always the behavior you want. In your example, I'm guessing (?) that sometimes when the parent component re-renders, this causes some prop to change that is passed to the children? So you get the behavior where (1) the parent component Ajax call finishes then (2) all the children make their own Ajax call. Is that about right? We likely need some "mode" where you can say that you want a child component to "re-render eagerly". What this would mean is:

When my parent re-renders, please also send up my data so that I am also rendered during that Ajax request.

Does that sound like what you need?

If I understand you correctly, this is exactly what I need. In my case the parent component makes an http request to an external service to get a list of translation objects (each with translation locale, domain, key and text). Then the parent renders a child component for each of these translation objects. The parent component has functionality to filter the translations by locale, domain, translation key and translation text. When the user selects a different translation domain for example, another http request is made to the external service and a fresh batch of translation objects is fetched. So, all of the previous child components has to be replaced with a set of new ones.

[weaverryan]

I think you'll be quite happy after #596 is merged (I'll do it today). After trying that new code, you can tell me if there is anything else that doesn't seem right. When I tried your example with the new code, it worked wonderfully :)