Skip to content
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

speed(homepage) offload images until in viewport #2956

Merged
merged 3 commits into from
Apr 24, 2019
Merged

Conversation

EugeneHlushko
Copy link
Member

Because of the terrible load on the homepage visits, i am offloading img loading until supporters are in the viewport.

Related: #1548
Takes one off #1525

Copy link
Member

@pranshuchittora pranshuchittora left a comment

Choose a reason for hiding this comment

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

I'm not sure about this package. Pls try implementing this natively using Intersection Observer

@EugeneHlushko
Copy link
Member Author

What can i say... If you are not sure, check the source code.

@pranshuchittora
Copy link
Member

@EugeneHlushko I meant, I am not sure about the viability of the package. Hence I prefer to implement the feature using Intersection Observer API.

@EugeneHlushko
Copy link
Member Author

Really concerned with browser support around Intersection Observer.
So i've looked at our visitors browser/OS versions for the past 90 days in GA, and it looks like we don't really have IE 11 or Safari pre Intersection Observer visitors (not even 0.05%).

I am planning to make a HOC and wrap them into it.

@EugeneHlushko
Copy link
Member Author

Decided to not go with another HOC, rather extend my reusable component ;] @byzyk

@@ -61,9 +62,10 @@ function formatMoney(number) {
return str;
}

export default class Support extends React.Component {
export default class Support extends VisibilitySensor {
Copy link
Member

@montogeek montogeek Apr 24, 2019

Choose a reason for hiding this comment

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

2 things:

  1. And most important one, this break the goal of this project, @skipjack vision when rebuilding this project is to focus solely on content, meaning that custom plugins/components/logic/code etc should be outside of it, as dependencies, that's why my custom MDX plugins are dependencies.

  2. This way of writing React components is not recommended by React itself (https://reactjs.org/docs/composition-vs-inheritance.html#so-what-about-inheritance), meaning that it is not idiomatic, which is important if you want to attract new contributors, especially in an Open Source project like this one.

Copy link
Member Author

Choose a reason for hiding this comment

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

this looks like an overkill to me, @skipjack thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree with @montogeek in this case.

...when rebuilding this project is to focus solely on content, meaning that custom plugins/components/logic/code etc should be outside of it, as dependencies, that's why my custom MDX plugins are dependencies.

Yeah it seems there are already some pretty popular open source packages that do similar things so we should consider those first instead of bloating this codebase with more components:

Even if none of those work, you could always write this new component as a separate package the same way we've done for other things.

This way of writing React components is not recommended by React itself (https://reactjs.org/docs/composition-vs-inheritance.html#so-what-about-inheritance), meaning that it is not idiomatic, which is important if you want to attract new contributors, especially in an Open Source project like this one.

Yeah I agree with this as well. However, if you use one of the open source packages I listed above then the new component (and inheritance) wouldn't even be necessary.

Copy link
Member Author

@EugeneHlushko EugeneHlushko Apr 24, 2019

Choose a reason for hiding this comment

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

I've started this PR with a react-visibility-sensor which doesn't benefit from Intersection Observer. After looking at our user base i was tempted to go ahead and use that. Which seems to be widely supported nowadays.
So i've done a re-work here within PR.

having that said i will move the visibility sensor into a separate package and rework it from inheritance type module into a HOC

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for dropping by btw @skipjack 👍

@@ -0,0 +1,47 @@
import React from 'react';

export default class VisibilitySensor extends React.Component {
Copy link
Member

Choose a reason for hiding this comment

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

It is nice component, good work

@EugeneHlushko
Copy link
Member Author

Apparently there is a: https://www.npmjs.com/package/react-intersection-observer

@EugeneHlushko EugeneHlushko requested a review from montogeek April 24, 2019 17:21
@EugeneHlushko
Copy link
Member Author

Its updated CC @montogeek

@netlify
Copy link

netlify bot commented Apr 24, 2019

Preview is ready

Built with commit efb793d

https://deploy-preview-2956--webpackjsorg-pr-previews.netlify.com

@EugeneHlushko
Copy link
Member Author

I love this bot lol

@netlify
Copy link

netlify bot commented Apr 24, 2019

Preview is ready

Built with commit 4b8d081

https://deploy-preview-2956--webpackjsorg-pr-previews.netlify.com

@montogeek
Copy link
Member

Yeah, this PR works great!

@montogeek montogeek merged commit 595e62b into master Apr 24, 2019
@montogeek montogeek deleted the lazy-contribs branch April 24, 2019 17:41
@montogeek
Copy link
Member

Thank you!!

@EugeneHlushko
Copy link
Member Author

Cheers

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

Successfully merging this pull request may close these issues.

4 participants