Benchmark and improve front-end performances

[hunvreus]

I know @epiphone and @bbss did a fair amount of optimization work for data.worldbank.org. I'd like to;

• See how we benchmark the front-end performance (we should set this up as a best practice part of our React dev cycles),
• See what are the low hanging fruits in terms of performance improvement for FullPM.

@JuhaS may be able to help with some of this.

[JuhaS]

For that project most of the performance gains were from reducing the data that is loaded and optimizing code to reduce CPU consumption. I think for this project the biggest performance bottleneck is loading data from server (and server loading form GH API). But if there is some sluggishness purely from the frontend code, then we could try apply some of the same tweaks we did.

[flyingant]

Hi there! this is MaYi, well, I also checkout the code with curious and I think maybe I could help provide some advices on this project with my react dev experiences. As @JuhaS noticed that the problem of loading data from server. I have some advices on it.

1. Use 'redux middlewale' to handle the data fetching.(to understand the middleware, you can check this link)
2. Or use the a react library called 'redux-saga', this library is really awesome.

And for this project, in my opinion we should try to follow some rules from flux architecture and redux architecture beacuse to follow the rules made by the react&redux community gonna be very easier to test and apply some new ideas or debug and fix issues. So I also have some advices:

1. The actions file (issueActions.js, repoActions.js ... etc.) should only export the 'redux actions' as a plain object like: { type: CHANGE_TICKETS, payload: {...} } . In the component, use 'props.dispatch()' proviced by redux to dispatch redux action. Just keep your actions stay pure.
2. Try to make react component as a Pure render component..
3. Use 'css-module', it gonna be like magic when you write some css.

Yeah, feel free to have a catch-up with me if you have some ideas on it!

MaYi

[EcutDavid]

1. For actions we are using async actions, and sending plain object as you said.
2. Which component's render isn't pure currently? thanks
3. No need using css-module this project, we are using another strategy handle css-collision this project.

[flyingant]

For 1), Yep, I know you are using async actions and actually I also did the same thing in my previous project but finally found this is not the best way to handle those redux actions. Allow me to explain.

What we did and I had been done is like this:

component -> Click handler triggered -> send request or something async stuff -> Successed or failed to get the response -> dispatch successed action or dispatch failed action -> reducer change the state -> component changed

What the community wished and I suggested:

component -> Click handler triggered -> dispatch action -> handle the action in the middleware (do the data fetching or something async stuff) -> dispatch successed action or dispatch failed action -> reducer change the state -> component changed

even though we could get the same result, but what we did is combined the component with server logic code and to isolate the component and make the component individual will be better in the development. My opinion is the component don't have to care about what will happen after click, what the component should do is just dispatch an action. And actually I found what we did now is like backbone-style, after handling the request and then trigger an event to notify the model changes. anyway I'm not meaning to do this is wrong but the advices to make the react development easy to understand. LOL!

For 2), Ha Yeah! I'm not meaning the 'componennt's render method' but the pure-rendered component or AKA stateless functional component.

For 3), Not sure but I guess, if it will cause the namepace and gloabl scope issues?

:)

: btw am I get a little aggressive in my English ? Ahh, if did, that's must be an accident. LOoOL!

[EcutDavid]

The new way to handle actions sounds good, we have been using the old way for a long time.

Yep, I agree, for stateless AKA "dumb" component, using a pure function.

[bbss]

I'm with @JuhaS on this one, the performance of this app won't be an issue on the front-end. The small amount of data this app uses would make React dance in circles even on mobile. The most important thing is doing optimistic updates (as @hunvreus described earlier with the drag n drop).