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

React in patterns

github.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: React in patterns

#41

Post by msane »

_greim_ wrote: post #37
msane wrote: post #31

One thing I prefer about Angular is all of these patterns are established and documented by the same people who designed the framework. In React they are distributed among hundreds of blogs and individual github repos, which all debate each other. How long has React been out? Simple patterns such as component communication are debated, and third-party documentation about them is newsworthy?

The patterns handed down by the authors of Angular were one team's idea of how to do things, at a specific moment in time, which subsequently got enshrined and frozen in place for everyone for the next several years. And it works! It's a legitimate way to run a framework. But, in such an environment, there's no marketplace where ideas can compete and evolve. There's a trade-off where you have to do the hard work of n…

...the benefit of React is that you can choose an architecture...

I don't see that as a benefit... you must choose, and hope you chose well, based on poorer information and docs. It's an expense and a risk.

Some are more confident about the cost and risk than others, but less conscious of it I presume.

Re: React in patterns

#42

Post by cnp »

tengbretson wrote: post #33

In the section on higher-order-components: var enhanceComponent = (Component) => class Enhance extends React.Component { render() { return ( ) } }; Shouldn't `{...this.state}` be considered an anti-pattern?

This is just passing state as props

Re: React in patterns

#44

Post by rrecuero »

Fifer82 wrote: post #4

I am struggling a little with Flux, everyone has their own implementation of it. I mean that is grand, but what does it actually mean for me? Contextless. Thanks for sharing :)

For more advanced examples, I recommend checking out these great boilerplates

https://github.com/erikras/react-redux-universal-hot-example Universal Web Rendering. React + Redux + Express + ES6 + Webpack https://github.com/este/este For Web & Mobile (React Native, Redux, ES6...).

Re: React in patterns

#45

Post by acemarke »

liquidise wrote: post #39
tengbretson wrote: post #33

In the section on higher-order-components: var enhanceComponent = (Component) => class Enhance extends React.Component { render() { return ( ) } }; Shouldn't `{...this.state}` be considered an anti-pattern?

This comment is sure to prove controversial among the more rigorous React followers, but i disagree with the anti-pattern claims. Having built a startup on Backbone and React, i find that referencing `this.state` is a fine way to handle data shifts in our views. While i have read the oft-presented reasons for not using `this.state`, the arguments feel more academic to me than being based in practical examples. Your m…

Yep, using something like Redux or MobX absolutely does not mean "no React component state ever". There's definitely use cases for all of the above. Dan Abramov has tried to make that point repeatedly, and I made sure to put that viewpoint into the Redux FAQ ( http://redux.js.org/docs/FAQ.html#organizing-state-only-redu... ).

Re: React in patterns

#46

Post by acemarke »

msane wrote: post #41
_greim_ wrote: post #37

Earlier quoted context omitted.

The patterns handed down by the authors of Angular were one team's idea of how to do things, at a specific moment in time, which subsequently got enshrined and frozen in place for everyone for the next several years. And it works! It's a legitimate way to run a framework. But, in such an environment, there's no marketplace where ideas can compete and evolve. There's a trade-off where you have to do the hard work of n…

...the benefit of React is that you can choose an architecture... I don't see that as a benefit... you must choose, and hope you chose well, based on poorer information and docs. It's an expense and a risk. Some are more confident about the cost and risk than others, but less conscious of it I presume.

The great thing about React is that you get to choose something that works for your team in your situation.

The bad thing about React is that you need to choose something that works for your team in your situation.

Re: React in patterns

#47

Post by msane »

acemarke wrote: post #46
msane wrote: post #41

Earlier quoted context omitted.

...the benefit of React is that you can choose an architecture... I don't see that as a benefit... you must choose, and hope you chose well, based on poorer information and docs. It's an expense and a risk. Some are more confident about the cost and risk than others, but less conscious of it I presume.

The great thing about React is that you get to choose something that works for your team in your situation. The bad thing about React is that you need to choose something that works for your team in your situation.

It takes more time and energy than the team realizes, which would otherwise be spent building the app.

Its the frontend after all... what matters is UI and features. Component communication patterns and all this low level stuff is time lost.

Re: React in patterns

#48

Post by dceddia »

_greim_ wrote: post #27
dceddia wrote: post #17

Earlier quoted context omitted.

Completely agree. I don't see many people in the React community advocating the use of DI though, so that's a plus. The DI in Angular made a little bit of sense because JS modules weren't very widespread back then. But now, with ES6 imports (and/or 'require') there's no need. We have real modules now, and they can be dynamically injected for testing purposes with something like inject-loader[0]. I think Angular and/o…

Makes sense. My frustration in part stems from having worked on an app that used Angular DI and a module loading system (RequireJS) side by side. The conceptual dissonance and fallout between the two systems was an endless source of bickering and confusion for the team. I came to the situation having worked on a CommonJS/Browserify project, and it was like walking into a brick wall.

I worked on a project that had Angular + RequireJS too. I don't think having RequireJS added anything at all. It was just additional overhead - every module we added caused at least 3 files to change. We eventually ripped it out and just dealt with Angular's own module system.

Re: React in patterns

#49

Post by tengbretson »

liquidise wrote: post #39
tengbretson wrote: post #33

In the section on higher-order-components: var enhanceComponent = (Component) => class Enhance extends React.Component { render() { return ( ) } }; Shouldn't `{...this.state}` be considered an anti-pattern?

This comment is sure to prove controversial among the more rigorous React followers, but i disagree with the anti-pattern claims. Having built a startup on Backbone and React, i find that referencing `this.state` is a fine way to handle data shifts in our views. While i have read the oft-presented reasons for not using `this.state`, the arguments feel more academic to me than being based in practical examples. Your m…

To be clear, I wasn't meaning that use of local state was an anti-pattern in itself. I only meant that dumping all of the state of a wrapper component into the child should be avoided. Ideally, the complexity of the data in the props of a component should lessen the closer one gets to a leaf in the view tree.

Re: React in patterns

#50

Post by ower_89 »

kin wrote: post #19
_greim_ wrote: post #8

Ugh, the dependency injection stuff is just Angular all over again. export default wire(Title, ['title'], function resolve(title) { return { title }; }); Now I have to register "title" somewhere. Where is it registered? Did I remember to register it? I no longer know what's going on just by looking at the file in front of me, and my linter is silent. Then I have to annotate the function and declare it in the argument…

Yeah, I'm also not a fan of the DI example. I would rather explicitly pass it down the component tree or use Redux's connect. I believe React's docs advise against using context.

You can use InversifyJS to inject a value into a React component without passing it explicitly through each component and without using the context http://blog.wolksoftware.com/dependency-injection-in-react-p...
Post reply on HN