[REACT] Grid With Over 15 rows Issue

[tjmeal]

Dear all,

I would like your expertise and mainly your help, now that i was wrapping up the grid i am facing a critical error.

I have set a grid with websocket connection using stomp client library (set up is same as https://bryntum.com/products/scheduler/examples/websockets/).

1) i have a popup to perform updates to the records
2) i can create new records on grid level > with autoCommit to false > a batch save all the records.

On 1) The moment the grid has more than 15 rows so 16 and more > when i open the popup to perform an update > the moment the code is about to send the data over stomp > its like the websocket connection has been lost.

• I would like to point here that if the grid is completely empty > and i create up to 29 rows with method 2) > then the popup update works as expected > if i reload the page and the grid loads with 29 rows then the popup updates again fails with same behaviour > websocket connection lost.

on 2) if i create up to 29 records everything works perfectly > the moment i try to add 30 rows at once > the same behaviour occurs > its like the websocket connection has been lost.

The only reason i am sending you this message > is due to the think that the problem only happens specifically at 15 +1 rows and 29 respectivly.

• i have 100% same web socket implementation > with scheduler & grid (chainedStore)> which uses the same popup and it works as expected. The issue is specifically to the grid only.

Do you have any idea/impression what might causing this unexpected behaviour ?

Thanks a lot in advance your effort helping me.

[marcio]

Hey tjmeal,

Thanks for reaching out.

This behavior might be related to how the data is being handled or transmitted over the websocket. Here are a few things you could check:

1. Websocket Configuration: Ensure that the websocket connection is properly configured to handle larger data payloads. Sometimes, the server might have limitations on the size of data it can process at once.

2. Batch Size: When sending data over the websocket, try breaking it into smaller batches to see if that resolves the issue. This can help if the problem is related to the size of the data being sent.

3. Error Handling: Implement error handling in your websocket connection to catch any errors or disconnections. This might give you more insight into what's causing the connection to drop.

4. Network Limitations: Check if there are any network limitations or restrictions that might be affecting the websocket connection when handling larger datasets.

5. Browser Console: Look for any error messages in the browser console when the issue occurs. This might provide more clues about what's going wrong.

If none of these suggestions help, you might need to provide more details about your websocket setup and any error messages you're receiving.

[tjmeal]

Thanks a lot for your reply, but has nothing to do with the server.

I may have found the issue but can you please explain me the following :

On the code bellow > both listeners are working.

But what is the difference and when should i use what?

When should i use
1) grid.store.trigger('some_name', {});
2) grid.trigger('some_oter_name', {});

    grid.on({
      mmp_grid_wakeUpReminder: me.wakeUpReminder,

  thisObj: me
});

grid.store.on({
  mmp_saveBatch: me.saveBatch,
  
        thisObj: me
});

Thanks in advance.

[ghulam.ghous]

Hi tjmeal,

The difference between

grid.trigger('eventName', {})

and

grid.store.trigger('eventName', {})

lies in the scope of the event being triggered.

1. grid.trigger('eventName', {}): This triggers an event on the Grid instance itself. Use this when you want to notify or handle events related to the Grid's UI or behavior, such as user interactions or visual updates.

2. grid.store.trigger('eventName', {}): This triggers an event on the Store associated with the Grid. Use this for events related to data operations, such as changes in the dataset, data loading, or saving.

Choose the appropriate method based on whether the event pertains to the Grid's UI or the underlying data operations.