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

31–40 of 92 posts

Re: React JS Best Practices

#31

Post by modarts »

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…

Flummox is incredible, and pretty much the first thing I point beginners to after they've learned the basic concepts of flux (I don't even show them Facebook's implementation because it's actually pretty poor and relies heavily on singletons and interacting directly with things that should be implementation details like the dispatcher)

Re: React JS Best Practices

#32

Post by girvo »

modarts wrote: post #31
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…

Flummox is incredible, and pretty much the first thing I point beginners to after they've learned the basic concepts of flux (I don't even show them Facebook's implementation because it's actually pretty poor and relies heavily on singletons and interacting directly with things that should be implementation details like the dispatcher)

Gosh yes, Facebooks implementation doesn't really do the whole idea justice to be honest. Alt and Flummox are much nicer, but I found Flummox far easier to use; one of the few libraries that seems to strike the balance between minimalism and features. I'm definitely impressed, and it was a super easy sell at work to move to a "three tier" architecture, because two of those tiers are the same code base with Flummox and React!

Re: React JS Best Practices

#34

Post by garthk »

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…

We rolled our own Flux library before they published any code, dodging singletons and gaining mock-free testability. I just re-wrote it, but will check Flummox out.

Re: React JS Best Practices

#36

Post by agmcleod »

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…

I had been using reflux when trying out react native. This actually looks nicer than reflux, i think i'll check it out :)

Re: React JS Best Practices

#37

Post by talldan »

lobster_johnson wrote: post #17
lopatin wrote: post #15

Earlier quoted context omitted.

Nice, we're actually posting a tutorial in a week or two about how we use d3 + react. I'll try to summarize though. In the case that a library modifies the DOM, we try to keep React out of it's way. React works best when it has full control of the DOM. In these cases, React components are more of "wrappers" for the 3rd party libraries. Mostly by using the componentDidMount/componentWillUnmount to initialize/destroy t…

We use Google ads in our React apps, and it turns out to be a problem. I wonder if anyone has solved it in a satisfactory way. Basically, with GPT you have named slots identified by their DOM element IDs. You can "refresh" a slot any time, which will populate the element if it's empty, or load a different ad. So we do that when we're mounted. Unfortunately, if the page structure changes, React will re-render the comp…

Do you have the 'key' prop specified on these components? React uses the key to keep track of a particular element. If you specify your own unique key, react will know that the dom representation of a component matches your react instance, and thus not replace the dom element when changes happen in a parent component (apart from if the component or parents are completely unmounted).

Without the implicitly set key, react creates its own index, so if a change happens in the hierarchy above your component, a new key might be given by react, causing the dom element to potentially be replaced when rendering.

Re: React JS Best Practices

#38

Post by pbowyer »

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.

Re: React JS Best Practices

#39

Post by lopatin »

rattray wrote: post #23
lopatin wrote: post #13

Earlier quoted context omitted.

The latter. Most of our components have an associated scss file. I didn't consider those to be global because we namespace all css rules in the style files under a class name of the same name as the component. But that's a great point, it didn't occur to me that that paragraph may have only made sense to people familiar with our conventions.

Interesting. Asking out of curiosity, not skepticism: why not use react styles in js directly, à la vjeux et al? Reasons I'd guess: not being able to use pseudo-selectors and things like :hover; familiarity for designers; easier use of legacy code; benefits of SCSS that would take work to re-implement in js. But I'm curious what your real reasons were!

That's pretty much it! Although the ideas presented here do make sense (https://speakerdeck.com/vjeux/react-css-in-js) we haven't gotten there yet. Our css namespacing scheme solves the "global namespace" issue, which was the biggest issue that stood out for us.

Re: React JS Best Practices

#40

Post by cnp »

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
Post reply on HN