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

Best practices for building large React applications

blog.siftscience.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Best practices for building large React applications

#11

Post by findjashua »

I like me some React, but my only gripe w it is the synthetic events, which can result in a single model's state being updated by multiple listeners.

I have replaced synthetic events w event streams, and couldn't be happier w how much cleaner the code has become as a result of replacing setters with stream-combinators.

The architecture roughly follows Elm's Model-View-Update, by splitting each component into view.jsx and update.js.

1. Update contains the eventstreams (replacement for synthetic events), and are transforms them into update-streams.

2. The model combines multiple update streams to return a model-stream.

3. The view combines multiple model streams, and the subscriber at the end does a `setState` to trigger the re-render

Using streams also has the side-benefit of not needing the didUpdate, shouldUpdate etc lifecycle hooks.

Here's a gist w the eventstream code: https://gist.github.com/findjashua/e78063e6591a2c234919

Happy to answer any questions.

Edit: special thx to Andre Staltz for the insightful discussions.

Re: Best practices for building large React applications

#17

Post by WalterSear »

aikah wrote: post #16

never understood why React needed flux on top. Or does that mean React doesn't solve the problem it is supposed to solve on its own ? or flux should have been baked in react? never understand what flux was about anyway.

Flux is a way to organize interactions with data and business logic, so that React only has to worry about the UI. Specifically, it breaks down behaviours into functional streams that don't interrupt each otherr.

Re: Best practices for building large React applications

#18

Post by ville »

jxm262 wrote: post #6
chowes wrote: post #5

Earlier quoted context omitted.

The 'vanilla' implementation of Flux is very verbose, due to its declarative nature The Relay system they're talking about is in reference to http://facebook.github.io/react/blog/2015/02/20/introducing-... , which is how Facebook manages data fetching at the component level.

Oh yeah I get the part about flux being verbose :) Probably should have omitted that part and just asked about what they meant by the Backbone model cache. Thanks for the link! Wasn't even aware of Relay.

Relay technical preview was open sourced today: http://facebook.github.io/react/blog/2015/08/11/relay-techni...

Re: Best practices for building large React applications

#19

Post by aikah »

WalterSear wrote: post #17
aikah wrote: post #16

never understood why React needed flux on top. Or does that mean React doesn't solve the problem it is supposed to solve on its own ? or flux should have been baked in react? never understand what flux was about anyway.

Flux is a way to organize interactions with data and business logic, so that React only has to worry about the UI. Specifically, it breaks down behaviours into functional streams that don't interrupt each otherr.

so what is relay ? is it on top of flux ?

Re: Best practices for building large React applications

#20

Post by ArthurClemens »

hellbanner wrote: post #7

Any examples of good tile-based board games written in React (or other JS frameworks)?

An example is chessground [1], the UI for the lichess [2] chess game, written with Mithril [3].

[1] https://github.com/ornicar/chessground [2] http://lichess.org [3] http://mithril.js.org

Post reply on HN