Simple React Patterns
lucasmreis.github.io
Simple React Patterns
1–10 of 87 posts
Re: Simple React Patterns
#2Part of me is sad that Javascript has now been made OOP, after a majority of efforts pushing the balance towards becoming more and more functional (e.g. PureScript) only a few years ago.
Re: Simple React Patterns
#3Part of me is sad that Javascript has now been made OOP, after a majority of efforts pushing the balance towards becoming more and more functional (e.g. PureScript) only a few years ago.
React explicitly discourages using inheritance with components, instead promoting composing components together like functions. You're also encouraged to keep them stateless if possible, so they create the same output for the same input. I'll need some convincing that functional programming is on its way out in JavaScript.
Re: Simple React Patterns
#4This is an _excellent_ summary of some of the most useful React patterns. I can also recommend "React Patterns" [0] and "React Bits" [1], which show a variety of other useful patterns as well.
Beyond those, my React/Redux links list has sections on "React Component Patterns" [2] and "React Component Composition" [3], with links to many additional articles on these topics.
[1] https://github.com/vasanthk/react-bits
[2] https://github.com/markerikson/react-redux-links/blob/master...
[3] https://github.com/markerikson/react-redux-links/blob/master...
Re: Simple React Patterns
#5Part of me is sad that Javascript has now been made OOP, after a majority of efforts pushing the balance towards becoming more and more functional (e.g. PureScript) only a few years ago.
React explicitly discourages using inheritance with components, instead promoting composing components together like functions. You're also encouraged to keep them stateless if possible, so they create the same output for the same input. I'll need some convincing that functional programming is on its way out in JavaScript.
Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.
Re: Simple React Patterns
#6Earlier quoted context omitted.
React explicitly discourages using inheritance with components, instead promoting composing components together like functions. You're also encouraged to keep them stateless if possible, so they create the same output for the same input. I'll need some convincing that functional programming is on its way out in JavaScript.
Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.
In React v0.13 https://reactjs.org/blog/2015/03/10/react-v0.13.html, they claimed the reason for the switch is because the `class` syntax is for "more flexibility." What can you do with the `class` syntax that you can't do with the functional syntax? Furthermore, you can generate React code much easier with the functional syntax than with the class syntax.
Also, the functional syntax has mixins and other ways to combine objects or share code, I think that would be harder to do with classes, which make them even less flexible.
Re: Simple React Patterns
#7How does the pervasive use of higher-order functions affect debugging?
Take this example:
const withDagobah = ({
LoadingViewComponent,
ErrorViewComponent,
PlanetViewComponent
}) =>
class extends React.Component {
…
};
class Dagobah extends React.Component {
…
}
(I’ll ignore the topic of type erasure.)
Re: Simple React Patterns
#8How does the pervasive use of higher-order functions affect debugging? Take this example: const withDagobah = ({ LoadingViewComponent, ErrorViewComponent, PlanetViewComponent }) => class extends React.Component { … }; In a language with proper generics, you’d write this instead: class Dagobah extends React.Component { … } And then you’d clearly have an object of type Dagobah , easy to inspect and debug. (And Dagobah…
If you inspect the component tree using the React DevTools, you'll be able to see exactly what values each component is passing to its children, and what their internal state is. So, use of HOCs adds an extra level of nesting to the component tree, but it should also be very clear in there what each component is passing down.
Re: Simple React Patterns
#9Earlier quoted context omitted.
React explicitly discourages using inheritance with components, instead promoting composing components together like functions. You're also encouraged to keep them stateless if possible, so they create the same output for the same input. I'll need some convincing that functional programming is on its way out in JavaScript.
Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.
Prior to ES6, there were hundreds of incompatible class-like implementations in the JS ecosystem, and every major library had its own. That included React.
Now that ES6 classes are actually part of the language, there's no reason for the React team to continue maintaining their own class-like implementation. They can defer that to the language itself. This also enables better use of standardizing tooling around the JS language.
Re: Simple React Patterns
#10Earlier quoted context omitted.
Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.
In React v0.13 https://reactjs.org/blog/2015/03/10/react-v0.13.html , they claimed the reason for the switch is because the `class` syntax is for "more flexibility." What can you do with the `class` syntax that you can't do with the functional syntax? Furthermore, you can generate React code much easier with the functional syntax than with the class syntax. Also, the functional syntax has mixins and other ways to com…
At the moment, React does not yet have support for stateful functional components. It's something they've said they would _like_ to research and implement down the road, but right now, component state and lifecycle methods requires class components.