-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
feat: thanking contributor (#2632) #2635
feat: thanking contributor (#2632) #2635
Conversation
As I recently learned the hard way, the CSS is currently used by other nodejs sites. So, this shouldn't land until that's solved. Also, I'm not very keen of using non standard attributes even if Chrome has the biggest market share. |
Thank you, i'll change that tomorrow ! |
Woohoow this is cool, looking forward to seeing this in action 💯 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Also do note |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
5b41608
to
c20cdde
Compare
This comment has been minimized.
This comment has been minimized.
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.
This needs to wait until we have PR previews. And see if we can make only one API request instead of 2, see if we should cache this or not and so on. Currently this slows down the page a lot that I'm personally not sure if we should move with this. |
How do you see this slowing down the page a lot? To me it looks like the JavaScript introduced here is mostly asynchronous, in other words not blocking rendering. And the Intersection usage supported by near 90% of users even tries to avoid triggering much of the added code until the But you might be considering something that hasn't caught my eye yet 🤷♂ |
Adding the intersection observer was the idea of @XhmikosR, the home page is slowed down a lot by these 2 requests even with the IO :/ Should I cache the response of the first request to localStorage if supported ? If so how long ? |
This makes me really curious.. Could you describe concretely what you mean by "slowing down" and "a lot"? E.g. is it the actual rendering of the entire webpage we're talking about here? How are you measuring before / after times? |
This makes 2 XHR requests, and also fetches the avatars. All this doesn't come for free :) An example https://gtmetrix.com/compare/OUjbjkwL/BXCUZpol
|
Yeay, great to have some insights to base discussions around 👍 Personally think the fact that it takes more time to wait for the browser to finish all its potential HTTP requests (+ followed by some code execution) is less important, and surely not a surprise as you're hinting at. What is actually important is how quickly visitors gets the website rendered onto their screen. The fact that some parts gets rendered later or even not at all because of network failures etc, may or may not be a problem, it completely depends on what gets rendered later. What Google says about User-centric Performance is spot on IMO:
In this particular scenario we're talking about nice-to-have content in the website's footer. Surely not critical for the visitor to do what they came to the website to do. The rendering of the main content will surely not be postponed significantly because of the changes added here. Chrome's Performance-part of Devtools shows a few important stages related to User-centric Performance metrics that's really valuable. This is the results I got when measuring the nodejs.org vs these changes on netlify: nodejs.orgnetlifyBottom line; I don't think the changes purposed in this PR will negatively affect nodejs.org visitors. |
That I can try for sure. But see if we can get someone to help us move with the build PR. |
* return early * hide the block by default * remove function used only once * remove `height: 0` * add dns-prefetch for api.github.com
* fix: check for the card instead of the avatar * feat: add intersection observer support * feat: localstorage caching - set 2 keys : max_contributors and fetch_date - if max_contributors is set : refetch max contributors - if fetch_date is 1 month old : refetch max contributors - if max_contributors is set and fetch_date is less that one month old : fetch only the contributor * feat: style contributor card, avatar and contributions links * feat: loading spinner * feat: handle requests error by removing the card
Also, move `.hidden` to utils.
b88d72d
to
edbae36
Compare
Thank you for your help @MartijnCuppens and @XhmikosR ! |
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.
Can this be merged?
@MaledongGit no. Please don't bother with this PR. I will merge it when we are ready. |
Thank you so much for merging this PR ! |
Thanks for sticking with the patch till the end :) |
👍 This breaks if going to a 404 URL, because the language picker function throws, and this code never runs, leaving the user with a spinner and placeholder text. |
@tniessen can you share the stacktrace please? Because when developing locally I don't get the 404 page. |
BTW ideally you should make a new issue. |
NVM, I saw the error on the live site. It's unrelated to this PR so please make a new issue. It has to do with the language toggler. |
Issue for toggler code failure: #2984 |
This PR aims to add a card which thank random Node.js contributors.
To Do
s=80
for the avatar imagetextContent
instead ofinnerText
?.hidden
to a general utility classPreview
Fixes #2632
Live preview: https://amazing-volhard-25db2f.netlify.com/en/