Redux Blog Example | Hacker News Reader

Redux Blog Example

github.com

80 pointsolegakbarov20 comments

Cool stuff!

In a somewhat similar vein, I've been working on a static site generator (like Jekyll) that uses React/Redux instead of a templating system: https://github.com/thomasboyt/peridot

It actually is very similar to any other isomorphic React app, except instead of hosting an API, it simply renders each page out to a file, as well as a JSON version of each post that acts as the "API" used to retrieve further pages from the frontend app. There's an example site here: http://loudplaces.disco.zone/

Thanks for this! Very cool idea.

I haven't looked closely enough - do you pre-render the pages somehow to maintain SEO?

Yep! It's a bit convoluted at the moment, and I should comment it better, but it basically just does the following:

1. Get a list of all posts and compute their URLs

2. Run each URL against the React app's react-router table (https://github.com/thomasboyt/peridot/blob/master/src/pagesB...). This gets the static markup for each route.

3. Wrap this static markup in a <Page /> container (which has e.g. <script> and <link> tags for assets), and write the resulting output to an HTML file.

That HTML file is what you initially load. It then loads a Webpack bundle of the same React app, and once that's loaded, React on the front-end "re-renders" into the already-rendered React app container (though it doesn't actually re-render the DOM, as it's able to diff against the existing DOM nodes).

There's some more nuance to this - for example, the server-side rendering also passes in a Redux store with the state needed for rendering the page (e.g. the contents of a post), as well as embedding the JSON-serialized state in a <script /> tag so when the front-end code takes over, it can just load the embedded state.

Honestly, though, the isomorphic rendering only took a few hours to implement, and most of that was me figuring out how to use Redux (previously, I'd used other Flux implementations that had somewhat different concepts). The biggest takeaway I've gotten from this project is that React isomorphic rendering is way easier than I thought.

I'm also working on a React + Markdown static site generator heavily inspired by Jekyll.

For the past few weeks, I've been experimenting with how I could render both React + Markdown into HTML and minimize the numerous edge cases that occur during the build process.

For example, ReactDOMServer.renderToStaticMarkup(page) will remove all line breaks in the HTML output. The problem with that is pre/code elements will have their line breaks removed as well which for obvious reasons is not good. Oh and another problem, it converts all (or most, if I remember correctly) HTML entities to their literals.. so those code blocks may look pretty messed up in the browser.

But after weeks of experimenting with different rendering/build processes and libraries, things have finally been coming together recently. Unfortunately, my private repo is a mess due to all the tests and methods I've tried. I'm going to be releasing a clean public repo of the project soon after I develop a landing github.io page for it. That will also be open source and serve as a great example for how to use the generator.

However, I did rewrite my live website from Jekyll to my generator (need to come up with a good name still..) this past week.

http://jakedeichert.com

Regarding build times on my $5 DigitalOcean droplet, my website is built in ~3.7s with Jekyll and ~9.5s with my generator. I still have many ways to improve performance and I haven't tested NODE_ENV production mode yet which the React team says should be much faster due to no warnings/error checking. Though, most of that build time is due to Babel converting my ES6+JSX components into actual JS that Node can execute. I'll be focusing on lowering this build time for the next week or two probably.

Very cool project.

But two weeks to shave off 6 seconds of build time?

I gotta wonder: https://xkcd.com/1205/

Not that it really matters, but his system added 6s of build time, not shaved it off

I'm hoping to drop the 9.5s to more like 4-5s. I don't think it can reach the speed of Jekyll since Babel is heavily used to convert the jsx to js at the start of the generation. If everyone wrote pure js React code, then the babel step would essentially be eliminated which should definitely be a config option.

Dropping at least a second or two should be easy. My code is a beautiful mess right now, and I know there's so many parts I can improve, let alone also using the production version of React instead of the warning/error checking version.

Also, when I say 2 weeks, I actually meant more like 40 hours over the course of 2 weeks. It's a side project :)

Couple of requests

1. Add comments

There's a lot going on here and very few comments

2. In the README point out the entry point of the code

There are a lot of places one could start reading, give users a hint as to the best place to start.

Your app template.html points toward a /js/app.js file which doesn't exist in the source, which is fine, but if I'd like to read before I run a pointer would be helpful!

Thank you for your feedback. We'll edit README to better explain what's going on and how stuff works!

Out of curiosity, why didn't you use Immutable.js for your Store? You thought about it and chose a different path, or you just didn't consider it at all?

So far I can't see the use of immutableJS in redux. When using basic pattern of returning a new store on each action the store isn't mutated. Is it just a very costly convenience ?( costly cause immutableJS isn't exactly small)

The only benefit I can think of is prevention of [accidental?] modification of `state` within your selectPropsFromState functions or within rendering code itself. Which is something you should never, ever do anyway, and the mistake should be quite obvious given redux's suggested structure. Given ImmutableJS also has a performance overhead in ES5, I'd definitely agree with you.

The biggest reason we adopted Immutable.js is that it allows us to use PureRenderMixin (or, to make some situations even simpler, https://github.com/jurassix/react-immutable-render-mixin ) for all our components. This gives a great performance boost, without having to think how to design a specific shouldComponentUpdate for each expensive component.

This is especially important with Redux if you connect your store to one controller-view which then passes the props down to a big tree of components (which should be the standard way to do things with both Flux and Redux).

Nice. I love Redux + React so much, so I appreciate any effort into making people more aware of it.

I was really excited that you found a way to return proper 404's! https://github.com/GetExpert/redux-blog-example/blob/master/...

There are a few things I would have done differently though. Check out:

- this sample project I made. it's not ideal though and I have learnt a since I made this, but it has a few good ideas https://github.com/joshhunt/reactapus

- the official 'real world' example https://github.com/rackt/redux/tree/master/examples/real-wor...

Suggestions:

- Consider putting client, server, and universal code into seperate folders like in my example - it makes it easier to understand what code is executing where.

- Move routing into a 'universalRouter.js' which is the one place that performs routing and returns the root component. Both the server and client use this. https://github.com/joshhunt/reactapus/blob/master/src/app/un...

- Actions should be very simple, return basic serialisable objects, and be super easy to test. Don't make API calls directly in actions. Redux has fantastic middleware to make this easier for you. I do it in a basic way in my sample project, but the redux real-world example does it much better. Check out https://github.com/rackt/redux/blob/master/examples/real-wor...

- Consider using ESLint. Airbnb has a premade config that does a pretty good job of providing best practices. https://github.com/airbnb/javascript/tree/master/linters Beware, it's going to flag a whole bunch of stuff in you project, but you'll get much better code out of it.

FYI I've made a set of redux middleware for executing and composing effectful actions:

http://github.com/redux-effects/redux-effects

Which makes it dead simple to write universal apps and keep all your functions pure. Would love to get some feedback on it from people who are into this stuff.

Cool! i'll take a look and let you know.

Awesome to hear that you found it useful.

1. Splitting folders entrypoints — very nice idea! For now i feel it a bit cryptic.

2. Router is the thing we want to tinker with. Gonna give a look into your solution.

3. At first we had all API interactions in separate folder, and truth to be told it was not very handy. That always felt like one more file to keep track of. Maybe our current design is a a flaw. Open question.

4. We do have one! (checkout .eslintrc) I feel like it is actually even more 'strict' than default Airbnb's one.

> 3. At first we had all API interactions in separate folder, and truth to be told it was not very handy. That always felt like one more file to keep track of. Maybe our current design is a a flaw. Open question.

The common pattern I've seen is:

- Dispatch simple actions that contains 'just' a URL

- Have a middleware to take those actions, make the API call (based on the URL in the action), and then dispatch further progress, success and/or failure actions

- Receive the API data in your reducer and transform it before adding it to your store.

That's a pattern that works really nicely and is crazy easy to write tests for.

> 4. We do have one! (checkout .eslintrc) I feel like it is actually even more 'strict' than default Airbnb's one.

Oops sorry!

I should definitely take a closer look at this approach. Thank you.

PS You are also welcome to PR =)

Really liked the auth workflow that was set up here: https://github.com/GetExpert/redux-blog-example/blob/master/.... I had a hard time finding good examples recently and a LOT of trouble finding good examples w/ react-router's 1.0 branch, so this is very much appreciated :-)

Reply on news.ycombinator.com