render components ready to be mounted on the browser

[magalhas]

By passing a new option flag static (defaults to true) we can toggle between rendering components with and without react extra markup.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[zpao]

I think you'll need an example that works to convince me this is a good idea. Or even possible. I'm pretty sure its quite difficult and annoying to actually hook this up right so your client mounts and reuses markup.

From the beginning this has been an explicit non-goal of the project. If it works and we were to do this, we'll need more checking - static:false and beautify:true are incompatible.

[magalhas]

You're completely right about the need of more checkings. Concerning the example, I'll try to provide you one asap.

Thanks.

[ajacksified]

The entire purpose of rendering react server-side is to serve up a complete page that the browser can take over, so that's an odd stance to take. If you wanted to just render templates server-side, there are a lot of easier template languages to use than react server-side.

At any rate, I've actually moved away from this project since I found that this was a non-goal and on to mounting an application as middleware that can be used both client- and server- side. (It made for better architecture anyway.)

[zpao]

You need a more integrated solution to handle controlling a whole application from front to back. Express routes + assets (stylesheets/scripts) + document title + duplicating logic on the client were more than I wanted to consider for this project. The design goal of this project was for somebody like myself who got used to the React way of thinking about components but still had entirely server-side websites. This allowed me to not have to use a templating language (we can agree to disagree about what's easier) and I could build a website in peace. As you can see the whole thing is < 70 lines including comments. If you want more and want to open source and share it, there's plenty of room for both in the world :)

[ajacksified]

Sorry if that came off as hostile - I was meaning to explain why I've moved on (because of my requirements.) This was great to get started!

[elliotfleming]

@zpao From what I had read, this was supposed to be one of the big benefits of React. Naturally, this was the first place I ended up when preparing to replace my current express-hbs view engines with react.

Do you know of anyone else at Facebook, or elsewhere, who is working toward this goal? And what exactly are the the challenges you mention? The documentation makes this seem pretty straight-forward...

For anyone else reading, @magalhas just implemented the method documented here in the official React docs.

@ajacksified could you elaborate on your solution of mounting as middleware?

[magalhas]

@ajacksified, like @elliotfleming, I would like to have a better idea of that middleware solution that works both on front and backend, it would be lovely if you could elabore it.

@zpao I still didn't find the time to elaborate a standalone example for the PR, but if you feel this is out of scope of this project I'll create a new Connect and/or Koa middleware for my use case.

[zpao]

@magalhas it's out of scope for now unless it's seamless. I don't think it's a bad idea, I just don't think the required effort has been done here. All you've done so far is change a method call with no indication that this actually does anything for you nor how to take advantage of it if it does. As of right now, static: false simply results in more markup sent to the client.

I'm leaving this open because it's not a bad idea and if you want to continue trying, I'm open to it. But I can't merge anything that I don't know even works.

@elliotfleming rendering server side for part of your page and mounting that on the client is pretty trivial. It gets trickier when React renders the whole page, there are caveats with updating parts of <head>. How do you handle page transitions & routing? Who updates the title? If this project is purporting to handle rendering your top level views, should it also be doing work on the client to handle the routing? There are projects that do that. https://github.com/andreypopp/react-quickstart is one. https://github.com/rackt/react-router/ isn't related to Express but I know they've been working on something for server-side rendering.

On the flip side, if you don't want to handle routing at all and are willing to embrace the fact that you'll server-render and mount for each page load, then I think it's doable and could be interesting to see. Basically you'd be building react-quickstart without the routing and async parts of it. You'd still need to bundle and serve the views.

[magalhas]

@zpao I don't think routing is the problem here, that's up to whoever uses this module, it depends on the solution intended. As I've said, as soon as I've got a good working standalone example I'll update the PR and we'll discuss by then, I'm 50% through it, still trying to find the time.

[ajacksified]

@elliotfleming and @magalhas -

I've released a fairly prototype, hacky version of what I'm trying to do here: https://github.com/ajacksified/switcharoo-core / https://github.com/ajacksified/switcharoo-plugin-core

The idea is that I have a server-side file (./src/server.jsx) and a client-side file (./assets/js/app.es6.js). Each of those does nothing more than take a request (from express, or from html5 history) and push it through a router (in this case, an express router clone) with a reference to a q defer object. When the promise resolves, on the server-side, I can render a react element and res.send it; on the client-side, I can mount it. (In my case, I'm building a plugin system, so routes are registered in plugin-core. Most cases will probably do it all in one project.)

I expect to write a more complete write up at some point, and I'll remove some of my project-specific code from switcharoo-core at some point to make it reusable for other projects.

[super-cache-money]

I think I may have cracked it 🍻 Check my pull request.

[mlrawlings]

I just started working on a fork of this project to enable mounting on the client. For right now this is mainly for code organization and I'm not concerned with getting routes to work on the client, but it seems silly to have components server-side and then, even for small interactions, have to resort to jQuery or equivalent for any functionality on the client.

There's a little bit of weirdness with making this work, but I'm hoping a lot of that will be hidden/removed. For right now, I think it would be best to consider it a separate project, but perhaps sometime down the road these two could merge.

I'm developing this side-by-side with a project I'm currently working on, but would love input if anyone is interested.

[magalhas]

@mlrawlings I've atually did the same half an year ago, you can find the result in here.

[wesleytodd]

I mentioned this over here but then saw this thread to. Maybe this module can solve this problem for people: https://github.com/wesleytodd/react-express-middleware

This is just an abstraction over a pattern we have been using in our production apps for a few months now. It has been working really well for us. Hope it helps :)

[codebling]

@mlrawlings it looks good but why on earth did you non just fork it?

[zpao]

I'm going to close this out since as discussed it's a non-goal. I recommend something like https://github.com/zeit/next.js/ if you want this feature (or if you've forked and have something else working, great!)