Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redux Blog Example

github.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Redux Blog Example

#11

Post by snake_case »

avolcano wrote: post #6

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 pa…

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.

Re: Redux Blog Example

#13

Post by 0mbre »

danmaz74 wrote: post #5

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)

Re: Redux Blog Example

#14

Post by bjt »

snake_case wrote: post #11
avolcano wrote: post #6

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 pa…

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 ha…

Very cool project.

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

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

Re: Redux Blog Example

#15

Post by grrowl »

0mbre wrote: post #13
danmaz74 wrote: post #5

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.

Re: Redux Blog Example

#16

Post by danmaz74 »

0mbre wrote: post #13
danmaz74 wrote: post #5

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 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).

Re: Redux Blog Example

#17

Post by dchuk »

bjt wrote: post #14
snake_case wrote: post #11

Earlier quoted context omitted.

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 ha…

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

Re: Redux Blog Example

#18

Post by snake_case »

bjt wrote: post #14
snake_case wrote: post #11

Earlier quoted context omitted.

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 ha…

Very cool project. But two weeks to shave off 6 seconds of build time? I gotta wonder: https://xkcd.com/1205/

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

Re: Redux Blog Example

#19

Post by olegakbarov »

madeofpalk wrote: post #8

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…

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.

Re: Redux Blog Example

#20

Post by madeofpalk »

olegakbarov wrote: post #19
madeofpalk wrote: post #8

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…

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…

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

Post reply on HN