Write example recipe for SSR

[jordanh]

This is something I wished I would have asked you about when we were laptop-to-laptop last week.

A universal app has two stores, one for the SSR and one for the client (which can be delivered to the client from the SSR). Following the pattern from Meatier and Action, these stores are created in:

• src/server/createSSR.js
• src/client/client.js

For testing purposes, our application is currently pulling in the Cashay singleton from src/client/client.js into its universal components. This does Bad Things™ during a production build (npm run build:server).

What's the recommended pattern here?

1. Should Cashay be eliminated from universal routes (ick) as it's really a client cache?
2. Should the Cashay singleton be moved into src/universal/... and should it import the appropriate store (exported by src/server/createSSR.js or src/client/client.js) depending on which context it's running in?
3. Something else?

[mattkrick]

I haven't moved my full thought train here yet, but what i envision is full SSR capability.

How we'll achieve that is by loading up the state on the server & then sending the state down the wire.

At first glance, it may seem odd that the redux state has some state & the singleton has other "state". But, if you look closely, the singleton actually only holds "computed values" (term borrowed from MobX).

That means we can recreate the singleton based solely off of the redux state. 🔥.

After all, cashay is just a cache, your state stays in redux 😉

[jordanh]

That makes a ton of sense to me. Perhaps this issue can become the tracking issue? I'd like to make a list of all the issue deps for Action Cashay refactor so we can prioritize effort...

[mattkrick]

Done, i started writing recipes on my new working branch (mostly for me, but i guess it'll be useful for other folks, too). I'll keep this issue open & write up a recipe after we implement it successfully in Action

[danbruder]

Awesome! This will be helpful. I have questions but will hold off and go through your examples when posted.

[mattkrick]

Alrighty, finally digging into this & the reason it barfs right now is because I recommend you import the singleton from something that's only created client side, and of course the cashay singleton isn't created when it's SSR'd...

An easy fix would be a webpack if (__CLIENT__) conditional, but i'm trying to think up a webpack-agnostic solution...

[mattkrick]

another idea would be to cache the singleton in cashay. that way you could say cashay = new Cashay() and if it was already created, just hand it back the cached instance.

[mattkrick]

a 3rd would be to do away with the Cashay class.

so this

// index.js
import {Cashay} from 'cashay';
new Cashay(params);

// component.js
import {Cashay} from 'cashay';
const cashay = new Cashay()

becomes this:

// index.js
import {cashay} from 'cashay';
cashay.create(params);

// component.js
import {cashay} from 'cashay'; // ready to go!

calling create again could overwrite current props, effectively obviating the need for setTransport, too. I like this, i'm gonna run with this one.

@jordanh

[jordanh]

I am having recollections of managing the react-look singleton. Remember those days?

Which are you leaning toward?

Jordan
@jrhusney(http://twitter.com/jrhusney)/612.227.5673(tel:612.227.5673)

On Jun 15, 2016, 11:14 -0700, Matt Kricknotifications@github.com, wrote:

a 3rd would be to do away with theCashayclass.

so this

// index.js import {Cashay} from 'cashay'; new Cashay(params); // component.js import {Cashay} from 'cashay'; const cashay = new Cashay()

becomes this:

// index.js import {cashay} from 'cashay'; cashay.create(params); // component.js import {cashay} from 'cashay'; // ready to go!

@jordanh(https://github.com/jordanh)

—
You are receiving this because you were mentioned.
Reply to this email directly,view it on GitHub(#53 (comment)), ormute the thread(https://github.com/notifications/unsubscribe/AAGSWI8KG65XRAsLcXCZb7z0INQRre7Oks5qMED6gaJpZM4Iz09S).

[mattkrick]

@jordanh i've blocked those from my memory, they never existed la la la.

Happily, the solution we came up to fix that react-look problem works here, too. But let's imagine that we didn't do that fix...
we create a cashay singleton on the server, feed it a store, transport, etc. Then, when the cashay version that is bundled inside webpack runs, it doesn't have those things.
To fix that, we'd have to call cashay.create somewhere within the code that is webpack bundled. So for example in our AppContainer we'd have something like

if (__CLIENT__) // build for client else if (__SERVER__) //build for server

those who don't use webpack won't have this double instance problem, so it's safe to assume they can use compilation-time variables.

[jordanh]

Beautiful! As long as the state can be rehydrated, I am all good!

Jordan
@jrhusney(http://twitter.com/jrhusney)/612.227.5673(tel:612.227.5673)

On Jun 15, 2016, 16:30 -0700, Matt Kricknotifications@github.com, wrote:

@jordanh(https://github.com/jordanh)i've blocked those from my memory, they never existed la la la.

Happily, the solution we came up to fix that react-look problem works here, too. But let's imagine that we didn't do that fix...
we create a cashay singleton on the server, feed it astore,transport, etc. Then, when thecashayversion that is bundled inside webpack runs, it doesn't have those things.
To fix that, we'd have to callcashay.createsomewhere within the code that is webpack bundled.

—
You are receiving this because you were mentioned.
Reply to this email directly,view it on GitHub(#53 (comment)), ormute the thread(https://github.com/notifications/unsubscribe/AAGSWPKQ5VdG4OFKvzbw-Pxpy1Tze1b5ks5qMIr6gaJpZM4Iz09S).