I have a number of methods in a React class component. The component itself receives a number of props.
I am wondering if I should take the props and add each of them as this.propName in the constructor and then access the props using this.propName. Here is an example. What is best practice?
const classComponent = class classComponent extends Component {
constructor(props) {
super(props)
this.propA = props.propA
this.propB = props.propB
}
methodA() {
console.log(this.propA)
}
}
Alternative
const classComponent = class classComponent extends Component {
constructor(props) {
super(props)
}
methodA() {
console.log(this.props.propA)
}
}
Official documentation of React.js in State and Lifecycle section says:
While this.props is set up by React itself and this.state has a special meaning, you are free to add additional fields to the class manually if you need to store something that is not used for the visual output.
In your case, most likely it should stay as a prop. Whenever you pass anything as a parameter, which in React.js philosophy would be a prop, it's most likely an ingredient of the visual effect.
Once you create a variable it uses memory and, even if you are referencing a type, like an array or an object, you make your file bigger. Creating new names for variables already accessible to your class/function make no sense, so don't do it.
The way you handled the props does not allow the component to update when it receives new props; mainly because constructor is only called once--at the creation of the component.
A better way to do it is to use Destructuring assignment in the render function:
render() {
{propA, propB, ...rest} = this.props;
//Rest code here, using propA, propB
//However, don't use this.propA, or this.propB
}
If you still like to do the way you want to do, you have to add the following function inside your component, to make your component update whenever it receives new props:
componentWillReceiveProps(nextProps) {
this.propA = nextProps.propA;
this.propB = nextProps.propB;
}
As you can see, unnecessary code had to be included, so I think this is a wrong way to do it!
Related
I have a class which has many functions, i wish to outsource these functions and put each group of function inside a file of their own and then use them by importing and calling them.
Usually this is very simple, you simply put the function bodies inside another file and then export them, but in my case i use this.state and this.setState, is it still possible to outsource these function? if not, is there a better practice?
Thank you.
I just knocked this up real quick with no testing whatsoever, tell me if this is kinda what you were looking for?
window._stateManager = new StateManager();
class X extends React.Component {
constructor(props) {
super(props);
_stateManager.addStateFunction(this.setState.bind(this));
}
}
class StateManager() {
constructor() {
this.stateFunctions = [];
}
addStateFunction(ss) {
this.stateFunctions.push(ss);
}
updateStates(obj) {
this.stateFunctions.forEach(ss => {
ss((state => {
// here you have access to "this.state" as state
return Object.assign({}, state, obj);
// whatever you return from this function changes the state of the react component
}))
})
}
}
Why you want to update the state by the function that doesn't belong to your component or child component. It doesn't make sense. You want to use redux there will be a single source of state of your entire App stored in the store. All your state update logic will be separated in reducer and you would have access to action creator that can update your App's state.
Note: I encounter this specific problem using React Native, but I guess this goes for React in general as well.
I have a react component built using React.Component.
I don't need to set state, but I do have props. My proposed syntax was as follows:
class Header extends Component {
constructor(props) {
super(props);
}
render() {
return <div>{this.props.title}</div>;
}
}
I understand I can use a function to construct this component, like this:
const Header = (props) => {
return <div>{props.title}</div>;
}
But I prefer the former, because my component will grow, might have state etc, and I just want to keep all my components built in a similar fashion.
Now, my linter complains about having a useless constructor, but how else do I access the props while keeping a class constructor instead of a function constructor?
If you want to use this.props in the constructor, you need to pass props to super. Otherwise, it doesn't matter because React sets .props on the instance from the outside immediately after calling the constructor.
So just simply remove constructor() if useless
you can access props without constructor in a class using "this", like this:
class XXXXXX extends React.Component {
render() {
return (
<div>{this.props.value}</div>
)
}
}
So i love this React thingy, and we have this so called 'stateless' functions to help us build a 'dumb' component. Now i want to create a class that produce a stateless function. Why you may ask, well i love the idea of inheritance and wanting to 'extend' my stateless function basic capability, said i want to add a helper function as a statics that binds to the function itself.
I ended up with this code
class Stateless {
constructor() {
return this.render.bind(this)
}
nanny() {
// do something
}
render(props) {
// yeay! a stateless function!
// plus i can access nanny by using this.nanny()
}
}
And when i extend it, i can see that the inheritance is working well.
BUT, if then i initialize the class:
const stateless = new Stateless()
Why can't i access stateless.nanny even tho inside the render function i can see that this.nanny is accessible? Where does the nanny lives? Does it binded to the render function?
EG:
class Stateless {
constructor() {
return this.render.bind(this)
}
nanny() {
console.log('foo')
return true
}
render(props) {
console.log(this.nanny()) // -> returns 'foo'
return 'JSX'
// this should return a JSX
}
}
const stateless = new Stateless() // -> stateless IS a function
stateless()
// 'foo'
// true
// JSX
stateless.nanny
// undefined
While clearly inside render when i called this, there is nanny there. But when i
refer it outside, the nanny is gone. I thought nanny should be a static property of the stateless, right?
If you are returning object from constructor - new will return that object instead of the instance of the class being constructed (more info).
Therefore line
const stateless = new Stateless()
will assign to stateless variable result of this.render.bind(this) - that is reference to method (function) of Stateless class, that is not an instance of Stateless. Therefore stateless.nanny makes no sense - as function render does not have such property defined. On the other hand calling bound render function directly - produce the expected result.
All in all - i strongly do not recommend you to return anything from constructor (unless you are dealing with some really weird requirements like controlling number of instances and such). It makes code hard to understand and maintain.
Your example should work if you remove this.render.bind(this) from your constructor.
It should also work, if you just remove return from the constructor:
constructor() {
this.render.bind(this)
}
However, you might actually be looking to create a higher order component that can enhance the component that it wraps.
Your higher order component is a function that returns a class that renders the component that it passed to it:
import React from 'react'
function HigherOrderComponent(WrappedComponent) {
return class Enhancer extends React.Component {
constructor(props) {
super(props)
}
exampleFunc() {
// Code here
}
render() {
return <WrappedComponent exampleprop={ this.exampleFunc } />
}
}
}
export default HigherOrderComponent
Then you can import HigherOrderComponent into your stateless dumb component file and wrap the export:
import React from 'react'
import HigherOrderComponent from './HigherOrderComponent'
const DumbComponent = (props) => {
// Return JSX
// You can use props.exampleprop
}
export default HigherOrderComponent(DumbComponent)
Here are some articles that you can read on higher order components:
https://facebook.github.io/react/docs/higher-order-components.html
https://medium.com/#franleplant/react-higher-order-components-in-depth-cf9032ee6c3e
I've been using this.props and props interchangeably, and for the most part, there doesn't seem to be a major difference between them (as far as I can tell).
However, I've been running into issues lately that make me think that when and why one is used over the other matters.
This is where I'm currently using them interchangeably:
constructor(props, context) {
super(props, context);
this.data = props.card.data;
this.dataLength = this.props.card.data.length;
}
What's the difference and when do you use one over the other, and where?
Thanks!
It all depends on the type of component you are using.
const StatelessComponent = (props) => {
return <div>{props.something}</div>;
}
class SomeComponent extends Component {
constructor(props){
super(props)
}
render() {
return <div>{this.props.something}</div>;
}
}
Here you will notice that in the stateless component it is just a regular function without any this context. The props are passed to the function so we already have access to it.
When you have a class you have a this context that the props live on.
In the constructor of a class the props are passed to the class constructor. So in the context of that constructor function props is passed as an argument and is a local variable
I would recommend you stick to a pattern, when you have props passed as an argument to a function you use props when you are in other methods of a react class you use this.props. That is how it was intended to be used. Also there is something to be said for consistency, so whether you choose one or the other stick with that pattern. It can be confusing if you don't follow a pattern / keep things consistent.
Only in the constructor of React ES2015 components (non-function components) will you be able to refer to props as it is passed into the constructor. If you do this.props === props in the constructor, it will evaluate to true.
However in React, you can only use this.props after you call super(props). This is part of the ES2015 Class spec.
For simplicity, I usually just use solely props within the constructor, and this.props within the component lifecycle methods and in render.
In simple terms:
1.props.data is used in functional components
2.this.props.data is used in Class components
copy the code and run it in "stackblitz" ->https://stackblitz.com/edit/react-3wr8jb
the following code shows usage of both class and functional components with props.data and this.props.data
import React, { Component } from 'react';
import { render } from 'react-dom';
//=================PROPS=======================
//Both Class and Functional components have "properties" ie props
//properties are immutable->fixed->cant be changed
//=================================================
//props.data in functional components
function A1(props)
{
return <h2>functional component->props.data:{props.data}</h2>
}
//===============================================
//this.props.data in class components
class A2 extends React.Component{
render()
{
return<h2>class component->this.props.data:{this.props.data}</h2>
}
}
//===================================================
var element1=
<div>
<hr/>
//data from class and functional component
<A1 data="Sample data" />
<A2 data="Sample data"></A2>
<hr />
</div>
render(element1, document.getElementById('root'));
Is it possible (or even a good idea) to add my own props to another React component, like:
<SomeCustomComponent myOwnParam={handler}>
As mentioned by Tyrsius, it really depends on the implementation of SomeCustomComponent. If the component does not use the myOwnParam prop anywhere, passing it won't accomplish anything. On the other hand, some React components might use JSX spread attributes to reference props not directly enumerated in the code.
As an example, the following implementation of SomeCustomComponent would pass your myOwnParam prop down to its child div:
class SomeCustomComponent extends React.Component {
constructor(props) {
super(props);
}
render() {
var {customComponentProp, ...other } = this.props;
return (
<div customComponentProp={customComponentProp} {...other}></div>
);
}
}
So again, it depends on the implementation of SomeCustomComponent what will happen.
See Transferring Props documentation for more details: https://facebook.github.io/react/docs/transferring-props.html
This won't cause an error, but unless SomeCustomComponent is looking for this prop nothing will be done with it. It is possible for a component to loop over its props, so this could be a usable strategy, but I am not sure what you would do with it. You couldn't define anything but iteration logic over properties that you don't know in advance.