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

matchMedia doesn't seem to be working with mediaClassNames #125

Closed
jdesherlia opened this issue Mar 10, 2020 · 8 comments · Fixed by #151
Closed

matchMedia doesn't seem to be working with mediaClassNames #125

jdesherlia opened this issue Mar 10, 2020 · 8 comments · Fixed by #151

Comments

@jdesherlia
Copy link

Hey All,

When trying to use the method described for passing mediaClassNames to my own components in order to avoid the extra div, it seems that all content is always present. I was under the impression that an eventListener and call to matchMedia should be selectively rendering only the matching components after rehydration. Is this a bug or am I mistaken as to how this should be working?

Also, I can't seem to understand how the onlyMatch prop works. Any clarity you can provide there?

Thanks,

-Josh-

@damassi
Copy link
Member

damassi commented Apr 11, 2020

@jdesherlia - mind pasting a snipped of code for what you're trying to do?

@damassi
Copy link
Member

damassi commented May 1, 2020

Feel free to reopen if this is still an issue

@damassi damassi closed this as completed May 1, 2020
@jdesherlia
Copy link
Author

Sorry @damassi got sidetracked for a while and this was an issue but not a blocker. It has since popped up again, and im more concerned that its just causing an oversized DOM. When I do something like the below, the content is never removed from the DOM when the breakpoint isn't matched:

<Media at="mobile">
          { ( mediaClassNames ) => {
            return (
              <Section styles={ styles || undefined } { ...this.setClasses( `slim-bottom-1 slim-top-1 ${ mediaClassNames }` ) }>
                { this.renderTestimonial() }
              </Section>
            )
          }}
        </Media>

Here is a screenshot fo this component on a desktop resolution. As you can see the class names get added and successfully hide the content, but its still rendered to the DOM:

image

@damassi
Copy link
Member

damassi commented Aug 2, 2020

To confirm, do you have your root component wrapped in a context provider as seen here?

@damassi damassi reopened this Aug 2, 2020
@jdesherlia
Copy link
Author

Yes. We are using Gatsby so we wrap our app in gatsby-ssr.js and gatsby-browser.js like this:

// Wrap our Root element with our Modal Provider to allow passing context up and down the chain
exports.wrapRootElement = ({ element }) => {
  
  return (
    <MediaContextProvider>
      <ModalProvider>
        <LegalDisclaimersProvider>
          <StickyStackContextProvider>
              {element}
          </StickyStackContextProvider>
        </LegalDisclaimersProvider>
      </ModalProvider>
    </MediaContextProvider>
  )
};

I can also confirm that if I don't render a function inside a media component but instead allow it to generate the fresnal div, it does correctly render only the content for the matching browser size. I think the major difference is the presence of the fresnal-container class.

@alloy
Copy link
Collaborator

alloy commented Aug 12, 2020

You’re not utilizing the second render-prop parameter described here (renderChildren). I see it’s not mentioned in the README, which probably caused the confusion. Can your verify that that’s the case?

@jdesherlia
Copy link
Author

@alloy just had a chance to try this. That worked a treat, thanks! Went through and updated my whole app.

I imagine this will help with our lighthouse score a bit. At least the part about excessive DOM size. :-) Have a great one, and thanks for the awesome package!

alloy added a commit that referenced this issue Aug 24, 2020
@alloy
Copy link
Collaborator

alloy commented Aug 24, 2020

Thanks for verifying, I’ve created a PR to expand the README doc #151

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

Successfully merging a pull request may close this issue.

3 participants