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

Don't React

staltz.com

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Don't React

#121

Post by balls187 »

nogridbag wrote: post #116

I've used Flux now on a few toy microprojects and I found that while Flux's unidirectional data flow is initially appealing (and I naturally tend to write unidirectional code for very complex UIs in past apps),it makes the simple cases much more tedious and error prone. For example, given the simplest case of a Flux store handling events from a single ajax call, I find I have to write code like this: onLoad() { this.…

> I still have tons more boilerplate than a traditional MVC app which for the simple UIs makes the code more difficult to reason about.

I think this is just the relative immaturity of the ReactJS/Flux stack, and having to do this boilerplate is just part of the cost of being bleeding edge (much like struggling with understanding Transclusion/Directives/et-al when Angular was first released with crappy documentation).

Re: Don't React

#123

Post by balls187 »

dwg wrote: post #107
balls187 wrote: post #102

Earlier quoted context omitted.

As is covered ad naseum else where, ReactJS is just a way to do Views. What did you use to manage state, data flow, communication to servers, etc?

Used refluxjs for data flow. Inside the stores, superagent is used for request handling. React-router was used for routing.

Once I finally grok'd the implementations of Flux, I found the it to be a decent layer ontop of ReactJS.

Of the implementations of Flux, Reflux is pretty good, with less hassle of a centralized dispatcher, and extra boilerplate.

What I don't get is that the `trigger` is essentially a store created action, which goes against the unidirectional data flow model.

Re: Don't React

#124

Post by woah »

balls187 wrote: post #117
woah wrote: post #105

Earlier quoted context omitted.

You can actually do a lot of that stuff with JavaScript, it turns out.

So you end up with an unmaintainable pile of javascript? Or are advocating reinventing the wheel and writing a bunch of boiler plate javascript to marshal data, update state, etc? ---- One major reason to use a JS framework is to enforce good design and coding practices to allow for more maintainable code. You can certainly implement these patterns yourself in Javascript, but you are reinventing the wheel, which is a…

React abstracts away the stuff that usually makes JS complicated, like DOM manipulation, or dealing with observables. What you're left with is view components that you can just stick a regular JSON tree into. For instance, updating state is something that you don't really need to do in React. Just update your JSON tree, and your interface will match. And JS is really good at monkeying around with JSON.

There is some stuff like routers etc. that you might not want to write yourself. Luckily there is a universe of components you can choose from, instead of one that some guy at google thought was good.

Re: Don't React

#125

Post by dwg »

balls187 wrote: post #123
dwg wrote: post #107

Earlier quoted context omitted.

Used refluxjs for data flow. Inside the stores, superagent is used for request handling. React-router was used for routing.

Once I finally grok'd the implementations of Flux, I found the it to be a decent layer ontop of ReactJS. Of the implementations of Flux, Reflux is pretty good, with less hassle of a centralized dispatcher, and extra boilerplate. What I don't get is that the `trigger` is essentially a store created action, which goes against the unidirectional data flow model.

I definitely found Reflux to be more understandable and easier to put into practice than Flux in general. They trade-off some purity and flexibility for simplicity.

That said the stores and trigger method are definitely one of the rougher areas in the app. Thinking back, the stores were probably the largest source of bugs, but they also contain more logic so it's reasonable to assume they would have higher bug density.

Reflux was a great stepping stone, but this is the area I would most like to refactor and/or spend more time on in future projects. Fortunately there's a lot of interesting work going on in this area right now.

Re: Don't React

#126

Post by danabramov »

EugeneOZ wrote: post #115
staltz wrote: post #86

Presentation author here. I didn't publish this to HN myself, it was just discovered by someone among my repos. Some important things I want to make clear: 1. React is revolutionary. I really like the core idea inside it, which is basically just this https://joshaber.github.io/2015/01/30/why-react-native-matte... 2. Apart from the core ideas, the surfacing API has its problems: synchronous render (a problem for serve…

Well, not sure about first point. We already have FlightJS ( https://flightjs.github.io/ ) couple of years, which is event-driven also (even templates looks similar to React UI).

Flight is not like React at all. I see DOM manipulation all over the place in Flight examples.

Re: Don't React

#127

Post by jlongster »

staltz wrote: post #86

Presentation author here. I didn't publish this to HN myself, it was just discovered by someone among my repos. Some important things I want to make clear: 1. React is revolutionary. I really like the core idea inside it, which is basically just this https://joshaber.github.io/2015/01/30/why-react-native-matte... 2. Apart from the core ideas, the surfacing API has its problems: synchronous render (a problem for serve…

I feel bad for my comment now. I got lured in the typical HN response. Sorry! I hate just seeing slides from a presentation.

Re: Don't React

#128

Post by mjackson »

staltz wrote: post #86

Presentation author here. I didn't publish this to HN myself, it was just discovered by someone among my repos. Some important things I want to make clear: 1. React is revolutionary. I really like the core idea inside it, which is basically just this https://joshaber.github.io/2015/01/30/why-react-native-matte... 2. Apart from the core ideas, the surfacing API has its problems: synchronous render (a problem for serve…

Co-author of ReactRouter here.

With regards to #2, I used to think that a fully sync render function was a limitation of React, but have come to appreciate the fact that React tries to restrict its concerns to a very small, but significant piece. We've been working on solving the async data fetching use case in the router over the past few months, working with the Relay team as well, and we're starting to converge on some ideas and patterns that we think will help. But it's my personal opinion that sync render isn't a problem.

Re: Don't React

#129

Post by EugeneOZ »

danabramov wrote: post #126
EugeneOZ wrote: post #115

Earlier quoted context omitted.

Well, not sure about first point. We already have FlightJS ( https://flightjs.github.io/ ) couple of years, which is event-driven also (even templates looks similar to React UI).

Flight is not like React at all. I see DOM manipulation all over the place in Flight examples.

Maybe that's the reason why it didn't take off the ground :) But their main idea is event-driven design, so I still think it's common idea for React and for Flight.

Re: Don't React

#130

Post by imron »

untog wrote: post #52
bratsche wrote: post #50

Earlier quoted context omitted.

They did put it on the web.

Yes, and for all we know there is a page linking to it that says "Here's a link to my reveal.js presentation, just use the arrows to navigate"

Even if I had seen a message beforehand telling me "just use the arrows to navigate", I still wouldn't have found those arrows. Light gray on light green doesn't exactly stand out.
Post reply on HN