Projects: move panel mgmt to React Context

[chadoh]

Fixes #978

This change slims down the App.js file in Projects by hundreds of lines, primarily by pushing logic to hooks and context.

Reviewing

• you may find it useful to read the commits in order
• I suggest reviewing the file changes with whitespace changes hidden

[coveralls]

Pull Request Test Coverage Report for Build 2470

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 2465:	0.0%
Covered Lines:	311
Relevant Lines:	311

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 2473

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 2465:	0.0%
Covered Lines:	311
Relevant Lines:	311

---

💛 - Coveralls

[ottodevs]

@chadoh the PR status is "In progress" is that accurate, or is it ready for review?

[chadoh]

 I am finding some issues with it still, maybe hold off on review. You can look over the code if you want, I don’t think the shape of it will change much, but don’t bother trying to run it locally.

…

On Jun 25, 2019, 10:28 PM -0400, Otto G ***@***.***>, wrote: @chadoh the PR status is "In progress" is that accurate, or is it ready for review? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Quazia]

I agree! That would be great. A quick search for how to automate such "performance regression checks" in our CI pipeline led me to a blog post about using Lighthouse and Circle CI. I wonder if it makes to wait until we get our e2e testing setup merged so we can explore Cypress a bit more, and see if there's a way to integrate Lighthouse or another performance-checker with our Cypress setup.
This sort of research could easily take multiple days, though I think it would be worth it in the long-run. Want me to go ahead and make a ticket for it now?

I think capture a ticket and we can start looking into this post mainnet.

[ottodevs]

In my recent tests with latest codebase the most concerning issues were addressed, and overall the code works good.

A lot of code was cleaned and the code changes seem ok

I have some other findings, probably most of them are not really related, and I think this PR is already huge, just to take note of these to capture on other tickets if relevant:

• Basically once we stop using some complex react lifecycles we could change lot of other components to be functional, like App.js and the panels (most of them have right now the TODO note about that)
• We can still abstract lot of duplicated logic to hooks to reuse the code a lot, specially the panels seem to have a lot of duplicated boilerplate
• We could encode the proptypes to clean the code a lot, specially the complex objects that need shape
• Lot of props seem not properly typed (I am pretty sure @chadoh addressed this on other commits)
• View funding proposal could probably be improved a bit, probably out of scope but something to take in mind, some data will need additional Apollo queries other can be taken as we do on issuedetail
• Lot of issues transformations happen on the render function, that should be done IMHO in the reducer and some others just Apollo requests, taking advantage of the nice zero config caching it offers (like array of issue names or things like that, so we don't need to manipulate some data locally or we could save some of those transformations)
• When removing repos or creating new issues there is no visual feedback at all, this should happen without the need to refresh
• Filter bar is not correctly showing the filtered results, for example for funded issues, specially after a cache clean
• We want to adopt a solution like aragon/ui has to do the svg cleaning and minification by using a script instead of in-lining svg code from other files (ethereum loading animation) - that is probably not a priority but nice to have and would save time in the mid/long term
• Some things like the github authenticated user should not be loaded each time we visit the settings tab, but be already loaded in a more global state and only read by the settings field
• I generally rather to assign default values for props into the beginning of the components instead of dealing with conditionals in the render function (thing like token={props.token || []} would be cleaner if we deal with default values for token just when the prop is received, maybe this is more opinionated, but I find this more readable and cleaner)
• The activity log is wiped when a funding is rejected and a new work submission starts

If you @chadoh or @Quazia think any of these are in the scope of this issue would be nice to incorporate, but as I said I encourage to put these on new tickets and merge this one ASAP :)

Nice job @chadoh !

[ottodevs]

I also commented with @chadoh about the -not that much annoying- 401 unauthorized errors that we experienced on other branches as well, the issue is with the useGithubAuth() hook, line 17, maybe if we put a try-catch to handle that promise result we would have more control over the response, the same as my other comment, if we decide this is in the scope of this PR let's do it, should be trivial to add, otherwise I can capture the issue outside