Hacker News new | past | comments | ask | show | jobs | submit login

I've been working on learning React, and finding it particularly difficult. It appears there are a large number of things I need to have in place and pieces of knowledge I need before I can use it. These include some kind of Js compilation step like Webpack or Browserfy, something like Babel, a knowledge of how to use ES6, an understanding of React, and an understanding of how to use React-Router.

Although I've done some Javascript on the front end, I haven't done the other things I mentioned. The tutorials all seem to assume I know how to do everything but one little piece of detail, and I'm finding it difficult to bite on the elephant. It's hard to tell where to start on learning this stuff, and how much I need to learn before I can use it.

Any suggestions for what resources and approach to use to learn react? My goal eventually is an app that runs in 3 versions: web, iOS, android. I don't intend to use javascript on the server.

I found this tutorial a very good solution to the problem you describe:


It assumes very little and builds an app from the ground up, including configuring Webpack, Babel, react-router etc, explaining what it's doing along the way.

It does use Javascript for the server, but it's well abstracted so it's clear where to swap out the server if needed. (I actually skipped over the server part of the tutorial on the first run through and it didn't hurt my comprehension.)

I started here: http://reactfordesigners.com/labs/reactjs-introduction-for-p... (h/t tptacek).

And then I found the egghead.io videos particularly helpful. Nice bite-sized chunks, very focused: https://egghead.io/technologies/react

There are a number of free lessons. I found them useful enough to pay for a subscription. YMMV.

Start with an HTML boilerplate which takes care of the details of transpiling (which are initially irrelevant to you in learning mode). My first react app started out in a file like this [1] and I didn't go and figure out how to set up a build or use ES6 features until I was > 1000 lines into it, with a working prototype.

If you have an idea for something you want to build as a learning experience, following the same flow as Thinking In React [2] is a good way to get started, using the docs as a reference as you start to explore each area.

- Start by writing a single component which implements render() to get a feel for using JSX.

- Then pass some props into it to get a feel for working with those and interpolating JS using {}.

- Then create a second component and use it from the first component's render() via JSX.

- Once you've done that, you should have enough knowledge to create a static prototype of whatever you want to build while learning and you can play about with componentisation as you go.

- Once you have a static prototype, you can start to learn about state and pass callbacks to child components when they need to update state held somewhere above them.

Just do the simplest thing to get it working until you understand what's going on with props and state. Don't jump straight into React Router, as you'd be missing a chance to learn about, for example, state (to control the current page), conditional rendering (to display whatever should be the current page component based on state) and component lifecycle hooks (to register a basic hashchange event handler to implement your own simple back/forward support). Don't jump straight into Redux, Flux or a cursor implementation, as you won't get a chance to experience the problems they solve first-hand. Build up your app's complexity gradually and come back to these things later once you feel like you have a handle on things.

[1] https://gist.github.com/insin/9c0712cef6ac8583b742#file-reac...

[2] http://facebook.github.io/react/docs/thinking-in-react.html

>and an understanding of how to use React-Router.

Gosh no. You don't need react router for simple applications.

When someone is looking at something in the app, I need them to be able to paste a link to someone else, and have the recipient see the same thing. Sounds like a job for react-router, right?

you can use history api or many of the simple abstractions like page.js.

react-router is waay to complicated for trying to do everything in a declarative way.

I'll start off by stating that I am not a frontend dev, but I've been trying to learn React to connect it to a backend API and I too find it difficult for the same reasons you stated plus some others:

- The FB React docs are a bit scattered in terms of content and not as intuitive / helpful for a beginner as I'd hope they be

- I often resort to referencing other people's code from Github, StackOverflow & Google and the mix of ES5,6 & 7 styling used is hard to wrap my head around, especially when I try to find a source of "truth" on how to adopt the more idiomatic way of doing things seeing how everyone is using a different version from docs to examples

- React-Router's docs & code samples vary widely from what they state in the repo vs what people are actually using, and the whole pre 1.0 / post 1.0 way of using it has bitten me more times than I care to count - this is most likely me jumping in at a transformative time in the project

- Learning tools like webpack, browserify, babel, gulp etc. have been nothing short of a learning curve and these tools are basically required to be useful in React without repeating yourself from running commands over & over again when developing

- I've learned Flux's architecture, understand the concept, have integrated its structure into my code and know that this is the proper decoupling required, but its definitely not been an easy process for me to have to think about how I need to modify the flux pipeline for new functionality and how I can cut down on repetitive code.

- I don't understand how to manage state properly when I navigate to another page - this creates issues for me around the combination of flux + react-router as my lack of experience with them as well as lack of proper examples to utilize make the two difficult to address some of the state management issues I encounter. i.e. If a user logs in & they have a token, do I make use of local storage, do I not, how do I navigate to another page seamlessly with information I want to pre-specify such as the fact that a user is logged in and some of their basic info so I dont have to hit an API etc.

- Lastly, I fear committing to an all-in javascript-dependent solution for a frontend will segment users in terms of it working or not - see http://maketea.co.uk/2014/03/05/building-robust-web-apps-wit... for the tidbit about how SquareSpace's page is completely blank if javascript is disabled - this worries me that I may have a user that can't even interact with my page either because they disabled javascript, or because their browser is outdated/lacks expected functionality.

I know most of these issues stem from my lack of exposure and knowledge in this frontend endeavour. Nevertheless, I have to assume others are getting bit by many of the same issues as well and I constantly question if I'm biting off more than I can chew with React, as well as if I should just go back to the more traditional way of doing things on the server-side which I happen to know & understand already.


To your last fear... we're using a noscript > meta element combination to refresh/replace to a noscript.html page for users without JS... same for old Ie (conditional comment) for that matter.

Higher in the thread there's a reference to a Full Stack Redux Totorial that looks really good so far, only skimmed it... as a starter point.

Your state is best as one big state tree passed through components as props... your events/dispatchers can then trigger requests to load from stores... these stores then signal when data is loaded, which can trigger an update to state, which causes an update/render to your ui. The Redux workflow is a distillation of the flux framework overall, and might be an easier place to start, and stay with.

As for local storage, your stores can use local/session storage to save information locally for requests... for that matter, you could save your current state to session storage in case of a reload/refresh, etc.

As for router... not all SPAs need to change routing... It makes it a bit more complicated, and your stores can/should be your interaction with data that may be available locally or via server.

Applications are open for YC Summer 2020

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