14 ms·

A Primer for Building Single Page Applications with React

352 points by tilt 12y ago

mcx 12y ago
Author here, the primer is still in the draft phase but feel free to share your feedback / make pull requests!
- krat0sprakhar 12y ago
  Thanks for the guide. Looks awesome! I've recently started working on a SPA in React and was desperately googling around information. Glad to see it in one document. BTW - I can see that the section on Flux and Alt is still left to be written. Any idea when you'll have the drafts for those sections ready? Lastly, it would be nice if you could contrast Alt with Reflux and give us your recommendations on what to work with. Thanks a lot, again!
  - mcx 12y ago
    At the rate I am going, I am hoping by next week. But, the author of Alt has already written an amazing getting started guide: http://goatslacker.github.io/alt/guide/ http://goatslacker.github.io/alt/guide/ - check it out! As for a contrast between Alt/Reflux, I am hoping others using different Flux libraries will contribute and share their views, I will also link to some comparisons others have already done, such as: http://pixelhunter.me/post/110248593059/flux-solutions-compared-by-example http://pixelhunter.me/post/110248593059/flux-solutions-compa.... But if I have time to, I'll give it a try!
- otar 12y ago
  Thank you! This guide is very well-structured and easy to read.
- deleted 12y ago
  [deleted]
- ClayM 12y ago
  How hard would it be to adapt this to non SPA?
  - mcx 12y ago
    It's not really that SPA specific, if you want to just use React for the View, then Part 1 and Part 4 (to be written) is probably all you need to get started. Collectively, all the parts of the primer, together should give you the tools you need if you want to build a SPA.
- fudgy73 12y ago
  Great guide. Thanks a bunch. Glad you're feeling better! :-)
- chippy 12y ago
  Completely new to React, your introduction was spot on. Many thanks.
pixelHD 12y ago
I've been looking for such a guide for react! thanks!
phelmig 12y ago
I have been toying with reactjs a few weeks ago and this would have helped a lot to get going. Great guide!
JDDunn9 12y ago
Can you build an SPA using just React? At the very least it seems like you'll need a URL router, and something like underscore.js to fill in the gaps.
- krat0sprakhar 12y ago
  Correct! The author has sections outlined for React-router / Flux[0] which, I believe, will be used to detail out the other parts of the app. [0] - https://github.com/mikechau/react-primer-draft#react-router https://github.com/mikechau/react-primer-draft#react-router
- mbrock 12y ago
  The "URL router" in my current project begins with "onhashchange = function () {" and is essentially a five line conditional. It might grow to ten lines. All it does is set the root props based on query parameters. Not rocket science. I'm using Fetch.js and a Promise polyfill in order to do AJAX stuff (the native XHR API is a bit tedious). But basically the answer is: yes, you can! You can even write an SPA using nothing but the regular W3C APIs! React just makes it very easy to keep the DOM in sync with your application state.
  - krat0sprakhar 12y ago
    I, for one, would love to know more about how this is done. Is your code open-sourced by any chance? Thanks!
- masklinn 12y ago
  > Can you build an SPA using just React? Sure. You may not want to depending how big and complex the application is, but it's definitely possible. A router and an immutable collections library (immutablejs or mori for instance) are very convenient additions, but by no means necessary. Hell you don't need a precompilation phase either by skipping JSX (and unsupported ES6 constructs).
- pachydermic 12y ago
  I had to write my own router, but the event system [1] allows you to catch left-clicks or touch events and let you decide how to handle them and the lifecycle functions [2] allow you to update history/URL params to reflect the state of your app. If you have app state which isn't easily serializeable, then you'd have difficulty providing a good URL structure for people but you'd probably have that issue even if you weren't using react. 1: https://facebook.github.io/react/docs/events.html https://facebook.github.io/react/docs/events.html 2: https://facebook.github.io/react/docs/component-specs.html https://facebook.github.io/react/docs/component-specs.html
fizixer 12y ago
Question from a JS layman: React is great in comparison to what? vanilla JS? Angular/Backbone/Ember? JQuery? any other *.JS? Also is this a good direction for "mobile first" approach? What about platform independence? (iOS/Android/Desktop agnostic, etc, etc). (bootstrap? phonegap?)
- myhf 12y ago
  In comparison to Angular, React is more idiomatic. It is very easy to reason about the scope, lifecycle, and performance of React components if you are familiar with JavaScript as a language. In comparison with Backbone/JQuery, React is more declarative. It encourages the developer to describe the structure of the UI in a given state and let the engine handle the transitions between states. It's possible to use Backbone models and events with React views with very little impedance mismatch. I would like to hear an Ember expert's perspective. React Native has an interesting approach to mobile-first development. The general philosophy is "learn once, write anywhere" instead of "write once, run anywhere". Most apps cannot make the most of their platform while being truly platform-independent, but unifying component lifecycle behavior between platforms could end up being easier on developers than learning the particulars of each platform, while producing a better result than a PhoneGap-style wrapper.
  - go1979 12y ago
    I'm not an expert ... I dabbled a bit in Angular and found it really confusing and hard to debug. React worked mostly as expected. There were some gotchas but I managed to get through them in a few days. I just wish we had a non-proliferation treaty on Flux frameworks.
    - TheAceOfHearts 12y ago
      Flux is an idea, there's multiple implementations because they optimize for different concerns. For example, I like Fluxible because it lets you do server side rendering, and it avoids singletons, so it's exceptionally easy to test. However, if I'm working on an app that doesn't have any public facing components, I'd probably consider a different implementation that is less verbose.
unklefolk 12y ago
Honest question here from someone new to React. Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? It feels a bit like old school ASP! I'm not trying to be flippant, I just was always taught about separation and mixing HTML markup with JS logic seems like we are going the other way.
- dagw 12y ago
  'We' never really came to an agreement on that question. Some people always thought it was a pretty good idea to keep things that belong together close together and some people didn't. The separation people have been dominant for a couple of years, but a bunch of people didn't really like that approach and are now taking a new stab at finding a new solution the problem. It's just two different schools of thought and really comes down to personal preference. Fashion ebbs and flows and what was old is new, and what was new is old.
- Swizec 12y ago
  As someone a bit less new to React. This is leaps and bounds better than the Angular approach. My favourite part is passing functions and complex objects as element properties. Very useful.
- skrebbel 12y ago
  > Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications. While well-designed applications also have commonalities to them (button styles, margins, etc), the various screens and dialogs in an application vary way more in structure than the various pages on a typical informational web site tend to do. It turns out that separating logic and presentation in web applications the way you would on web sites is a very bad match. You simply end up putting logic that is very closely tied together in three different places. E.g. typical jQuery code that falls apart the moment you change either the HTML (turn a div into a span, whatever), or the css class names, or the jquery selector/handler code, all of which is located in different files deep in a different directory hierarchy. For each single widget in your app (button, dropdown, LoginScreen, etc), it's much better to put all that code together. And that's what React lets you do. (note that this means that you really do want to tie your styles closely to your react components too - either inside the JS or with e.g. one .sass file for each React component)
loceng 12y ago
What are your thoughts on, and how do you let your clients know (since you're a web agency?), that using anything built by Facebook comes with a huge business risk? With the included PATENTS file, if Facebook decides a patent they filed is something you violate then they will sue you or ask for a royalty. If you try to fight it or even suggest it's not valid then your license for React and all other Facebook projects becomes voided. This gives incredible leverage and power to Facebook for anyone developing their core business with anything they've made/open sourced. EDIT: https://github.com/Raynos/mercury https://github.com/Raynos/mercury was suggested as an alternative, I'm not sure how viable it is for different types of projects.
- dada78641 12y ago
  It's undue paranoia. It says essentially the same thing as the Apache 'Grant of Patent License' section. Namely, if you instigate a patent lawsuit, the free patent license offered by Facebook no longer applies. It would be impossible for Facebook or Apache to engage in patent lawsuits if they did not include this termination clause. Besides, Facebook is gonna sue you if you violate their patents, regardless of whether you use React or not. And the termination pertains to the patent license. They can't restrict your access to a BSD licensed software package.
  - deleted 12y ago
    [deleted]
    - matthewmacleod 12y ago
      No, this is not correct. Please stop spreading this misinformation. Your license to use React is not contingent on 'not to sue them' – however, the additional patent grant that they give you is contingent on this. This patent grant is in addition to your license to use the software. If you accuse Facebook of violating one of your patents, then you automatically lose the right to use any of theirs. You do not lose your license to use the software, which is a totally orthogonal issue.
      - 12y ago
bananaoomarang 12y ago
Hey, this is really nice. The sort of quick-reference guide w/ examples I wanted a couple of months ago, nice!
MichaelCrawford 12y ago
Please don't build single page applications. They drive me bananas. Consider how difficult it is to open different sections of your site into separate tabs.
- esro360 12y ago
  Aren't you supposed to use react router and mimic the real site behavior in a single page app ?
- davidy123 12y ago
  As esro360 said, goods router (like react-router) will keep your ability to open site links in different tabs, as well as keeping your location (and history) in sync with different views. Things have evolved since the first SPAs.
davidy123 12y ago
Looks like a nice tutorial, but the very strange use of `code` markup makes it harder to read than it should be.
- mcx 12y ago
  Ah sorry about, I was trying to highlight keywords but I might have been too liberal about it.
Cshelton 12y ago
Hey by the way, the slack channel, Reactiflux, is actually pretty strong, check it out. Many people there are actually using React on large scale apps, myself included, and there is plenty of discussion.
- nileshtrivedi 12y ago
  How do I join? It seems I need to be invited by the team admin.
  - tilt 12y ago
    Request an invite from http://reactiflux.com/ http://reactiflux.com/
    - dinosaurs 12y ago
      Seems like the website is down. Any other way to get invited?
- armandososa 12y ago
  Yeah. That seemed attractive to me because I'm building a medium-sized app pretty much in isolation. But it's invitation only.
andrewrice 12y ago
This is great. Does anyone know of a similar primer for Angular 1.*?
- TheAceOfHearts 12y ago
  One problem is that angular 1.x is considerably more complicated than react. There's John Papa's style guide [0], but IMO it's not great. There's an angular review [1] that I believe hits the nail on the head: "Angular wants you to build your application in a particular way, but it’s not very explicit about it. Call it “passive-aggressive architecture.”" After using angular for over ~2 years, I'm far happier with react (and a flux implementation, if doing something more complicated). You end up with far simpler code and more maintainable code. The fact that the angular team itself is doing a complete rewrite that throws away almost all the fundamentals of angular 1.x shows a clear recognition of the many flaws present in it. [0] https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide [1] http://www.letscodejavascript.com/v3/blog/2015/01/angular_review http://www.letscodejavascript.com/v3/blog/2015/01/angular_re...
  - andrewrice 12y ago
    Thanks for the insight! :) I'm just starting to get my feet wet with JS frameworks so the input is appreciated.
fiatjaf 12y ago
There's a tutorial bubble for these frameworks and languages. Too little to say, too much reexplanation of the basics. You end up reading for days and knowing less than what you would know if you started playing with the tools.
- chippy 12y ago
  I dunno, I prefer going through a basic list / hello world tutorial first, and then experimenting.
rip747 12y ago
it's funny how for years i heard how bad CFML was because of mixing in logic and presentation in custom tags. now for some reason react makes this cool. we've come full circle.
- ExpiredLink 12y ago
  Software is a fashion industry.
  - rip747 12y ago
    So does mean I can start sporting a mullet and bell-bottoms to work to code in VB?
xanderjanz 12y ago
lol everytime something about React or Flux gets posted on HN, we get this massive comment thread debating how X React feature isn't best practices (Inline styles, full-app re-render, singleton dispatcher or whatever). Get over it nerds. React is very well thought out, and Just Works™. Your me-too diatribe about how being different is bad doesn't help anything but feed these endless debates. Build apps or die. If you prefer building lousy implicit Rails apps, go wild.

352 points by tilt 12y ago

mcx 12y ago

Author here, the primer is still in the draft phase but feel free to share your feedback / make pull requests!

krat0sprakhar 12y ago
Thanks for the guide. Looks awesome! I've recently started working on a SPA in React and was desperately googling around information. Glad to see it in one document. BTW - I can see that the section on Flux and Alt is still left to be written. Any idea when you'll have the drafts for those sections ready? Lastly, it would be nice if you could contrast Alt with Reflux and give us your recommendations on what to work with. Thanks a lot, again!
- mcx 12y ago
  At the rate I am going, I am hoping by next week. But, the author of Alt has already written an amazing getting started guide: http://goatslacker.github.io/alt/guide/ http://goatslacker.github.io/alt/guide/ - check it out! As for a contrast between Alt/Reflux, I am hoping others using different Flux libraries will contribute and share their views, I will also link to some comparisons others have already done, such as: http://pixelhunter.me/post/110248593059/flux-solutions-compared-by-example http://pixelhunter.me/post/110248593059/flux-solutions-compa.... But if I have time to, I'll give it a try!
otar 12y ago
Thank you! This guide is very well-structured and easy to read.
deleted 12y ago
[deleted]
ClayM 12y ago
How hard would it be to adapt this to non SPA?
- mcx 12y ago
  It's not really that SPA specific, if you want to just use React for the View, then Part 1 and Part 4 (to be written) is probably all you need to get started. Collectively, all the parts of the primer, together should give you the tools you need if you want to build a SPA.
fudgy73 12y ago
Great guide. Thanks a bunch. Glad you're feeling better! :-)
chippy 12y ago
Completely new to React, your introduction was spot on. Many thanks.

pixelHD 12y ago

I've been looking for such a guide for react! thanks!

phelmig 12y ago

I have been toying with reactjs a few weeks ago and this would have helped a lot to get going. Great guide!

JDDunn9 12y ago

Can you build an SPA using just React? At the very least it seems like you'll need a URL router, and something like underscore.js to fill in the gaps.

krat0sprakhar 12y ago
Correct! The author has sections outlined for React-router / Flux[0] which, I believe, will be used to detail out the other parts of the app. [0] - https://github.com/mikechau/react-primer-draft#react-router https://github.com/mikechau/react-primer-draft#react-router
mbrock 12y ago
The "URL router" in my current project begins with "onhashchange = function () {" and is essentially a five line conditional. It might grow to ten lines. All it does is set the root props based on query parameters. Not rocket science. I'm using Fetch.js and a Promise polyfill in order to do AJAX stuff (the native XHR API is a bit tedious). But basically the answer is: yes, you can! You can even write an SPA using nothing but the regular W3C APIs! React just makes it very easy to keep the DOM in sync with your application state.
- krat0sprakhar 12y ago
  I, for one, would love to know more about how this is done. Is your code open-sourced by any chance? Thanks!
masklinn 12y ago
> Can you build an SPA using just React? Sure. You may not want to depending how big and complex the application is, but it's definitely possible. A router and an immutable collections library (immutablejs or mori for instance) are very convenient additions, but by no means necessary. Hell you don't need a precompilation phase either by skipping JSX (and unsupported ES6 constructs).
pachydermic 12y ago
I had to write my own router, but the event system [1] allows you to catch left-clicks or touch events and let you decide how to handle them and the lifecycle functions [2] allow you to update history/URL params to reflect the state of your app. If you have app state which isn't easily serializeable, then you'd have difficulty providing a good URL structure for people but you'd probably have that issue even if you weren't using react. 1: https://facebook.github.io/react/docs/events.html https://facebook.github.io/react/docs/events.html 2: https://facebook.github.io/react/docs/component-specs.html https://facebook.github.io/react/docs/component-specs.html

fizixer 12y ago

Question from a JS layman: React is great in comparison to what? vanilla JS? Angular/Backbone/Ember? JQuery? any other *.JS? Also is this a good direction for "mobile first" approach? What about platform independence? (iOS/Android/Desktop agnostic, etc, etc). (bootstrap? phonegap?)

myhf 12y ago
In comparison to Angular, React is more idiomatic. It is very easy to reason about the scope, lifecycle, and performance of React components if you are familiar with JavaScript as a language. In comparison with Backbone/JQuery, React is more declarative. It encourages the developer to describe the structure of the UI in a given state and let the engine handle the transitions between states. It's possible to use Backbone models and events with React views with very little impedance mismatch. I would like to hear an Ember expert's perspective. React Native has an interesting approach to mobile-first development. The general philosophy is "learn once, write anywhere" instead of "write once, run anywhere". Most apps cannot make the most of their platform while being truly platform-independent, but unifying component lifecycle behavior between platforms could end up being easier on developers than learning the particulars of each platform, while producing a better result than a PhoneGap-style wrapper.
- go1979 12y ago
  I'm not an expert ... I dabbled a bit in Angular and found it really confusing and hard to debug. React worked mostly as expected. There were some gotchas but I managed to get through them in a few days. I just wish we had a non-proliferation treaty on Flux frameworks.
  - TheAceOfHearts 12y ago
    Flux is an idea, there's multiple implementations because they optimize for different concerns. For example, I like Fluxible because it lets you do server side rendering, and it avoids singletons, so it's exceptionally easy to test. However, if I'm working on an app that doesn't have any public facing components, I'd probably consider a different implementation that is less verbose.

unklefolk 12y ago

Honest question here from someone new to React. Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? It feels a bit like old school ASP! I'm not trying to be flippant, I just was always taught about separation and mixing HTML markup with JS logic seems like we are going the other way.

dagw 12y ago
'We' never really came to an agreement on that question. Some people always thought it was a pretty good idea to keep things that belong together close together and some people didn't. The separation people have been dominant for a couple of years, but a bunch of people didn't really like that approach and are now taking a new stab at finding a new solution the problem. It's just two different schools of thought and really comes down to personal preference. Fashion ebbs and flows and what was old is new, and what was new is old.
Swizec 12y ago
As someone a bit less new to React. This is leaps and bounds better than the Angular approach. My favourite part is passing functions and complex objects as element properties. Very useful.
skrebbel 12y ago
> Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications. While well-designed applications also have commonalities to them (button styles, margins, etc), the various screens and dialogs in an application vary way more in structure than the various pages on a typical informational web site tend to do. It turns out that separating logic and presentation in web applications the way you would on web sites is a very bad match. You simply end up putting logic that is very closely tied together in three different places. E.g. typical jQuery code that falls apart the moment you change either the HTML (turn a div into a span, whatever), or the css class names, or the jquery selector/handler code, all of which is located in different files deep in a different directory hierarchy. For each single widget in your app (button, dropdown, LoginScreen, etc), it's much better to put all that code together. And that's what React lets you do. (note that this means that you really do want to tie your styles closely to your react components too - either inside the JS or with e.g. one .sass file for each React component)

loceng 12y ago

What are your thoughts on, and how do you let your clients know (since you're a web agency?), that using anything built by Facebook comes with a huge business risk? With the included PATENTS file, if Facebook decides a patent they filed is something you violate then they will sue you or ask for a royalty. If you try to fight it or even suggest it's not valid then your license for React and all other Facebook projects becomes voided. This gives incredible leverage and power to Facebook for anyone developing their core business with anything they've made/open sourced. EDIT: https://github.com/Raynos/mercury https://github.com/Raynos/mercury was suggested as an alternative, I'm not sure how viable it is for different types of projects.

dada78641 12y ago
It's undue paranoia. It says essentially the same thing as the Apache 'Grant of Patent License' section. Namely, if you instigate a patent lawsuit, the free patent license offered by Facebook no longer applies. It would be impossible for Facebook or Apache to engage in patent lawsuits if they did not include this termination clause. Besides, Facebook is gonna sue you if you violate their patents, regardless of whether you use React or not. And the termination pertains to the patent license. They can't restrict your access to a BSD licensed software package.
- deleted 12y ago
  [deleted]
  - matthewmacleod 12y ago
    No, this is not correct. Please stop spreading this misinformation. Your license to use React is not contingent on 'not to sue them' – however, the additional patent grant that they give you is contingent on this. This patent grant is in addition to your license to use the software. If you accuse Facebook of violating one of your patents, then you automatically lose the right to use any of theirs. You do not lose your license to use the software, which is a totally orthogonal issue.
    - 12y ago

bananaoomarang 12y ago

Hey, this is really nice. The sort of quick-reference guide w/ examples I wanted a couple of months ago, nice!

MichaelCrawford 12y ago

Please don't build single page applications. They drive me bananas. Consider how difficult it is to open different sections of your site into separate tabs.

esro360 12y ago
Aren't you supposed to use react router and mimic the real site behavior in a single page app ?
davidy123 12y ago
As esro360 said, goods router (like react-router) will keep your ability to open site links in different tabs, as well as keeping your location (and history) in sync with different views. Things have evolved since the first SPAs.

davidy123 12y ago

Looks like a nice tutorial, but the very strange use of `code` markup makes it harder to read than it should be.

mcx 12y ago
Ah sorry about, I was trying to highlight keywords but I might have been too liberal about it.

Cshelton 12y ago

Hey by the way, the slack channel, Reactiflux, is actually pretty strong, check it out. Many people there are actually using React on large scale apps, myself included, and there is plenty of discussion.

nileshtrivedi 12y ago
How do I join? It seems I need to be invited by the team admin.
- tilt 12y ago
  Request an invite from http://reactiflux.com/ http://reactiflux.com/
  - dinosaurs 12y ago
    Seems like the website is down. Any other way to get invited?
armandososa 12y ago
Yeah. That seemed attractive to me because I'm building a medium-sized app pretty much in isolation. But it's invitation only.

andrewrice 12y ago

This is great. Does anyone know of a similar primer for Angular 1.*?

TheAceOfHearts 12y ago
One problem is that angular 1.x is considerably more complicated than react. There's John Papa's style guide [0], but IMO it's not great. There's an angular review [1] that I believe hits the nail on the head: "Angular wants you to build your application in a particular way, but it’s not very explicit about it. Call it “passive-aggressive architecture.”" After using angular for over ~2 years, I'm far happier with react (and a flux implementation, if doing something more complicated). You end up with far simpler code and more maintainable code. The fact that the angular team itself is doing a complete rewrite that throws away almost all the fundamentals of angular 1.x shows a clear recognition of the many flaws present in it. [0] https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide [1] http://www.letscodejavascript.com/v3/blog/2015/01/angular_review http://www.letscodejavascript.com/v3/blog/2015/01/angular_re...
- andrewrice 12y ago
  Thanks for the insight! :) I'm just starting to get my feet wet with JS frameworks so the input is appreciated.

fiatjaf 12y ago

There's a tutorial bubble for these frameworks and languages. Too little to say, too much reexplanation of the basics. You end up reading for days and knowing less than what you would know if you started playing with the tools.

chippy 12y ago
I dunno, I prefer going through a basic list / hello world tutorial first, and then experimenting.

rip747 12y ago

it's funny how for years i heard how bad CFML was because of mixing in logic and presentation in custom tags. now for some reason react makes this cool. we've come full circle.

ExpiredLink 12y ago
Software is a fashion industry.
- rip747 12y ago
  So does mean I can start sporting a mullet and bell-bottoms to work to code in VB?

xanderjanz 12y ago

lol everytime something about React or Flux gets posted on HN, we get this massive comment thread debating how X React feature isn't best practices (Inline styles, full-app re-render, singleton dispatcher or whatever). Get over it nerds. React is very well thought out, and Just Works™. Your me-too diatribe about how being different is bad doesn't help anything but feed these endless debates. Build apps or die. If you prefer building lousy implicit Rails apps, go wild.