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

Simple React Patterns

lucasmreis.github.io

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Simple React Patterns

#81

Post by LiweiZ »

Cthulhu_ wrote: post #37
blumomo wrote: post #18

The Container/View Pattern in this article, isn't this MVC?

You could argue it's a variation thereof, more like MVVC (Model View ViewController) maybe. In React you only really have the View layer. In this case, there's two views, a 'functional' view (the ViewController) and the 'presentation' view (the View itself). I guess the main difference is that in MVC, the view and controller are two separated entities (side-by-side), while in React it's embedded (Controller wraps aro…

I'm new to React. From what I read, isn't React only the View? I thought its structure was more like pure view layers glued by light logic to form a higher level view. It seems I was wrong now.

Re: Simple React Patterns

#82

Post by amk_ »

barrkel wrote: post #69

Two things I don't like about the approach taken with these specific examples (and they're related): - It's harder to see the structure of a page when the parts are composed functionally instead of structurally (i.e. explicit nesting); but functional composition is required because the next step down from components are DOM elements - This approach makes consistent styling of a large application difficult because it…

CSS-in-JS libs like https://emotion.sh make "micro-componentization" even easier - pretty much every raw DOM element can be replaced by a domain-relevant/ui-relevant component type. Then if you need to add something beyond styles like state or complex render logic, the consumers don't even know about it because the reference is the same.

Re: Simple React Patterns

#84

Post by wuliwong »

MPiccinato wrote: post #78

I am always intrigued when I come across an article like this, after having done 2+ years of React development, and have never seen these patterns (Provider Pattern), nor seen them debated (Render Props). I do pay attention to the community here and there, and constantly poke around open source react libraries. I tend to bring in patterns from iOS development, such as Delegates, especially when using React Native, an…

I just heard about the Provider pattern this week when reading about using react-router and mobx. That being said, it is a solution to a "problem" that I noticed fairly early on in my react usage.

Re: Simple React Patterns

#85

Post by fatso83 »

pcmaffey wrote: post #79
travmatt wrote: post #77

Earlier quoted context omitted.

Set a variable... set a property in the component state? Or set a static variable on the class?

I use a static var on the class. componentDidMount() { if (!this.unmounted) ... } componentWillUnmount() { this.unmounted = true }

That's not a static car on the class. It's on the instance! A static class property would entail something like `Foo.unmounted = true` (a bad idea).

Re: Simple React Patterns

#86

Post by js4all »

Fetching data directly in components is bad advice and leads to a program with cluttered data access becoming more and more unmaintainable as the app grows. You need to encapsulate fetching and storage in redux or a similar state management solution.

Re: Simple React Patterns

#87

Post by tmat »

azangru wrote: post #49
tmat wrote: post #47

Earlier quoted context omitted.

actually once redux is introduced to react it's very very very functional.. so hold the sadness

React is functional even without Redux :-) Look at the Reason team, with their Reason-React implementation. Cheng Lou seems to actively dislike a single store that Redux is, and, if anything, co-locates stores to stateful components.

That sounds more like flux, how do they avoid all the boilerplate that flux was? It was very very painful.
Post reply on HN