Server-side renders flashes broken Masonry view

[stanleycyang]

On initial load:

On client-side JS kick:

[stanleycyang]

This is when using isomorphic react + react-router

[afram]

@stanleycyang have you tried using Masonry's stamp method?

http://masonry.desandro.com/methods.html#stamp

EDIT: I just read your question again, sorry.

Currently there is no server side rendering support. You might be able to do it if you use JSDOM to render server side, but that will take a bit of work.

I am currently also looking for a solution to this, I welcome any feedback/input you have in this area :-)

[Peege151]

Just coming across this now, and I'm having the same issue. Has anyone progressed this or done any work on this yet? As of now I am adding Masonry to the state in a componentDidMount().

[afram]

@Peege151

I believe server side rendering in place is not a trivial thing to accomplish. There are a few ways to solve this problem, and probably a few more I haven't considered.

1) Assuming responsive design, on the initial request you do not know the width of the viewport, only the useragent. From there you would have to map devices to likely viewport widths and probably use jsdom to render in place.

2) If you don't have a responsive site, you can use a similar approach to the one above but your width is a constant.

3) You can render a small subset of items server side (say 1 row or less) and load the rest on the client.

4) If using Webpack, maybe you can load your JS at the top of the page before the body is downloaded/parsed. That should probably fix the issue, but you will have to wait for blocking JS code. For this reason it might be a good idea split out all non-core JS from the core bundle.

For my projects, I am going to try 4 and 3 as they are the simplest and could lead to the biggest gains. If your site requires good SEO, then going with option 3 may or may not work for you (Google is quite good at dealing with ajax these days though)

Will update this ticket with findings.

[afram]

I ended up going with option 3. A small number of items is rendered server side and the rest loaded async on the client.

This works for my use case. If you do not want to split item rendering between server/client maybe you can consider loading all items on the client async.

[karaxuna]

I changed opacity depending on where it is rendered, on client side or on server side:

var style = {
    opacity: process.env.BROWSER ? '1' : '0'
};

<div style={style}>
    <Masonry options={options}>
          ...
    </Masonry>
</div>

[afram]

@karaxuna I'm curious how that works for you? What happens on the client?

[mrsufgi]

@afram can u explain how did u actually got option no.3 to work? the items that are rendered via server still need a browser width no?

[mrsufgi]

I tried using it with my SSR app, and unfortunately it doesn't apply the grid inline styling on the server pass, no reason why it shouldn't. Since this grid is based on percentages, it might be the best solution for SSR grid

[afram]

@mrsufgi I use the useragent in the request header to determine how many items to render across the first row. I then load the rest on the client.

This is a little hacky admittedly, but it does the job for my use case. We are probably going to move away from this and to a different UI layout anyway.

Hope this helps.

[elmpp]

A simple hack i've employed is to just still do full SSR but with style={{visibility: 'hidden'}} on a top level container and then switch that off through the onLayoutComplete ref.

I tried initialising masonry on the server through a hacked componentWillMount but this was just plain silly. :woman_facepalming:

[AviKKi]

@eiriklv is there any update on this? If not I can contribute.

[eiriklv]

@AviKKi I'll add you as a contributor

[eiriklv]

@AviKKi Send me your npm user if you need to publish access

[AviKKi]

Thanks @eiriklv for inviting me to contribute, my username on npm is avikki

This project seems to be working fine with nextjs, so for now I'll look over other issues.