I was looking at this fiddle for MobX and I've seen these two ways of defining React Components in ES6 other places as well, like Dan Abramov's egghead redux video series.
#observer
class TodoListView extends Component {
render() {
return <div>
<ul>
{this.props.todoList.todos.map(todo =>
<TodoView todo={todo} key={todo.id} />
)}
</ul>
Tasks left: {this.props.todoList.unfinishedTodoCount}
</div>
}
}
const TodoView = observer(({todo}) =>
<li>
<input
type="checkbox"
checked={todo.finished}
onClick={() => todo.finished = !todo.finished}
/>
<input
type="text"
value={todo.title}
onChange={ e => todo.title = e.target.value } />
</li>
);
My question is, when is it appropriate to use each type?
It seems like the simpler components are able to use the simpler syntax, but I'd like a rule or guideline to follow.
Thanks!
The second pattern is called "stateless functional components", and using it is recommended in almost all cases. SFCs (stateless functional components) are pure functions that are only dependent on their props. They are easier to test, decoupled from each other and will have significant performance gains over other patterns in the future. (source from the official react documentation)
They have a few gotchas though, namely:
One cannot attach refs to SFCs. (src, src2)
They cannot have internal state. (src)
They cannot use lifecycle methods. (e.g. componentDidMount, src)
If you need any of these things, first make sure there is no way around using them and only then use either the ES6 class or the React.createClass patterns.
I highly recommend "Should I use React.createClass, ES6 Classes or stateless functional components?" by James K Nelson to understand the tradeoffs and difference between these patterns, and "Presentational and Container Components" by Dan Abramov for an explanation of the most commonly used structure for Redux applications.
React.createClass VS ES2015 classes VS functional stateless components
In React, there are 3 main ways of creating a new component.
The first one to be introduced alongside with React library was React.createClass, which has the following syntax:
var TestComponent = React.createClass({
render: function(){
return <p>{this.props.children}</p>;
}
})
React.render(<TestComponent>This will be a paragraph element!</TestComponent>, document.body);
After that, in React 0.13 release, we could define our components directly as ES2015 classes:
class TestComponent extends React.Component {
render () {
return <p>{this.props.children}</p>;
}
}
React.render(<TestComponent>This will be a paragraph element!</TestComponent>, document.body);
React 0.14 introduces the ability to create those called stateless components, also known as functional or pure components because they are declared as a function that has no state and returns the same markup given the same props:
const TestComponent = (props) => <p>props.children</p>;
ReactDOM.render(<TestComponent>This will be a paragraph element!</TestComponent>,
document.querySelector('#root'));
These stateless components are much more lighter for React to render, and also have the advantage of being React agnostic, meaning that they can be rendered in any other way given the same input and will produce the same output.
So what you should use in your app depends. Each has their pros and cons and should be used under certain conditions. There are times when you can't use stateless components.
Use ES2015 (ES6) classes or React.createClass when your component needs lifecycle methods or you need to access 'this' for anything other than props.
Related
I'm new in TDD for the React. I've decided to use the react-testing-library to start TDD for development. Suppose that, I should check a prop and simple text in component:
import { render, screen } from '#testing-library/react';
import Card from '../Card';
test('render without crash', () => {
render(<Card />);
expect(screen.getByText('Card Component')).toBeInTheDocument();
});
test('title', () => {
render(<Card title="test" />);
expect(screen.getByText('test')).toBeInTheDocument();
});
I used render two times two check different types of rendering for my component. But I was worry about performance... Is it best practice to separately use render in any tests? or I should create something like this common variable:
const Component = render(<Card title={...} prop2={} prop3={} ... />);
then use Component instead using render again?
I don't think this would be a bad practice. I usually use one of these approaches :
render my component once in a beforeEach, and use it in multiple test(), if I always need the same setup for each test (props, contexts, redux store...),
render my component in each test(), so I can adjust props and context and test multiple configurations.
See https://stackoverflow.com/a/61838982/2295549 for a more complete explanation, and some pros/cons.
But using render multiple times is not a bad practice, in fact it is a pattern used in official docs.
I have created two component in my React App one is class component and another one is functional component. But how react can identify when it call the component it's a class component or functional component?
It's a question ask by Interviewer
But how react can identify when it calls the component it's a class component or functional component?
// Who is a class component and who is a functional component?
ReactDOM.render(
<>
<ComponentA />
<ComponentB />
{React.createElement(ComponentA)}
{React.createElement(ComponentB)}
</>,
document.getElementById('root')
);
While JSX represents objects, as stated in docs they are equivalent:
The above two components are equivalent from React’s point of view.
But actually, React checking isReactComponent flag to determinate if it's a class component or function component:
// # ReactComponent.js
ReactComponent.prototype.isReactComponent = {};
// # ReactFiber.js
function shouldConstruct(Component: Function) {
const prototype = Component.prototype;
return !!(prototype && prototype.isReactComponent);
}
For more in-depth explanation check Dan Abramov's blog post.
React check the component for the isReactComponent flag (which is present on React.Component.prototype source) to determine weather it's a class or a function.
You can read about it in detail here: https://overreacted.io/how-does-react-tell-a-class-from-a-function/
I've stumbled upon a question regarding the Styled Component API updates in version 4:
withComponent which was handy to use, is now deprecated
as is the introduced alternative to it
But as far as I understood as is meant to be used on a JSX template level whereas withComponent was used within a styled component declaration.
So what is the suggested workflow in situations like following:
const BaseComponent = styled.div`
color: red;
`;
const HeadingComponent = BaseComponent.withComponent('h4');
assuming that we use <HeadingComponent /> in a lot of different places.
Would it mean that instead of having a second styled component, declare a React component using the <BaseComponent as="h4" /> and instead of reusing the styled component, reuse the React component?
So transfer usage of withComponent into creating a new React component using the base styled component with as attribute?
Thanks in advance,
Andreas
While I personally prefer reusing the React component with the as prop, it could be easier for you to just refactor the usages into BaseComponent.attrs({ as: 'h4' })``.
The documentation around Microsoft's recently released ReactXP doesn't have much information about the RX.Component class at the moment.
Here's an example from the documentation:
class HelloWorld extends RX.Component<void, void> {
render() {
return <RX.Text>Hello World</RX.Text>;
}
}
What are the features offered by RX.Component over React.Component?
How does it influence the life-cycle of the base Component class?
This is an important consideration for me because best practices for React components typically encourage composition over inheritance, except for very basic scenarios like PureComponent. Would the features provided by RX.Component justify the inheritance?
I believe it's the same:
https://github.com/Microsoft/reactxp/blob/master/src/web/ReactXP.ts#L131
Maybe they just want to make everything under the RX namespace so you only need to import RX = require('reactxp');
I am quite new to React and have been reading up a lot about it. I have come across three different methods to create components:
Functional Components:
const Hello = ({world}) => {
return (
<div>{"Hello" + world}</div>
);
}
React.createClass (Factory):
const Hello = React.createClass({
render: function() {
return <div>{"Hello" + this.props.world}</div>
}
});
ES6 Class Extends
class Hello extends React.Component {
render() {
return (
<div>{"Hello" + this.props.world}</div>
);
}
}
Apart from the obvious that the functional components don't have any state coupled to it and is probably a more functional approach to doing components, why would I use the different methods?
In the React documentation they use all three methods. Some of the Stack Overflow articles suggest the Class method and then some suggest the Factory method.
Using functional is recommended for components that are stateless.
Using React.Component extend is recommended if you are working with ES6+/TypeScript code. React Native has support only for this type of component creation.
React.createClass is for used with ES5.
Browsers will soon have a complete support and Facebook recommends to use React.Component instead of React.createClass and to use functional for stateless.
Edit
Facebook added a deprecation warning to React.createClass in React 15.6.0 and points users to use create-react-class instead.
As I know, it is recommend to use functional component when you need just create presentational logic component. For component that has any logic we use smth like React.createClass().
There are two ways of doing that:
First, you create general component and than divide it on presentational logic and business logic.
Second, you can create them alongside.
Be careful! When divide these components, your business logic must render your presentational logic!
For more practice see tutorials on the codecademy