Open hunvreus opened 8 years ago
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.
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.
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:
{ type: CHANGE_TICKETS, payload: {...} }
. In the component, use 'props.dispatch()' proviced by redux to dispatch redux action. Just keep your actions stay pure.Yeah, feel free to have a catch-up with me if you have some ideas on it!
MaYi
render
isn't pure currently? thanksFor 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!
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.
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).
I know @epiphone and @bbss did a fair amount of optimization work for data.worldbank.org. I'd like to;
@JuhaS may be able to help with some of this.