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

A Primer for Building Single Page Applications with React

github.com

Post reply on HN
Print view View original

61–70 of 145 posts

Re: A Primer for Building Single Page Applications with React

#61

Post by pachydermic »

JDDunn9 wrote: post #5

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.

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

2: https://facebook.github.io/react/docs/component-specs.html

Re: A Primer for Building Single Page Applications with React

#62

Post by mcx »

ClayM wrote: post #58
mcx wrote: post #2

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

How hard would it be to adapt this to non SPA?

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.

Re: A Primer for Building Single Page Applications with React

#63

Post by BinaryIdiot »

skrebbel wrote: post #17
unklefolk wrote: post #12

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.

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

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

As a web developer for the past 10 years I can't disagree with this more. It wasn't the easiest thing to accomplish maybe 5 years ago but it was always doable and now with web components it's incredibly easy.

React is cool but I wouldn't call separating logic and presentation bad. I would call that a best practice.

Re: A Primer for Building Single Page Applications with React

#64

Post by armandososa »

Cshelton wrote: post #32

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.

Yeah. That seemed attractive to me because I'm building a medium-sized app pretty much in isolation. But it's invitation only.

Re: A Primer for Building Single Page Applications with React

#65

Post by TheAceOfHearts »

go1979 wrote: post #48
myhf wrote: post #31

Earlier quoted context omitted.

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

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.

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.

Re: A Primer for Building Single Page Applications with React

#66

Post by rpedela »

timepiece wrote: post #52
skrebbel wrote: post #37

Earlier quoted context omitted.

> Is a highly dynamic site really a "get out of jail free card" for best practices? No, of course not. React proposes to replace one "best practice" by a different one. In React, the best practice is to divide your application up in a deep hierarchy of components, each of which adds one single little layer of abstraction over the other. Then, put all the logic and presentation that's relevant for that little piece of…

it's difficult for the programmer of a parent component to influence the behavior of the child component You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly. Yeah sometimes undesired consequences occur on elements but it's easy to…

> You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly.

This presentation explains what problems React inline CSS solves. https://speakerdeck.com/vjeux/react-css-in-js

EDIT: I gave wrong presentation link initially.

Re: A Primer for Building Single Page Applications with React

#67

Post by timepiece »

rpedela wrote: post #66
timepiece wrote: post #52

Earlier quoted context omitted.

it's difficult for the programmer of a parent component to influence the behavior of the child component You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly. Yeah sometimes undesired consequences occur on elements but it's easy to…

> You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly. This presentation explains what problems React inline CSS solves. https://speakerdeck.com/vjeux/react-css-in-js EDIT: I gave wrong presentation link initially.

This presentation explains what problems React inline CSS solves

Could you please summarize in a few sentences what are these probs this approach deem to solve?

Because I have seen demos and talks from React people and I was appalled at their neglect of best practices and bending the rules just to push their product and technologies on the community

Re: A Primer for Building Single Page Applications with React

#69

Post by rudasn »

unklefolk wrote: post #12

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.

Keep in mind that the notion of separation of concerns (markup, style, behaviour) mostly refers to the end result, the rendered page. Performance is a good reason for doing this.

In other words, use css classes to style similarly looking elements instead of defining the styles inline (style attribute). Or use event delegation instead of adding a bunch of onClick attributes on your elements.

When talking about developer productivity (ie. maintenance, new feature development) what's more important than separation of technologies is separation of concerns at the "component" level.

Component in this context can be simply defined as a single file that contains all the logic required to render and manipulate a single DOM element throughout its lifecycle.

What React does (as is Angular to a lesser extend) is allow you to mix markup and behaviour while developing but keep those things separate when generating the end result.

Re: A Primer for Building Single Page Applications with React

#70

Post by timepiece »

kyllo wrote: post #47
unklefolk wrote: post #12

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.

Just because your HTML, JS and CSS are in different files doesn't change the fact that they are tightly coupled. React dispenses with this superficial separation and groups presentation, behavior and styling of the same UI element together. I've found it much easier to reason about.

But if these individual components share any code between them, you'd still have to write the same lines over and over again for each component.

So, how do you reason about that?

Post reply on HN