Live data from Hacker News

React Tips and Best Practices

aeflash.com

31–40 of 42 posts

Re: React Tips and Best Practices

#31
post #3

Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?

Can you (or someone else) explain the need for the language to be functional?

Re: React Tips and Best Practices

#32
post #26
post #9

One of the things I didn't realize at first was the degree to which Relay/GraphQL appear to effectively replace a lot of Flux: http://facebook.github.io/react/blog/2015/02/20/introducing-... Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will…

Don't forget that Relay means replacing your RESTful routes. If you still want to work with RESTful endpoints, you are going to work with Flux.

Exactly -- nobody (yet) has written any kind of general purpose mapping from rest concepts to relay endpoints. Relay appears to leverage graph db functionality/semantics pretty heavily.

Re: React Tips and Best Practices

#33
post #3

Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?

Can you (or someone else) explain the need for the language to be functional?

I don't think there's a strict need, but functional languages tend to bring the desired traits: immutable data structures, referential transparency, isolating side effects and state mutation as much as possible, etc.

It seems like the more one uses React, the more they crave the above, so it makes sense to use an environment where all of the above is natural.

Re: React Tips and Best Practices

#34
post #7
post #2

What are the best resources for someone looking to learn react and jsx?

Quite seriously: http://facebook.github.io/react/docs/getting-started.html

Wow, really? As much as I have enjoyed playing with React, the docs seem very, very sparse to me. I wish I had a better suggestion, but for me it was a lot of trying things in code and googling Stack Overflow answers -- you know, the usual. (And this was, like, a week ago, not 6 months ago or whatever.)

Re: React Tips and Best Practices

#35
post #26

Earlier quoted context omitted.

Don't forget that Relay means replacing your RESTful routes. If you still want to work with RESTful endpoints, you are going to work with Flux.

Exactly -- nobody (yet) has written any kind of general purpose mapping from rest concepts to relay endpoints. Relay appears to leverage graph db functionality/semantics pretty heavily.

Pete hunt said it should be relatively easy to wire up a RESTful api to flux relay. And since mapping data to complex front ends is hard, but defining restful endpoints is easy, I'd rather design my database to be optimized for the complex front end scenarios. I imagine that you would be able to make a standard REST api from graphql.

Re: React Tips and Best Practices

#36
With PureRenderMixin, doesn't that also prevent child components from updating in response to state changes? For example if a child component must update due to some event, but none of its parents care about that event, doesn't that cause the child not to update?

Edit: Turns out my render methods aren't pure. I query stores right render, which causes problems when using this mixin.

Re: React Tips and Best Practices

#37

With PureRenderMixin, doesn't that also prevent child components from updating in response to state changes? For example if a child component must update due to some event, but none of its parents care about that event, doesn't that cause the child not to update? Edit: Turns out my render methods aren't pure. I query stores right render, which causes problems when using this mixin.

That's kind of the point, at least as I understand it. You want to minimize the number virtual nodes that need to be reconciled to actual DOM nodes. If nothing about a parent's props or state has changed, then ideally nothing should have to change about any of its children.

http://facebook.github.io/react/docs/advanced-performance.ht... has the best description of this process I've found so far.

Re: React Tips and Best Practices

#38

With PureRenderMixin, doesn't that also prevent child components from updating in response to state changes? For example if a child component must update due to some event, but none of its parents care about that event, doesn't that cause the child not to update? Edit: Turns out my render methods aren't pure. I query stores right render, which causes problems when using this mixin.

If you use PureRenderMixin, all child components must also be pure. If a pure component wants to change what it renders because of an event, it must change its state, otherwise it won't be re-rendered.

Re: React Tips and Best Practices

#39

With PureRenderMixin, doesn't that also prevent child components from updating in response to state changes? For example if a child component must update due to some event, but none of its parents care about that event, doesn't that cause the child not to update? Edit: Turns out my render methods aren't pure. I query stores right render, which causes problems when using this mixin.

An often overlooked pattern in React is controller-views. When using Flux (or really, with any external-to-the-component data) you should put this Store logic in the nearest parent to the components who use it. This component is the "controller" which gets the data and passes it as properties to the child components (who pass it as required to their children down the hierarchy).

This keeps your child components pure (fast, renders directly from props, uses PureRenderMixin) and keeps data access centralised to the nearest common controller-view component. It's okay to have a parent component that simply collects data to pass directly into a single child within the render() call — the parent fetches data and sets props, the child re-renders only when the props update, and there's a clear separation of responsibility between the two.

Re: React Tips and Best Practices

#40
post #3

Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?

Seeing "Mixins are awesome" is bringing back so many code smells. : (
Post reply on HN