#4083 (Current react design is really bad for async rendering.)

by Sharif Mehedi · in Developers · assigned to Sharif Mehedi

Résumé

Every time I type something on a text box (even if it's a dot (.) or any minor edit) react render the whole layout all over. In many cases this causes a disturbance in an event flow. Say I want to trigger an event (any event), after triggering, while react re-render the layout, the event detail gets lost. I saw, in many places @tonis used setTimeout which is really not a solution rather another complication.

Note: I am not complaining rather just stating the fact.

Concepts sous-jacents

Commentaires

5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : Separated datatable and managed to isolate the effect of data-fetching ajax call by channeling render of the datatable only on ajax success. there's still another ajax happens when we submit an edit, but it will not be much of an issue. until I come up with an idea to resolve that, I am afraid it wil...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : TODO: another triage. I am hopeful that separating DataTable into a separate component will work.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : I am really kind of frustrated with this memory leak. No matter what I do, it's always there. My findings about building bugfree react app: Keep logic (including data fetching) to a separate higher level component from the rendering component. If not using any async features then make the data flow f...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : Actor is rendering twice on mount, that is a fact from my investigation, which means LinoGrid is also rendering at least twice with Actor. rendering multiple times are not so bad unless these renders happen as renders from two different components rather than one component rendering twice. Here: git...
5 ans, 6 mois ago by tonis about #4083 (Current react design is really bad for async rendering.) : AFAIR that's not the reason for the flashing.
The race condition I was referring to was the use of setTimouts.
IIRC the reason for the flashing is that when the editor opens, it's creating a new state containing an editing value.
when onsave is called, we're not acutally editing the state of the ...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : Further investigation into the cause of the "race condition" (this is what @tonis called it) led me to believe that the Actor (parent component of LinoGrid) is being rendered twice as children(s) of <SiteContext.Provider />. Normally, Javascript does not allow multi-threading and this race condition...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : Correction - Actor does not re-render on every data-fetch call. Rather it's being re-rendered twice only on LinoGrid mount. Which might actually be causing memory leak and we are getting two LinoGrid in the memory. And also could be the reason for the DataTable issue and some other.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : On data fetch, LinoGrid's parent component "Actor" is being re-rendered. Which is normal, and also can be avoided but I don't think that will be necessary and we know what to expect. Probably this was the thing that was out of my mind and was obstacle in understanding the whole picture. But that does...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : I managed to minimize the render method call from 7 times down to 3. Two of them are intentional, but there's still one I don't know where it comes from. There are still two stateful state of LinoGrid in the memory that are complicating things places. I hope to find the remaining culprit and make Li...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : About the work I have done so far, there's this thing on Sorting that's bugging me: dataTable's internal props take the updated sortField, sortOrder information but it's not reflected back on to the outer layer, as in onSort method. Which is why the default sorting sign in the header does not trigge...
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) : Tonis as the "father" of the Lino React front end was glad to see that his "child" is in good hands :-) The basic usage of paginator seems okay but of course there are still issues. For example: number of rows per page : don't use preview_limit but a hard-coded default value (eg 25) and a dropbox whe...
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) : I talked with Tonis. Let's meet (sharif, tonis and luc) on meet.jit.si/linocore tomorrow at 10 (utc+3).
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) : I had a look into the code, but I don't yet understand enough. Reminds me the first years when we worked for getting the ExtJS grid stable...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : Made pagination available too. But like sorting also not satisfied with it.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : I made the sorting available, but my approach weren't an elegant solution.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : I'm also not sure if I understand the situation correctly. Maybe I will know as I explore more.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : Sorting and Pagination of lino_react is not functional currently. This is because primereact DataTable's default behavior works on data loaded on memory. On each reload we are currently loading the minimum number of rows that we show on a single page, so for pagination and sorting we were querying t...
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) : That said, I would actually be glad to be your "host" in the original meaning: the one who welcomes you and gives an introductory talk. If you want. Another aspect is that maybe you have questions about some obscure internals of Lino. Certain parts of Lino are obvious to me, but other developers can...
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) : No, you don't need me to host you on Jitsi. Everybody can go to meet.jit.si and start a meeting. You just need to open the same URL at the same time. I usually use "linocore", but that's purely optional.
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) : Note the sign of hope. Tonis and Sharif want to meet. It is a historical moment: two Lino contributors want to discuss things where Luc won't be of much help.
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) : Wow! Tonis getting his local contributor environment back! That's great news! Please try to follow the instruction on [url www.lino-framework.org/contrib/index.html#get-started] and give feedback whether they are good.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : Of course, let's have a talk on jitsi on Monday. @tonis I will be available whenever you are. We are going to have to have @luc to host us. Don't we @luc?
5 ans, 6 mois ago by tonis about #4083 (Current react design is really bad for async rendering.) : had a quick look at the Pr. interrsting stuff. would aprciate some deeper explcation of how your plan to implemnt a async soution. i should likely get local dev server running again to test things. On Monday I have time to have a meeting about this.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : I categorized the LinoGrid state.properties in the following three categories: Cosmetic, Static & NotCosmetic. Cosmetic properties shell stay in the state since they require a re-render on change. Static properties will also stay in the state since they do not possess any threat of re-render (Not pro...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : LinoGrid calls its render method 7 times on load and reload; also multiple times on handling any action or navigation. In my opinion, the call should be done twice at most (on load or reload), once to signal that it's loading and another is to actually render everything after internal setups.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : @tonis I made a pull request: github.com/lino-framework/react/pull/18
I moved the editingValues from state to gridData and only assign them to state on-onSubmit so that the Action on-onSubmit has access to the editingValues. Thank you.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : @tonis I made a pull request: github.com/lino-framework/react/pull/18
I moved the editingValues from state to gridData and only assign them to state on-onSubmit so that the Action on-onSubmit has access to the editingValues. Thank you.
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : I installed additional two packages, "abort-controller" and "@babel/plugin-transform-runtime", the later is a devDependency, also removed "yet-another-abortcontroller-polyfill". Both of the "abort controller" are functionally the same I think and I like the name "abort-controller" because it is shor...
5 ans, 6 mois ago by tonis about #4083 (Current react design is really bad for async rendering.) : Yes. The grid component is quite bad in this regard.
IIRC I did monkey patch the rich text editor, or any cells in editing mode, to store a the local changes without calling propagating the changes until after exiting the edit mode, or a denounce finishes. Good luck. :D
As far as I could see f...
5 ans, 6 mois ago by Sharif Mehedi about #4083 (Current react design is really bad for async rendering.) : The problem is worse in LinoGrid. All the data for each lower level component in LinoGrid is stored in LinoGrid.state (this.state) and with each little changes in the leaf component level the state of LinoGrid changes and calls the render method, which re-renders everything. I decided to create a var...
5 ans, 6 mois ago by Luc Saffre about #4083 (Current react design is really bad for async rendering.) (1 reply) : Do you see a better solution already? If yes, and if you are more or less sure about it: go for it! If you are not very sure, then let's have a brainstorming session on Jitsi. But not right now, because my ladies are sleeping and we are in Tallinn where I have no room where I can talk in the night. ...