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

61–70 of 92 posts

Re: React JS Best Practices

#61

Post by arms »

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

I'm also curious to hear why you like Flummox better than Reflux. I'm using Reflux now, and haven't hit any pain points, which I can't say the same about some of the other Flux implementations.

Re: React JS Best Practices

#62

Post by mbrock »

spicyj wrote: post #56
lobster_johnson wrote: post #17

Earlier quoted context omitted.

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…

Never used Google Ads, but you should be able to do something like var GoogleAd = React.createClass({ getInitialState: function() { return { id: makeUniqueId() }; }, render: function() { // Since this is always the same, React won't try to change the contents return ; }, componentDidMount: function() { googletag.defineSlot('/1234567/sports', [728, 90], this.state.id); }, componentWillUnmount: function() { // Clean up…

It would probably be good to supply a `key` property to the div to ensure that React never tries to reuse it (say, when changing from one GoogleAd to another).

Re: React JS Best Practices

#63

Post by lopatin »

UUMMUU wrote: post #53
lopatin wrote: post #2

Author here, happy to answer any questions or discuss further!

I noticed in your first code example you use a mixture of leading a method with an _ and some without. Ex. navigateToContact vs _hasUnsavedChanges and _saveChanges. I read somewhere that a best practice is to always prefix custom methods with _ to differentiate from React core methods. What're your feelings on that?

Oh this is definitely a personal preference thing, but our convention is this: private instance methods start with an underscore, public instance methods have no underscore. Public ones have no syntactic difference from the core life cycle methods but that's ok to me because they're all easy to remember. Btw we use public instance methods very sparingly, basically as a last resort when all else fails.

Re: React JS Best Practices

#64

Post by Geee »

iyn wrote: post #44
pbowyer wrote: post #38

Earlier quoted context omitted.

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…

What do you think of http://www.basscss.com/ and would this kind of CSS be helpful in the situation you described?

Re: React JS Best Practices

#65

Post by lopatin »

rattray wrote: post #25
lopatin wrote: post #2

Author here, happy to answer any questions or discuss further!

Great article, thanks for sharing! Would have loved a few code samples to go along but your descriptions did an impressive job describing what's going on. One question: what does that "global Backbone cache" look like?

Thanks! Glad to hear it was easy to follow and didn't ramble. Our backbone model cache is a simple module that you request backbone model instances from by a unique key. You also pass initialization options in case it doesn't exist in the cache. The instance will be constructed, saved in the cache, and returned. You can pass a TTL also. It's not great, feels clunky, but it works.

Re: React JS Best Practices

#66

Post by nulltype »

straws wrote: post #59
Swizec wrote: post #4

Earlier quoted context omitted.

By making it explicit and a bit clunky, you discourage users from using state. Without explicit functions to be called, you can't detect state changes and would need polling. This is terrible. At the end of the day, it's a limitation of JavaScript because unlike with Python, for example, you can't have automagic getter/setter functions. They have to be called as functions.

Actually, custom getters and setters exist in ES5: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... AmpersandJS, for example, implements its observable pattern in this way: http://ampersandjs.com/learn/state That said, I don't think the pubsub/rx/observables pattern is the most optimal for UI development, since it still allows for cascading event chains. Modeling all application state as a large data s…

This is exactly where I am hoping reactive ui ends up. If you don't want to do 60 times a second you can render only on certain events like network call or mouseover. If you do the rendering in requestAnimationFrame you can batch things easily.

Re: React JS Best Practices

#67

Post by nulltype »

lopatin wrote: post #39
rattray wrote: post #23

Earlier quoted context omitted.

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.

I like the vjeux thing, I think for dynamic sites if we replace static html and css with javascript the world will be a better place.

Re: React JS Best Practices

#68

Post by billybolero »

tel wrote: post #58
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…

This is probably obvious but why is the existence of singletons what destroys "isomorphism"?

Because that singleton will serve multiple requests on the server, requests from different users. Singletons are more okay on the client because you know you'll only serve one user, so the singleton can make that assumption as well. But that doesn't work on the server, since the singleton is serving more than one user.

You can still use singletons on the server, but you have to pass the current user id to every method/event on that singleton. And that ends up being quite annoying.

Re: React JS Best Practices

#69

Post by tel »

billybolero wrote: post #68
tel wrote: post #58

Earlier quoted context omitted.

This is probably obvious but why is the existence of singletons what destroys "isomorphism"?

Because that singleton will serve multiple requests on the server, requests from different users. Singletons are more okay on the client because you know you'll only serve one user, so the singleton can make that assumption as well. But that doesn't work on the server, since the singleton is serving more than one user. You can still use singletons on the server, but you have to pass the current user id to every metho…

Ah, I see. Thanks.

Re: React JS Best Practices

#70

Post by noahgrant »

vanadium wrote: post #10
lopatin wrote: post #2

Author here, happy to answer any questions or discuss further!

Got a FOUC (especially on the webfonts) the first couple of renders on the page; looks like the overloading of the META tags might be to blame. Otherwise, really good stuff here as someone rapidly picking up on React.

Were you looking at the siftscience.com marketing site or the Sift Science console?
Post reply on HN