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

71–80 of 92 posts

Re: React JS Best Practices

#71

Post by Numberwang »

simplify wrote: post #48
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. E…

Why isn't the Mithril library more popular?

Re: React JS Best Practices

#72

Post by simplify »

Numberwang wrote: post #71
simplify wrote: post #48

Earlier quoted context omitted.

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. E…

Why isn't the Mithril library more popular?

It's getting more and more popular every day! It just doesn't have a billion dollar company's marketing budget to promote itself :)

Re: React JS Best Practices

#73

Post by platz »

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.

I really really hope the JavaScript redefinition of this word dies out. Please just make a new word instead of butchering a perfectly well-defined one.

Re: React JS Best Practices

#74

Post by girvo »

platz wrote: post #73
mushishi wrote: post #49

Earlier quoted context omitted.

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

I really really hope the JavaScript redefinition of this word dies out. Please just make a new word instead of butchering a perfectly well-defined one.

I don't disagree, I come from a maths background so it's a bit weird too; however, I'm yet to see a decent alternative and it's rather entrenched now. It's not a good descriptor however: using the word with non-tech product owners makes their eyes glaze over, so I'd love something better but am yet to come across it.

Re: React JS Best Practices

#75

Post by abritinthebay »

platz wrote: post #73
mushishi wrote: post #49

Earlier quoted context omitted.

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

I really really hope the JavaScript redefinition of this word dies out. Please just make a new word instead of butchering a perfectly well-defined one.

It's using the completely correct biology usage: "a similarity of form or structure between organisms"

Thinking it only refers to one field and is wrong - when the usage is totally correct (and very applicable) just makes you sound snobbish... and foolish.

Re: React JS Best Practices

#76

Post by pbowyer »

straws wrote: post #60
yblu wrote: post #57

Earlier quoted context omitted.

I wonder how everyone takes care of error handling in Flummox (or Flux in general)? Would you also trigger an action, then wait for the store to set some sort of error state? Basically, how would you migrate the following code to Flux: click() { doAction().catch(err => showModal(err)) }

Great question! Actions should be thought of as a mapping between some mechanical UI event (typing in a form, clicking on a button) and an event with some meaning in your application ("user typed a hacker news comment", "user submitted a reply to this comment with this text"). Whatever your application data store abstraction is, it should be responsible for taking that meaningful event and figuring out what to do wit…

Thanks for your explanation, that makes sense theoretically but... could you provide a code example for how this breaks out in practice?

Re: React JS Best Practices

#77

Post by pbowyer »

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…

Thanks for your comprehensive answer, I will have a watch, read and think!

[Linking to the other discussion on this post about CSS and vjeux for future reference: https://news.ycombinator.com/item?id=9515662]

Re: React JS Best Practices

#78

Post by iyn »

Geee wrote: post #64
iyn wrote: post #44

Earlier quoted context omitted.

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?

This is the first time I saw Basscss, so take all this with a grain of salt. It seems well written, but I would put it in the same/similar category as for example Bootstrap. Basscss seems to be more modular - you can build your own "version" of Bootstrap - but Basscss gives you npm modules, so you could do something like/equivalent of require(basscss-grid). So, there are some differences that can be interpreted as a advantage of Bootstrap/Basscss, but react tries to solve the bigger problem IMO. Did you see that we're adding more and more "logic" into CSS (like animations calculations, :first, :even etc)? Where is the line? Does CSS is still "only" description of the presentation or something more? To be honest, I don't know where we are now, all those things start to merge/mix. I'd say that we're still on a quest to find the best paradigms for the web. "Regular" HTML, CSS and JS were working fine, but we're moving forward and new problems arise (how to handle different screen sizes, how can 1000 people work on the same code base, ...), so we're trying new solutions (like react and flux).

So, to answer your question: Basscss could help with some of the problems with CSS but I think that react solves problem on a higher level and does it better than any other solution we have now.

Re: React JS Best Practices

#79

Post by efdee »

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"?

On the serverside, your stores should not be singletons (shared between all requests) but in request scope (one per request). Otherwise users will be reading eachother's data.

Re: React JS Best Practices

#80

Post by talldan »

STRML wrote: post #52
dandelany wrote: post #18

Earlier quoted context omitted.

Seems to me you could wrap ad elements in container components that have: shouldComponentUpdate() { return false; } Which would prevent React from re-rendering them after initial mount... any reason why this doesn't work? I do this often when using d3 selections to keep React out of the way and catch incoming props in componentWillReceiveProps instead.

This is the right answer. This will effectively keep React from touching the element ever again after the initial render.

I'm intrigued as to why you think this approach is better than using a key? The 'shouldComponentUpdate' way of doing things means any changes to props or state on the component have to be handled manually, which can introduce a lot of non-trivial and overly complex code.
Post reply on HN