Unsuccessful struggle with the AppConnect render 😭

Wappler General
#1

What the AppConnect render is doing now puts an end to the creation of large real-time messenger format applications.

Each time the data is updated, the renderer does not redraw the small element of the DOM tree in which the changes occurred, but everything related to the server action.

The operation of a simple chat is shown below. I change the status of the message to “read”. And with each change, not a separate element is rendered, but the entire chat window, which leads to the start of scrolling. Such an interface in production is a constant dissatisfaction and complaints of users about the interface:

8
8656×774 533 KB

But that’s half the trouble. The real hell arises from the fact that the renderer redraw interface from all users who are connected to the server at the moment when updating data. And it’s hell when 10+ users are connected to the app:

7
71844×774 2.28 MB

I will also place an archive of the application here (a simple chat with the sqlite database) so that you can also run it very quickly on your computer and reproduce what I showed in the recordings above.
chattest.zip (316.4 KB)

@sid I reading in your messages that one of the projects you were working on was a messenger. Aren’t your users facing a rendering problem? Or did you manage to find a solution to work around the problem? Maybe I’m missing something?

Wappler 5.2.4 Released
#2
#3

What does the eye icon exactly do, does it update something on the server?

Instead of the repeat attribute use the repeat children component with a key defined, make sure the messages have some uniq identifier. Using a key prevents the whole html from being updated and only changes are updated.

1 Like
#4

The setup we have, in few words, is that we fetch the data from SC and store in DataStore.
Each “event” that happens - new message, read status, delivered status etc - are shared across users via Sockets.
On each emit received on client side, DS is Upserted.
The list of chats is never queried from DB again, unless contact is changed or page is refreshed, since its very costly to get all the data from the server on every update.

With this setup, I have never seen such a issue where complete UI re-renders itself. Like Patrick has suggested - check if your repeats have a KEY.

Recently, due to various TYPES of messages - image, audio, video, text etc. - the UI has become very slow. Awaiting @patrick’s help on that over PM.

2 Likes
#5

Yes. The eye icon updates the status record of the read messages in the status table.

1
1651×696 61.4 KB

I’ve thought about it many times. And I was looking for different ways to use the repeat children attribute instead of the usual repeat. But the Wappler does not allow this to be done. The repetition of children can be enabled only for the table and for some other components. But what if I use a custom layout based on Flex containers?

#6

you can actually use repeat children on any kind of parent>child structure. You can just copy the code and add it:

is="dmx-repeat" id="repeat_id_here" dmx-bind:repeat="repeat_expression" key="unique_key"

If you find some cases where this is not available in the UI, please report them so we can add it there.

1 Like
#7

Thanks for the tip @Teodor. I will definitely try this solution tomorrow. If this is the solution to the problem it will be awesome!

The problem is that it can’t be done literally anywhere from the Wappler interface. If you create any nested structure (for example, one flex container and another flex container is nested in it) then through the Wappler interface it will be possible to add only the usual repeat. It is not possible to add a repeat children attribute to the external container via the Wappler GUI.

1 Like
#8

This is one of the reasons why we don’t use the design view much. There is not much sense in the way these component restrictions have been placed.

So whenever I need to add a component, I just go to the app node and try to add there, or just keep adding containers/flexes/forms etc, until I see the component I want.
Then just cut that code and paste where I need.

There is one new “convert to…” option in properties panel where it has become easier to get repeats or conditional regions, but haven’t used it much.

#9

Well, it works. Now the render has begun to adequately respond to exactly those elements in which changes are taking place.

The main question is, if the render works more efficiently with repeat children, is there really a need for a regular repeat?

In any case, even if both repet are necessary, it is required to make the use of repet children available wherever normal repet can be used. Now it is impossible to add it to 90% of the interface using the graphical interface, so you can only work with it in manual coding format.

#10
#11

Just to confirm, so repeat children are more efficient? Is so I need to change it in a lot of places

#12

Yes, the repeat children is an actual repeat component in App Connect, the other one - repeat is a dynamic attribute. Only components (i.e. repeat children) have properties, data and events.

1 Like
#13

Repeat children will be available for a lot more components in today’s update.

3 Likes
#14

This has been improved in Wappler 5.2.4, now you can make a lot more components a repeat children.

#15