Skip to content

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

Merged
merged 12 commits into from
May 2, 2017
Merged

Support Refactor #1170

merged 12 commits into from
May 2, 2017

Conversation

skipjack
Copy link
Collaborator

@skipjack skipjack commented Apr 29, 2017

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.

@bebraw
Copy link
Contributor

bebraw commented Apr 29, 2017

That fetch doesn't feel right. I wonder if it would be possible to push the problem outside of React and manage it on build like we do for loaders/plugins/etc.

@skipjack
Copy link
Collaborator Author

skipjack commented Apr 29, 2017

Ah like generate a json file on every build cycle that contains the backers/sponsors data?

@bebraw
Copy link
Contributor

bebraw commented Apr 29, 2017

Yeah, it doesn't have to be more complex than that. Also avoids some requests for the client.

@skipjack
Copy link
Collaborator Author

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.
Integrating opencollective sponsor/backer retrieval into the fetch the process
which saves some client side requests and fixes the build.
@skipjack
Copy link
Collaborator Author

skipjack commented Apr 29, 2017

@bebraw just moved it to the npm run fetch process. Please take a look when you have a chance to make sure everything is sound.

@skipjack
Copy link
Collaborator Author

skipjack commented Apr 29, 2017

@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",
Copy link
Contributor

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch.

@skipjack
Copy link
Collaborator Author

skipjack commented May 1, 2017

@bebraw should be good to go now.

@@ -1,56 +1,50 @@
import React from 'react';
// import PropTypes from 'prop-types';
import Additional from './support-additional.json';
import 'isomorphic-fetch';
Copy link
Contributor

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';.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah right again!

@skipjack
Copy link
Collaborator Author

skipjack commented May 1, 2017

@bebraw ok now it should be good to go (hopefully 😁 )

@@ -0,0 +1,18 @@
[
{
"id": 20000,
Copy link
Contributor

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?

Copy link
Collaborator Author

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",
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

@@ -1,56 +1,49 @@
import React from 'react';
// import PropTypes from 'prop-types';
Copy link
Contributor

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?

Copy link
Collaborator Author

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.

@skipjack
Copy link
Collaborator Author

skipjack commented May 1, 2017

@bebraw pushed some more tweaks based on your comments.

Copy link
Contributor

@bebraw bebraw left a 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. 👍

@skipjack
Copy link
Collaborator Author

skipjack commented May 2, 2017

Seeing the same error now as on #1177... @bebraw any idea what's going on there?

@bebraw
Copy link
Contributor

bebraw commented May 2, 2017

failure.diag can be undefined at scripts/check-links.js apparently. I think you have to add a check against that. I'm not sure if that fixes everything, though.

@skipjack
Copy link
Collaborator Author

skipjack commented May 2, 2017

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 --exclude as the support urls have changed now that we're pulling in the raw data.

@skipjack
Copy link
Collaborator Author

skipjack commented May 2, 2017

@Munter any idea what the FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory is about? Seems to be getting thrown from somewhere within hyperlink.

@skipjack skipjack merged commit 3513cb5 into master May 2, 2017
@skipjack skipjack deleted the support-refactor branch May 2, 2017 23:07
@Munter
Copy link
Collaborator

Munter commented May 3, 2017

@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?

@papandreou
Copy link
Contributor

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 node --max-old-space-size=<numMegaBytes> switch and defaults to 2000 (2 GB).

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 node --max-old-space-size=5000 hyperlink ... to rule out the latter.

@Munter
Copy link
Collaborator

Munter commented May 3, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants