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

11–20 of 42 posts

Re: React Tips and Best Practices

#11

Post by city41 »

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?

I recommend checking out ClojureScript. The community is really moving in this direction. I find cljs takes React from good to great (I wrote a simple blog post about that here [0]), and up and coming frameworks like reframe [1] are going to make it even better. reframe and even vanilla Reagent/Om/etc are heading in the direction you desire. ClojureScript still has some warts to iron out, but all in all I feel like it's our current best bet for some truly amazing apps in the browser.

[0] -- http://www.mattgreer.org/articles/reagent-rocks/

[1] -- https://github.com/Day8/re-frame

Re: React Tips and Best Practices

#12

Post by tptacek »

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?

You should write an article or a blog post about that and submit it. I'd upvote it! This thread isn't a good place for your point, which isn't germane to the article.

Re: React Tips and Best Practices

#13

Post by skybrian »

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?

If you're interested in this, perhaps try Elm? I'm not sure about performance, but it does enforce a pure architecture with all state outside the render tree.

Re: React Tips and Best Practices

#16

Post by danabramov »

themgt wrote: post #9

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…

I still think Flux will be handy for holding global UI state. Such as visible notifications, sidebar state, etc.

Re: React Tips and Best Practices

#17

Post by susi22 »

Has anybody in the client side community ever made the connection to rules engines? This flow of logic is awfully close to how a rule engine works. I wonder if people will at some point arrive at it.

There isn't a whole lot of rules engine in JS. Just nools [1] which is huge. I'd love to see a very simple forward chaining rule engine + Immutable + React and see how that would work out.

My guess is that they aren't popular at all because they have the notion of being enterprisey (Drools/Jboss). I'm a big fan of them. They /can/ make life & code very nice and elegant. Maybe somebody writes an JS adapter to clara rules [2].

[1] https://github.com/C2FO/nools

[2] https://github.com/rbrush/clara-rules

Re: React Tips and Best Practices

#18

Post by saosebastiao »

susi22 wrote: post #17

Has anybody in the client side community ever made the connection to rules engines? This flow of logic is awfully close to how a rule engine works. I wonder if people will at some point arrive at it. There isn't a whole lot of rules engine in JS. Just nools [1] which is huge. I'd love to see a very simple forward chaining rule engine + Immutable + React and see how that would work out. My guess is that they aren't po…

I see some similarities with a stateful recursive Rete implementation. I still wouldn't go so far as to say that it is basically a rules engine.

The Rete algorithm (which is the underlying algorithm of most rule engines) trades off memory use for an O(1) execution time (where n==1 and n is the number of rules in the system). You really only gain any benefit once the number of rules grows significantly, and by then memory usage is significant enough that I wouldn't want it running in my browser. If I had a the need for a rule engine in the browser, I would invest most my effort on offloading rule processing to the server instead.

Re: React Tips and Best Practices

#19

Post by ecesena »

netcraft wrote: post #2

What are the best resources for someone looking to learn react and jsx?

Beside the other links, I found a few react libs very useful. react-router [1] and material-ui [2].

The second one also has an example application that is a great boilerplate (if you like material ui and their work). I've been successfully using it in a couple of small apps [3, 4].

[1] https://github.com/rackt/react-router

[2] https://github.com/callemall/material-ui

[3] http://github.com/ecesena/oscars2015

[4] https://github.com/hasgluten/hasgluten

Re: React Tips and Best Practices

#20

Post by feider »

susi22 wrote: post #17

Has anybody in the client side community ever made the connection to rules engines? This flow of logic is awfully close to how a rule engine works. I wonder if people will at some point arrive at it. There isn't a whole lot of rules engine in JS. Just nools [1] which is huge. I'd love to see a very simple forward chaining rule engine + Immutable + React and see how that would work out. My guess is that they aren't po…

I'm not 100% sure what you mean by rule engines.

I tried to use a FSM for a SPA that was developed with Backbone.js. First it was really useful, but it was really shitty to maintain(expanding etc), though that maybe was fault of implementation. Still it is interesting idea, that I might want to try again.

Post reply on HN