Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: The Road to learn React – Build a Hacker News App on the Way (robinwieruch.de)
339 points by rwieruch on Dec 13, 2016 | hide | past | web | favorite | 22 comments



The previous tutorial posts by Robin are fantastic, and cover topics like React, Redux, MobX, Flow, and ESLint ([0]). This book looks to be even better. I'm going to preemptively recommend it without having even read it yet, because I know it'll be extremely well written.

As a similar note and bit of a self-plug: I keep a big list of links to high-quality tutorials on React, Redux, and related topics, at [1]. Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a source of quality info on more advanced topics. I've also been blogging at [2] on React and Redux usage, and just posted "Practical Redux Part 5: Loading and Displaying Data" [3], the latest in a tutorial series intended to demonstrate some intermediate to advanced usages of React and Redux.

[0] http://www.robinwieruch.de/

[1] https://github.com/markerikson/react-redux-links

[2] http://blog.isquaredsoftware.com/

[3] http://blog.isquaredsoftware.com/2016/12/practical-redux-par...


Thanks for recommending Robin's other articles! I've never seen them before and they look fantastic. I was sold as soon as I saw this paragraph near the start of the Redux vs MobX article:

"Everyone wants to have state management in an application. But what problem does it solve for us? Most people start with a small application and already introduce a state management library. Everyone is speaking about it, aren’t they? But most applications don’t need ambitious state management from the beginning. It is even more dangerous, because most people are never going to experience which problems libraries like Redux or MobX solve."

One of my biggest annoyances with Javascript is that people who create new tools fail to educate potential users about the problems the tools solve, and as a consequence, a lot of developers just build these huge stacks with all the trendy tools without even knowing why they're using them. Often in the documentation for a tool there's too much focus on the 'what' and not enough on the 'why'.

The more writers harp on this point and encourage developers to learn about the tools they're using, the healthier the Javascript ecosystem will be in the long term.


To be fair Dan Abramov, who wrote Redux, repeatedly tells folks they don't need it: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Unfortunately, the general sense from the community is that it's an essential piece of the React ecosystem.


All respects to Dan Abramov, this is not necessarily true. Under the guidance of the right teacher, who knows the use cases and reasons for using redux with a React app, it can make perfect sense to learn them together. It's not easy, but most things worth it are not.

There's a reason why many experienced developers choose Redux to manage the state of their React apps. Specially once you get into async and server-side rendering, you will want or need Redux middleware such as Redux-Thunk-- or perhaps you'd like to take it a step further into observables with RxJS and Redux-Observable.

Perhaps these are all just a bunch of terms that you might not know that you need when you're first getting into React. But if you want performance and scalability -- and need an app that can withstand the pressures of today's demands -- then you may actually want to learn about all of these possibilities.

But sure -- if you're just getting into react, then by all means learn React on its own. But if you're running a large production app, I would recommend that you use redux and perhaps RxJS in conjunction with it.


Part of me thinks that Redux is going to end up being the next Java EJB - really great and important concepts at the heart, but over-adopted in scenarios which don't need it. And in a few years, there will be a backlash about it due to too much code and complexity needed to do simple things.


Dan is correct (naturally); depending on complexity and scope redux can be a drag. For a small project I will use an event emitter to communicate state change requests to my top level component. These sort of things tend to only have a handful of components anyhow.


Do you know of any high quality Vue tutorials such as the one in OP?


Here's a great series on Vue 2:

https://www.youtube.com/watch?v=vzSjlLzGB1A&list=PLwAKR305CR...

Egghead also has got a Vue 2 series but I've yet to watch it though it comes recommended.

https://egghead.io/courses/develop-web-apps-with-vue-js


If you don't mind video guides, I can really recommend Laracasts[0]. The name implies that it only talks about Laravel, but it does not. :) Jeffrey is a great teacher and explains everything really well.

[0] https://laracasts.com/series/learn-vue-2-step-by-step


Afraid not. I haven't used Vue or tried to learn it, so I haven't accumulated any relevant links.

That said, I'd generally suggest starting with the official docs, and the "awesome-vue" list looks like a good set of resources:

https://github.com/vuejs/awesome-vue


Not a tutorial, but one of the official vue demos is a Hacker News clone: https://github.com/vuejs/vue-hackernews-2.0


Thanks for these. Out of curiosity, do you currently work with React on a daily basis?


Yep, using it in my main work project right now (as well as the sample app I'm writing for my tutorial series).


Love this book, the flow, the levels, and the rhythm!

The only thing I stay apart from, is the implicit approach of ES6.

IMHO, explicit is better than implicit. Therefore:

    return (<div>...</div>)
Is better than

    {
      <div>...</div>
    }
and

    this.state = { list: list };
Is better than

    this.state = { list};
Everyone these days seems to take the implicit ES6 way though.


Well, explicit is better than implicit when there is a very real chance of missing the implicit, especially when just going over the code quickly. The return example is a good case of this, reading over code you can easily miss that those particular brackets are supposed to be a return.

I think though that this.state = { list}; is just as easily understandable as this.state = { list: list }; once you are familiar with the syntax, and may be even more easy to understand due to the being easier to read.


Thanks for your honest feedback! I agree with your opinion. But at some point I had to make a decision how to address the ES6 topic. In the end my opinion was that you can't get away from learning ES6. Personally I learned ES6 on the way when I picked up React. It felt just natural and I hope that the readers will do so as well. Still I tried to cover most of the code pieces in an explicit way before I do them more implicit. But I have to be honest that I didn't thought about

(<div>...</div>)

vs

{ <div>...</div> }

:)


Two days ago I made a comment about HN evangelizing React, but never posting any good/current getting started points. I officially stand corrected.

I'm still curious about reasons to invest time in learning it over plain old javascript.


The React docs were recently rewritten by Dan Abramov ([0]). He's also spent a lot of time building Create-React-App ([1]), a project creation tool that provides all the build handling for you so you can just jump in and start writing code. CRA has been compared to a boilerplate, but unlike most boilerplates, it's designed so that you can keep upgrading one dependency and get all the build updates as they come out ([2]). It's a great way to start using React.

Besides the React docs, the authors of a book called Full Stack React are currently doing a tutorial series called "30 Days of React" ([3]), which has been excellent so far. Covers a lot of key topics. Also see my main comment above for my list of links to React tutorials and resources.

As for reasons to use React: I could talk about it for quite a while, but I'll stick with just one for now. Going from imperatively poking around at the DOM and toggling things to simple declaring what the UI output should be based on props this component was given and state this component controls is a huge improvement. It takes some time to switch your mind around to thinking in that style, but once you do, your code becomes much more predictable and straightforward.

[0] https://facebook.github.io/react/

[1] https://github.com/facebookincubator/create-react-app

[2] https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...

[3] https://www.fullstackreact.com/30-days-of-react/


I would add in addition to being more predictable it's significantly easier to test. If you fully embrace having stateless components, those components take inputs(props) and have a straightforward output (the elements they generate) which shouldn't have any side effects. A unit test can easily capture this behavior rather than building up a large test suite to test a button click.


Pedantry alert: small typo - "if you can effort it" should be "if you can afford it".


Why would you want to teach React without Redux?

I failed on the trap as well, I mean, why would you want to add yet another 'concept' to your stack when you can just get a simpler piece of code do the same thing as a more complex one?

The truth is that if you're going to build something as simple as a simplified Hacker News clone, you can just get along using concepts of Redux with plain-old React without actually using Redux.

However, if you want to build a much more complex frontend system using Redux does give you a utility.


I get your point. But I think you have to see it from two directions: real world developing and teaching.

When I wrote [The SoundCloud Client in React + Redux](http://www.robinwieruch.de/the-soundcloud-client-in-react-re...) I made the mistake to think one could learn everything at once. I agree with your point that, when you are developing a more complex app, you will need some external state management eventually. But when you want to teach about one subject, I learned to stick to that subject and to teach it properly before students should dive into something else.

I can't agree with your other point to use only Redux without React internal state management. Once your app grows more complex again, you don't want to store everything in your global store. (You shouldn't do so from the beginning.) In a development environment with multiple developers/teams you want to keep your store tidy. I had to learn that the hard way, because I made the mistake to learn React + Redux without React's internal state management in the beginning.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: