-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Support Refactor #1170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Refactor #1170
Conversation
That |
Ah like generate a json file on every build cycle that contains the backers/sponsors data? |
Yeah, it doesn't have to be more complex than that. Also avoids some requests for the client. |
I'll update with that change and re-test. |
…rom opencollective Fetching the actual JSON containing our supporters gives us more flexibility to tackle issues like #411. It also give a model to follow for our, now extracted, additional sponsors list (those not from open collective).
This includes an attempt at a server-side fetch although not sure it worked.
f36db08
to
91c18e5
Compare
Integrating opencollective sponsor/backer retrieval into the fetch the process which saves some client side requests and fixes the build.
@bebraw just moved it to the |
@bebraw we should definitely squash and merge this one, once you've reviewed. |
package.json
Outdated
@@ -98,6 +98,7 @@ | |||
"yaml-frontmatter-loader": "0.0.3" | |||
}, | |||
"dependencies": { | |||
"isomorphic-fetch": "^2.2.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please drop this as the implementation doesn't need it anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch.
@bebraw should be good to go now. |
components/support/support.jsx
Outdated
@@ -1,56 +1,50 @@ | |||
import React from 'react'; | |||
// import PropTypes from 'prop-types'; | |||
import Additional from './support-additional.json'; | |||
import 'isomorphic-fetch'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for import 'isomorphic-fetch';
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah right again!
@bebraw ok now it should be good to go (hopefully 😁 ) |
@@ -0,0 +1,18 @@ | |||
[ | |||
{ | |||
"id": 20000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do the ids come from? Is there any chance these could clash in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do the ids come from?
Hardcoded as I was trying to stay consistent with the opencollective data. And they're used for the key
prop.
Is there any chance these could clash in the future?
Potentially, yes. I tried to bump them pretty high to avoid that.
In general I like to avoid key={ index }
everywhere, hence the ids. In our case, it currently doesn't matter too much for non-interactive components as a render()
will never be called again on the client side. I'm ok with key={ supporter.id || index }
for now and maybe shifting back to something like this, except using higher ids or uuids to prevent collisions, down the road.
"name": "MoonMail", | ||
"username": "moonmail", | ||
"tier": "sponsor", | ||
"avatar": "https://static.moonmail.io/moonmail-logo.svg", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to host the svgs on webpack site instead? I can see pros/cons to both and we can stick with the current solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idk, I kind of like keeping these external for now. I think our asset management still has some room for improvement so I'd like to avoid adding any more than there already are for now. Plus, this stays consistent with the rest of the supporter images which are also fetched externally from the opencollective urls.
components/support/support.jsx
Outdated
@@ -1,56 +1,49 @@ | |||
import React from 'react'; | |||
// import PropTypes from 'prop-types'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe drop the commented bits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure... I was leaving it in for now as kind of a TODO. I'd like to add prop type checking to some of our components at some point but I'm fine with curbing this for now.
@bebraw pushed some more tweaks based on your comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to go, I can't find anything else. 👍
|
Yep, debugging the issue now... hopefully once this is resolved we can get this PR (and the other) merged finally. I'm also going to remove that |
@Munter any idea what the |
@skipjack Haven't seen that one before. But since hyperlink is not particularly clever about unloading the assets it has visited and out of memory error seems probable. @papandreou is this specific error known to you? |
Yeah, that's how V8 dies when the JavaScript heap exceeds the maximum allowed size (even after performing a full GC). The maximum size is specified using the That could either indicate that the combined size of the assets that hyperlink is loading has increased so it doesn't fit anymore, or that there is a bug that means it'll run off and follow external relations/redirects infinitely. As the first thing I would try invoking it as |
There's a bunch of things that hyperlink could do to free up memory during the run. Once an asset has been visited it's never used again. So I could potentially unload it. Similarly I might be able to avoid loading assets that are known to not contain external relations and are huge, like videos. |
Re-implementing the reverted refactor/fix of the
Support
component.@bebraw moving the conversation from #1168 to here, my attempts so far have failed. Please let me know any suggestions, if we don't get this in somehow we'll likely have to re-open #1167 and #411.