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

React JS Best Practices

blog.siftscience.com

Post reply on HN
Print view View original

41–50 of 92 posts

Re: React JS Best Practices

#41

Post by cnp »

supercoder wrote: post #6

Having just started using React for a new project, I absolutely love it. This new project uses a Rails backend, with React allowing the web to act the same way as any other client (iOS app, Android app etc), and it's so productive to work in. Pretty much decided I won't be writing a web app any other way for any future work. These best practices look pretty good, though my advice to any beginners would be to not get…

"React can be pretty forgiving in refactoring later on."

>>> So true

Re: React JS Best Practices

#42

Post by mjbellantoni »

girvo wrote: post #24

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…

Has anyone built their app using ES5 and Flummox? The Flummox documentation is sparse to start and is completely devoid of ES5 examples.

Edit: grammar.

Re: React JS Best Practices

#43

Post by weeksie »

cnp wrote: post #40
girvo wrote: post #24

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…

Oh holy shit I just moved my app off of reflux and on to flummox and wow! Much better

What would you say the major differences are with Flummox? It looks pretty straightforward but Reflux seems pretty lightweight as well. Just trying to figure out if it's worthwhile to switch an early stage project over.

Re: React JS Best Practices

#44

Post by iyn »

pbowyer wrote: post #38
iyn wrote: post #30

One of my initial problems with React & CSS was styling :hover etc. For now, Radium [0][1] solves this problem, but IMO as a community we're still trying to figure out all the best practices and patterns, when it comes to building isomorphic webapps (or webapps is general, since React introduces new way of building apps and I'm sure that's just the beginning). [0] http://projects.formidablelabs.com/radium/ [1] https:…

Why did you want to do it this way, rather than using CSS classes and a stylesheet? I've read the Radium intro and I still don't get their use-case. To me it feels like a misunderstanding of CSS, so inlining it in the component makes sense to the programmer.

This is a great question, I used to think exactly the same until I became enlighten ;). Well OK, to be honest I'm still not entirely happy with how things are modularized, but I see advantages. This is a very good presentation which explains key ideas: https://speakerdeck.com/vjeux/react-css-in-js

Understanding the problems mentioned in the slides was literally eye opening. I was already trying to solve the problems with CSS, without fully realizing that I'm solving them. For example, my "solution" to namespaces was creating a naming conventions for all classes/IDs, like ".header-search-box-button" and this approach becomes PITA quickly. Also, after a while I had more and more dead code, which wasn't easy to identify and I couldn't be sure that if I remove some class, I don't have any elements that depend on it. Non-deterministic resolution was also an issue for me - say user was on a page A (therefore had loaded A.css with class .main-button) where particular boxes are blue. If the user goes to page B (we load B.css which also has .main-button) he should have red boxes. But if the user gets back to page A, the boxes that are supposed to be blue are red (browser cached the style and when browser have 2 classes definitions, the one that was loaded the last "wins"). Sure, we could use IDs for everything, bundle all styles into 1 file etc., but bigger sites would have like 5MB CSS file and at the end of the day it's still hard to maintain the codebase.

I'm sure that "normal" way works for regular/medium sites (it worked for a few good years, right?), but I see ton of advantages for using the inline styles in the JS. It's not easy to "convert" to new approach, but I honestly don't look back. As I've said - it's not ideal solution, but a very important step forward.

This is a good 3-part tutorial on react, flux and some other things:

https://www.youtube.com/watch?v=Pd6Ub7Ju2RM

https://www.youtube.com/watch?v=iR22EWW-CVc

https://www.youtube.com/watch?v=6fhTawDEE9k

Re: React JS Best Practices

#45

Post by krat0sprakhar »

cnp wrote: post #40
girvo wrote: post #24

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…

Oh holy shit I just moved my app off of reflux and on to flummox and wow! Much better

For the past one month, I've been working on an app in Reflux. If the benefits are significant, I'd surely look at switching to Flummox. Care to point out how the switch has been useful to you?

Thanks!

Re: React JS Best Practices

#46

Post by sairion »

cnp wrote: post #40
girvo wrote: post #24

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…

Oh holy shit I just moved my app off of reflux and on to flummox and wow! Much better

Well pretty much Flummox is ES6-ified Reflux, no big differences in functionality...

Re: React JS Best Practices

#47

Post by krat0sprakhar »

mjbellantoni wrote: post #42
girvo wrote: post #24

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…

Has anyone built their app using ES5 and Flummox? The Flummox documentation is sparse to start and is completely devoid of ES5 examples. Edit: grammar.

I struggled the same with another ES6-first library. The best way to convert those to ES5 is via copy / pasting the code in https://babeljs.io/repl/. After a while, you'll quickly learn the syntax and the code will come naturally.

Re: React JS Best Practices

#48

Post by simplify »

nulltype wrote: post #3

I've been looking at reactive UI design, and it seems weird to me that React.js has this React.createClass and .setState stuff. It seems like it would be better to let the user manage the state and just re-render whenever the state changes. Am I missing something about how this works that makes those necessary?

You are absolutely correct; this is what Mithril.js does. In Mithril, a component is a plain JavaScript object with only two properties: controller and view. No set / replaceState, no component[Will | Did][Mount | ReceiveProps] – just plain JavaScript data structures.

Because Mithril uses plain JavaScript constructs, you can use standard design patterns and techniques when constructing and managing your components. Everything works beautifully.

Re: React JS Best Practices

#49

Post by mushishi »

girvo wrote: post #24

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…

What does isomorphism mean here? I know what it means in mathematics, but the explanation in flummox site does not compute for me.

Re: React JS Best Practices

#50

Post by xionon »

mushishi wrote: post #49
girvo wrote: post #24

> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…

What does isomorphism mean here? I know what it means in mathematics, but the explanation in flummox site does not compute for me.

In React / Javascript land, isomorphism means, "the same code is used to render on the server and in the browser"
Post reply on HN