More detailed examples

[ChrisCates]

Hey,

I found the example documentation to be sufficient to understand the concepts. However, implementation was not possible.

I am intending on using Hypernova with React-Router and/or Redux. And I'm wondering if my application structure will permit this.

Something such as:

//Render components
function App (props) {
  return (
    <Router history={browserHistory}>
      <Route path="/" component={Index}/>
      <Route path="*" component={NoMatch}/>
    </Router>
  )
}

export default renderReact('App.js', App)

Does not render when you hit the desired Port of Hypernova (using the hypernova/server package).

If it's possible. Writing more detailed documentation would be fabulous as the pros of Hypernova vastly outweight the cons in terms of implementation of traditional server side rendering with template literals.

[goatslacker]

I'm working on making a complex "real world" example which uses some of the tech you've mentioned.

What sort of error are you getting now?

[ChrisCates]

@goatslacker Nothing. just a 404.
After this issue I've been seriously considering building a server side rendering library that couples directly with React-Router.

Is there some sort of roadmap for your product so I can get a good idea if I can contribute to this library (or do my own thing).

[ljharb]

@ChrisCates we'd absolutely love hypernova to be compatible with react-router - we use react-router in a few places that aren't yet server-rendered, and hope to server-render them soon! It'd be great, if changes are needed in hypernova to work with react-router, if you wanted to file issues and make PRs to help :-)

[ChrisCates]

@ljharb I'll consider it. I'm still on the fence about creating my own FOSS NPM Module. I see me investing a lot of time in multiple use cases that go beyond React-Router, Redux and reengineering your current module would be questionable if it's not a pivot you're willing to make.

If you're up for it. We can talk on google hangouts at cc.chriscates.cc@gmail.com

Thanks, Chris

[goatslacker]

What version of RR are you using? I'll replicate this today.

[ChrisCates]

@goatslacker I wasn't using Ruby on Rails. Was using Express and Node V6.0.0 with Babel.

You should make it more explicit how it works. As it is deceiving that there is a hypernova-node repository but it does not have clear documentation on how to run it.

[ljharb]

I don't think "deceiving" is a fair or an accurate word. Certainly every project can always use better documentation, and please do file an issue requesting it on hypernova-node if you have actionable feedback for us.

[goatslacker]

@ChrisCates RR = React Router. (RoR = Ruby on Rails) My bad for not being explicit.

Edit: I'd appreciate feedback on what bits you confusing. hypernova-node has an exampleServer which I regularly use to test out changes.

"How it works" is explained at high-level here. I know that doesn't present any details but I'd love to know what sort of details you're looking for.

Also, Hypernova's main objective is to render your views when your server is in a different language than the one you're using to build your views.

If you're running Node, you might as well just render the views yourself and avoid having to introduce Hypernova into your tech stack. I'd love for you to use Hypernova but the tradeoff might not be worth it :)

There are reasons to use Hypernova even if you use Node, mainly if you want to separate out your rendering service...or if you just want to play with it.

[ChrisCates]

@ljharb For sure! I completely understand. I just got the impression it was a rendering service FOR node. Sorry for the wrong choice of words. Even my NPM modules could use more detailed documentation too. :)

@goatslacker I understand completely, and now understand why there was such a big disconnect with this project. This comes back to the idea of creating my own rendering service that couples directly with React Router, Redux State and is SEO optimized and has a solid caching strategy (with defaults to choose from).

I think in general server side rendering with template literals is mundane. And creating scalable solutions in terms of some sort of mappable schema for the HTML document would make it more scalable, as well as computing React components and React routes autonomously. This could even be pre-compiled instead of rendered on the fly so that you don't get penalized for using Babel on the server.

Hopefully that makes sense. I'll close this issue for now. Thanks so much for the information and feedback. I truly appreciate it guys.

[ChrisCates]

There are several projects that will stem from this conversation:

One for higher order functional programming to manipulate template literals as if they were HTML documents.

Second is a server side rendering strategy that couples directly with React Router

Third is a server side rendering strategy that pushes Redux state to Redis to be remapped to the client if/when they leave the server. (Most likely implemented in Socket.io and is completely optional)

Fourth is a caching strategy template system to use directly with Express.

Thanks so much for helping me come up with awesome ideas guys!
I appreciate it. ❤️

[goatslacker]

A bit of follow-up on this.

The following code sample will not work on any server-rendering environment (unless you're using jsdom or similar) because the DOM isn't available. browserHistory expects there to be a DOM and throws an error if one isn't available.

function App (props) {
  return (
    <Router history={browserHistory}>
      <Route path="/" component={Index}/>
      <Route path="*" component={NoMatch}/>
    </Router>
  )
}

To server-render with React Router you'll need to use match and friends which is explained here.

[goatslacker]

@ChrisCates if you're up for it, I'd love to hear how you intend to use react router on the client + server.

[ChrisCates]

@goatslacker add me on google hangouts: cc.chriscates.cc@gmail.com and we will discuss the use cases I intend to work on.

Would love to collaborate where possible as well too.

cc @ljharb