Thoughts on server side rendering

[edorivai]

This is intended to share some thoughts, and is somewhat related to #13.

My goal is for desktop specific code not to be downloaded/evaluated on mobile devices and vice versa. This is something that I think would present a significant boost to initial load time for many websites.

Now, a combination of this library and react-loadable would work perfectly fine, if server side rendering is not a requirement. Implementing this combination naively results in both mobile as well as desktop components being rendered serverside, which in turns results in a mismatch on the client. Actually, my current implementation (without this library), involves always rendering both components, and using CSS media queries to hide the irrelevant ones.

I understand that it's fundamentally impossible to perform media queries serverside. However, I think we should be able to do a better job than just rendering everything, always. I'm thinking of using information from the User Agent string as a heuristic to guess which elements to render.

Of course, this approach will inevitably result in mismatches in some cases, for example: User agent signals "mobile", but the device is large enough to show the desktop version according to the media queries. But I think accepting mismatches in these edge cases is worth the speedup in most of the cases.

I didn't dive into implementation details, because I'd like others to chime in, and tell me if they think it's a horrible idea before I'd invest 😛

[mjackson]

I think the only thing we need to give you on our end is a <Media defaultMatches> prop that you can use to override the default matches state. Then you can get as fancy as you want and we don't even have to know about it.

[mjackson]

I should clarify: you can think of <Media defaultMatches> like <input defaultValue>. It just sets the initial state.

[edorivai]

I'll dive into it thanks!

…

On Wed, Mar 29, 2017, 18:36 MICHAEL JACKSON ***@***.***> wrote: I should clarify: you can think of <Media defaultMatches> like <input defaultValue>. It just sets the initial state. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAutrquuaCG2wdQ6J8I2c9ahYGZxncNTks5rqoiogaJpZM4MrdKn> .

[edorivai]

I think I misunderstood; I thought defaultMatches was already available. But as far as I can tell it is not, right?

But yes, I think defaultMatches would be cool. Just to make sure I understand properly: on the server react-media detects that it cannot resolve any media queries, so it will apply the defaultMatches. We would have to make sure that the initial render on the client uses defaultMatches as well, to prevent client/server mismatch.

[mjackson]

The change here is really simple, probably only a few lines. Instead of

state = {
  matches: false
}

the <Media> component should do

static defaultProps = {
  // The default value of the defaultMatches prop is false. This means when it
  // is not given, the <Media> component will *not* match by default.
  defaultMatches: false
}

state = {
  // Then we just initialize state using the defaultMatches prop instead
  // of hard-coding `false` here.
  matches: this.props.defaultMatches
}

[edorivai]

Would you appreciate a PR, or are you planning to look into this yourself for a bit?

[edorivai]

I've actually got a version working with the exact changes as you outlined them. I can submit a PR if you like, but I have one question. Currently it always matches by default:

state = {
  matches: true
}

You suggest to disable matching by default, which works for me, but might break other peoples' stuff. For me the default doesn't matter, because I will always override the default. What would you prefer defaultProps.defaultMatches to be?

[edorivai]

Awesome. Are you planning to bump the NPM version any time soon?

[mjackson]

Sure, I can cut a release later today :)

[LoicMahieu]

Hi @mjackson Are you planning to... bump the NPM version ;) ? Thanks! 🚀