Components with tables seem to update strangely

[cro]

Updating this question, the original text is at the bottom. I switched from tables to flexbox with <div>s and this works better.

Now I have a different question: In my test data I have about 35 rows I want to display. Rendering takes 15-20 seconds (!!). My model is somewhat complex, but it didn't seem THAT complex. Django Debug Toolbar tells me that the SQL query takes about 1 second to run. How can I debug this and figure out why this takes so long?

Original question:

I have the following unicorn component template (table definition is outside of this)

        {% for m in movers %}
            <tr id="tr-{{ m.id }}">
                <td id="td-cb-{{ m.id }}"><input type="checkbox" name="search" value="{{ m.id }}"></td>
                <td id="td-name-{{ m.id }}">
                    <a href="{% url 'admin:core_mover_change' m.id %}"
                       target="_blank">{{ m.person_id.last_name }}, {{ m.person_id.first_names }}</a>
                </td>
            </tr>
        {% endfor %}

I also have a filter field that restricts the table contents to matching records. When the filter applies, it appears that the DOM morphing doesn't put the updated data in the table cells, but sticks it all just in front of the first <tr>.

The extra {{ m.id }} variables above was a guess on my part in case there wasn't enough context for morphdom to figure out where the updated data was supposed to go.

Is this a bug or am I holding it wrong?

[adamghill]

You might need a unicorn:key to help morphdom? https://www.django-unicorn.com/docs/templates/#dom-merging

[adamghill]

How can I debug this and figure out why this takes so long?

Django Debug Toolbar would be my approach as well, but usually the slow down is SQL and the fix is preselect/select_related.

I'm unclear if you are nested components, but here's an example with 50+ rows in a table where each row is its own django-unicorn component: https://github.com/adamghill/django-unicorn/assets/317045/162c17b1-3e57-4d16-8bc7-47e52fea5b1a

However, if you can make a PR or a sample repo replicating the issue I can take a look.

[cro]

Followup here, I think the actual issue here was that my models were indeed pulling in a lot of fields, and all these fields needed to be serialized so they could be pushed to the page. I did two things to correct this--first I applied @adamghill 's suggesting to use select_related, second I made sure that my query was only getting the fields I actually needed to display.

So rather than just

mq = Mover.objects.all()

I used

        mq = Mover.objects.prefetch_related("person_id", "team_id",
                                            "sending_org_id",
                                            "bicep_rating",
                                            "available").values("id", "person_id__last_name", "person_id__first_names")

HUGE difference in performance and number of SQL queries. Thanks to django-debug-toolbar I could see that the original was 250 queries and CPU time was 15+ seconds. The 'fixed' version was closer to the actual number of rows being displayed, and was sub-5 seconds.

[adamghill]

Nice! This is a good point which I briefly mention in https://www.django-unicorn.com/docs/django-models/#model, but not as it pertains to performance. I should probably make it more clear or add a section to the docs specifically about improving performance. 🤔