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

Themes: Use details middleware for server-side rendering #3562

Merged
merged 17 commits into from
Mar 9, 2016

Conversation

ockham
Copy link
Contributor

@ockham ockham commented Feb 25, 2016

In the /themes route in server/pages, use my-sites/themes to create a theme sheet element tree in context.layout, and renderToString() that.

  • Adapt express's req context to be able to use it with middleware that otherwise operates on page's context. props @mcsf
  • Add a package.json that sets different entry points on the server and in the browser (not everything required by my-sites/themes/index.js is SSR-ready yet, so we need a pruned version for the server).
  • Move theme details specific async data fetching to a separate middleware in my-sites/themes/controller/index.node.js.
  • Move generic renderToString caching to server/render.
  • Cache Helmet data, so title etc are properly set.

To test:

  • Check that everything still works as before.
  • Try logged-out /theme/mood, with JS disabled. Note that the title is now set to 'themeName Theme — WordPress.com' (instead of the generic 'WordPress.com', as on master).
  • Note that logged-in /design and /themes/something routes server-render the logged-out layout (masterbar!) before it's being replaced by the logged-in one on the client. While we want to fix this in the long run, it is no behavioral change from master.

Note:

/cc @seear @ehg @mcsf

Follow-ups: #3302, #3774, #3795, #3425

I'd say this closes #185 :-)

@ockham ockham self-assigned this Feb 25, 2016
@ockham ockham force-pushed the update/themes-use-details-middleware-server-side branch 4 times, most recently from 5091c86 to f71f418 Compare February 25, 2016 18:54
@ockham
Copy link
Contributor Author

ockham commented Feb 25, 2016

Getting

Error: Cannot find module 'indexof'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (wp-calypso/node_modules/component-classes/index.js:5:13)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
Makefile:96: recipe for target 'run' failed
make: *** [run] Error 1

@mcsf @ehg @seear Any experience from past component woos how to fix that?

@ehg
Copy link
Member

ehg commented Feb 26, 2016

Any experience from past component woos how to fix that?

NMR it, and seek an upstream fix :)

@ockham
Copy link
Contributor Author

ockham commented Feb 26, 2016

Been there, it seems: 8447-gh-calypso-pre-oss :-/

@ockham
Copy link
Contributor Author

ockham commented Feb 26, 2016

Hmm, just adding new webpack.NormalModuleReplacementPlugin( /^indexof$/, 'component-indexof' ) doesn't do the trick (nor does lodash/noop) -- probably because this is happening somewhere down in node_modules/, which we're not bundling through webpack?

@ockham
Copy link
Contributor Author

ockham commented Feb 26, 2016

seek an upstream fix :)

component/classes#27

@ehg
Copy link
Member

ehg commented Feb 26, 2016

Right, so the way we're trying to avoid loading non-iso-compatible controllers is suspect.

import { loggedOut, details, makeLoggedOutLayout } from './controller'; will result in attempts to resolve and load all dependencies in the controller.

What I imagined was having separate node/web controllers, so this wouldn't happen. Maybe put all SSR-compatible controllers/middleware in controllers/index.node.js, and have controllers/index.web.js specify the web-only stuff, and also pull in controllers/index.node.js, so we're DRY.

FWIW, I think we can solve the component.js issues using webpack's resolve.alias: https://webpack.github.io/docs/configuration.html#resolve-alias — but that's not going to help us much at this point in time.

Object.assign( context, render( context.layout ) );
}
context.res.render( 'index.jade', context );
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should move this function to server/render, I think.

@ockham ockham force-pushed the update/themes-use-details-middleware-server-side branch from 7d15e15 to 965fd4f Compare March 2, 2016 14:55
@ockham
Copy link
Contributor Author

ockham commented Mar 3, 2016

Rebasing this on master now that #3279 is in turns out to be a major PITA. I'm afraid we'll have to untangle some code in server/pages with a separate PR before this is feasible...

@ockham ockham force-pushed the update/themes-use-details-middleware-server-side branch 4 times, most recently from ef15ccd to d2af217 Compare March 5, 2016 22:01
@ockham ockham added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress labels Mar 6, 2016
@ockham ockham force-pushed the update/themes-use-details-middleware-server-side branch from 21e597f to 791bcde Compare March 6, 2016 17:33
compose( ...liftedmiddlewares )();
}

function compose( ...functions ) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can we use lodash's flowRight instead?

Copy link
Member

Choose a reason for hiding this comment

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

(For the record, flowRight wasn't fit for a drop-in replacement. It was agreed that having this local implementation is fine.)

<ThemeDetailsComponent id={ themeSlug } section={ contentSection } >
<ThemeSheetComponent />
</ThemeDetailsComponent>
);
Copy link
Member

Choose a reason for hiding this comment

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

We're redeclaring a component on each middleware call here.

@seear
Copy link
Contributor

seear commented Mar 9, 2016

Reviewed/tested as a team

20160308_165327

ockham added 17 commits March 9, 2016 15:04
Add a `package.json` that sets different entry points on the server and in
the browser (not everything required by `my-sites/themes/index.js` is
SSR-ready yet, so we need a pruned version for the server).
In the `/design` and `/themes` routes in `server/pages`, use `my-sites/themes`
to create element trees in `context.layout`, and `renderToString()` that.

 * Adapt `express`'s `req` context to be able to use it with middleware that
   otherwise operates on `page`'s `context` (props @mcsf).
 * Add docs
To avoid confusion with `context.layout` holding a Layout *element*.
@ockham ockham force-pushed the update/themes-use-details-middleware-server-side branch from d72b9fd to 0c6abfa Compare March 9, 2016 15:05
ockham added a commit that referenced this pull request Mar 9, 2016
…ddleware-server-side

Themes: Use `details` middleware for server-side rendering
@ockham ockham merged commit f983440 into master Mar 9, 2016
@ockham ockham deleted the update/themes-use-details-middleware-server-side branch March 9, 2016 15:12
@nylen nylen removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Mar 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature Group] Appearance & Themes Features related to the appearance of sites. Server Side Rendering
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Server Side Rendering: Render a logged out layout via a pure component tree
5 participants