
Redux Blog Example - olegakbarov
https://github.com/GetExpert/redux-blog-example
======
avolcano
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](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/](http://loudplaces.disco.zone/)

~~~
snake_case
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](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.

~~~
bjt
Very cool project.

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

I gotta wonder: [https://xkcd.com/1205/](https://xkcd.com/1205/)

~~~
snake_case
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 :)

------
iandanforth
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!

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

------
danmaz74
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?

~~~
0mbre
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)

~~~
danmaz74
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](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).

------
madeofpalk
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/...](https://github.com/GetExpert/redux-blog-
example/blob/master/app/server.js#L50-L52)

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](https://github.com/joshhunt/reactapus)

\- the official 'real world' example
[https://github.com/rackt/redux/tree/master/examples/real-
wor...](https://github.com/rackt/redux/tree/master/examples/real-world)

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...](https://github.com/joshhunt/reactapus/blob/master/src/app/universalRouter.js)

\- 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...](https://github.com/rackt/redux/blob/master/examples/real-
world/actions/index.js#L38)

\- 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](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.

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

[http://github.com/redux-effects/redux-effects](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.

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

------
awinder
Really liked the auth workflow that was set up here:
[https://github.com/GetExpert/redux-blog-
example/blob/master/...](https://github.com/GetExpert/redux-blog-
example/blob/master/app/routes/index.js). 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 :-)

