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

React Tips and Best Practices

aeflash.com

Post reply on HN
Print view View original

1–10 of 42 posts

Re: React Tips and Best Practices

#3

Post by amelius »

Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?

Re: React Tips and Best Practices

#4

Post by lukev »

amelius wrote: post #3

Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?

It's easy to speculate that better solutions are possible, but noone has ever actually done it. React (used from a more functional language, like ClojureScript) is the closest system to the world you describe which actually exists.

And no, papers and toy proof-of-concepts don't count. They are extremely interesting, and a necessary first step, but someone needs to build something large and demonstrate effectiveness in the real world before you can make an honest bid for large-scale adoption. As far as I know, no other FRP or functional UI system has done any better than React on that front, yet.

Re: React Tips and Best Practices

#5

Post by lopatin »

Great article. One thing I would like to mention is that using component state (this.setState) is okay! Central stores, and the flux architecture, are very helpful but if your state shouldn't persist after an unmount, there's no point in extracting to a central store and passing it through your entire app as props. (i.e. Whether or not a certain dropdown is expanded). Just keep that state local.

Re: React Tips and Best Practices

#9

Post by themgt »

One of the things I didn't realize at first was the degree to which Relay/GraphQL appear to effectively replace a lot of Flux: http://facebook.github.io/react/blog/2015/02/20/introducing-...

Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will look like though.

Re: React Tips and Best Practices

#10

Post by amelius »

lukev wrote: post #4
amelius wrote: post #3

Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?

It's easy to speculate that better solutions are possible, but noone has ever actually done it . React (used from a more functional language, like ClojureScript) is the closest system to the world you describe which actually exists. And no, papers and toy proof-of-concepts don't count. They are extremely interesting, and a necessary first step, but someone needs to build something large and demonstrate effectiveness…

True. But consider this: if we had a functional-style language that did not do any incremental computation, only the minimal React-style of re-rendering, that would already be infinitely better. Because it would mean we wouldn't have to totally rewrite our code whenever incremental computation became a reality.

In other words, we can do it in steps.

Post reply on HN