We Keep Coding

How to deal with duplicated function code that alters parent state

Say we got a Page-component that delegates the rendering of notifications to a Notification-component. The Page-component's render method contains the following ...
{this.state.notifications &&
<Notifications
notifications={this.state.notifications}
removeNotifAt={index => this.setState(prevState => {
const copy = [...prevState.notifications]
copy.splice(index, 1)
return { notifications: copy }
})}
removeNotifyBy={id => this.setState(prevState => {
const copy = [...prevState.notifications]
const index = copy.findIndex((notif, _) => { return notif.id === id })
copy.splice(index, 1)
return { notifications: copy }
})}
/>
}
... as you might notice, Notifications require some rather large function to alter the state of its parent. Since they access this.state, these functions have to be defined in the parent of Notifications, in this case Page.
Now, one can imagine that multiple pages have notifications that needs rendering and so they all have to code-duplicate the code snippet above. As we all know, code-duplication is bad, so how can we best avoid it?
It's impossible to extract the functions removeNotifyAt and removeNotifyBy out into functions defined in, say, Notifications.js since they need to access this.state.
So, what's the react-way of dealing with such duplicate functions that you can't extract away because it needs to access this.state? I suppose I am not the first one stumpling upon this, giving how trivial of a case this is.

You can move the code from removeNotifyBy and removeNotifyBy into functions, and place them in the parent component. Then you can pass them into the child components as props.

You could extract those functions into Notifications.js. (That is in case you don't wish to write those functions inside parent component).
Both the parent's state as will as the function that sets the state can be passed as props to Notifications component.
Example:
<Notifications parentState={this.state} parentStateHandler={this.setState} />
//Note: Ideally props shouldn't be named like this and one must avoid passing entire state object as prop, rather you should split it into props that the child component requires. However this is just to give you the clarity regarding how to access parent's state in child
Now Notifications component has entire parents state which can be accessed by props.parentState and you can also set Parent state by using props.parentStateHandler instead of this.setState

React changing state in Parent , does render calls for all its children and sub-children as iteration?

i am setting the language name in my local storage , when it changes from a dropdown in topbar , i want the whole current view to be re-rendered and words translated to the selected language. my layout is like this
render(){
return (
<MainContainer>
<TopBar/>
<SideBar/>
<RouteInsideSwitch/>
</MainContainer>
)
}
in render of components ,the words to be translated basically calls a function that returns the correct word based on the local storage language name.
i change the language and i set the state in maincontainer for selected langauge and set it in local storage. however i dont want to move that state from Maincontainer to all my components. also dont want to store it in redux because then all the possible containers have to listen to it and then pass it to their children as props.
what currently happens is that saving state in mainContainer without passing it to any children , the children does re-render but only the immediate ones , if there are more children in those children and so on , it does not re-render because i m not passing the state throughout the chain.
open to any suggestion based on different pattern for language changing. but my question is that is there any way to re-render the current open view (all components in dom).

If your concern is that you have a number of "possible containers" which all need to handle the state change, perhaps consider creating a higher order component that includes the common language rendering logic (your RouteInsideSwitch leads me to believe this may the issue). In that way, you can avoid duplicating that logic across a ton of "possible" components that all require the functionality of dynamic language rendering and will avoid the need to dial a bunch of components into a redux store, assuming they are in the same hierarchy.
const DynamicLanguageComp = RenderComponent => {
return class extends Component {
constructor(props) {
super(props)
//additional state setup if needed
}
changeLangFunc = () => { /* handle change */ }
render() {
return <RenderComponent handleLanguageChange={this.changeLangFunc} {...this.props} {...this.state} />
}
}
}
If you would like to avoid a re-render on certain intermediate components that may be receiving props by way of state change you can implement the lifecycle method shouldComponentUpdate(), which by default returns true. You can make a comparison of nextProps to your current props, and return false if a re-render is undesired despite new props.

Share data between React components with no relation?

I'm working on a React component library that allows for client-side data filtering by passing an array of objects and an <input/> as props to a <SearchFilter/> component. I want to return the filtered results to a separate <SearchResults/> component that can be rendered elsewhere in the tree (i.e. the results component doesn't have to be a child of the input component).
I've got the filtering figured out, but I'm not sure the best route to take in React on getting the filtered data to the <SearchResults/> component.
This is what I'd like to end up with...
<SearchFilter
data={data}
input={<input type="text" value={value} onChange={this.handleChange}/>}
/>
Then, using Render Props to return the data and map over that to return JSX, there would be the results component. Something like this...
<SearchResults
render={data => (
data.map(el => (
<div>
<span>{data.someProperty}</span>
</div>
)
)}
/>
This is what I'd like to achieve because I want to allow for rendering the <SearchFilter/> component at one place in the tree, and allow the <SearchResults/> component to be rendered elsewhere, so that there's maximum flexibility in how the tree is composed and, therefore, how the view is rendered.
I've looked into the Context API, but it seems like that would require a handful more components to be a part of my library, which further complicates what I'm trying to achieve. If that's the only way around it, then that's fine, but I wanted to ask and see if anyone can think of another solution.
Thanks!

The bigger issue is that you will need to manage a state that is shared between components on a higher level, i.e., any component that will wrap these other two components, ultimately. With plain React, this state would be managed by the parent (or ancestor) component, passing down the relevant values as props. This opposed to the, usually bad, idea to have sibling components influence each other's state, since you well get into the "who's boss here"-problem.
The thing the Context API handles is not having to pass down props for things that typically don't change (or: typically shouldn't cause renders to trigger often).
A global state store, such as Redux, can help you modelling this, but in essence it's not much more than 'a' component managing state, and other components rendering according to that state. Events within the lower components trigger changes in the data, which will cause the state to change, which will cause the props of the children to change, which then will cause re-renders.
I'd advise you to try using this simple pattern:
class Search ... {
state = {data: [], text: ""}
render() {
return (
<div>
<SearchFilter
data={this.state.data}
onSearch={() => this.fetchNewData()}
onChange={(e) => this.setState({text: e.targetElement.value})}
text={this.state.text}
/>
<SearchResults data={this.state.data} />
</div>
);
}
fetchNewData() {
fetch('/url?text=' + this.state.text)
.then((newData) => { this.setState({data: newData}); })
}
}
Something along these lines. If you have trouble modelling stuff like this, you can use Redux to force you to do it in a similar way, and avoid managing local state intermixing with global state (which is typically something that is hard to manage).
If you do this right, components that have no state (i.e., aren't responsible for managing state and thus have no event handlers) can all become pure components, i.e. stateless components, i.e. functions that return JSX based on props:
const SearchResults = ({data}) => <div>{data.map( () => <etc /> )}</div>

You could create a data store class that holds your filter, pass it in as a property to both components, and have your SearchFilter component change a value in that.

Why are higher-order components a lot more useful than the regular component?

I can't seem to grasp the understanding of why higher order components are highly valued over the regular components? I read a tutorial on them and that higher order components are good because they: 1) Allow code re-use, logic and bootstrap abstraction. 2) Able to do render highjacking. 3) Able to abstract state and manipulate them. 4) Able to manipulate props. Source: link
An example of a higher order component in code was shown there as:
function refsHOC(WrappedComponent) {
return class RefsHOC extends React.Component {
proc(wrappedComponentInstance) {
wrappedComponentInstance.method()
}
render() {
const props = Object.assign({}, this.props, {ref: this.proc.bind(this)})
return <WrappedComponent {...props}/>
}
}
}
These look almost the same exact code as a regular class definition that receives props and you are still able to "manipulate props" and "manipulate state" inside that class
class Something extends React.Component {
constructor(props) {
super(props);
this.state = { food: 'no_food_received_yet' }
}
componentDidMount() {
this.setState({ food: 'apple' });
}
render() {
return (
<div>
<p>{ this.state.food }</p>
<h2>{ this.props.food }</h2>
</div>
);
}
}
Actually I didn't get to manipulate or mutate the props but I can just receive them, apply them to state and output that state.
This is not to bash on higher order components---this is actually the complete opposite. I need to understand where I am wrong and why I should integrate higher order components into my react app.

HOCs are absolutely useful, but they're useful in the same way any "higher order" function is.
Consider the following component:
let Button = props => <button style={{ color: props.color }} />
You could make another component called BlueButton:
let BlueButton = props => <Button color="blue" />
There's nothing wrong with that, but maybe you want any component to be able to be blue, not just a button. Instead we can make a generic HOC that "blueifies" the passed component:
let blueify = Component => props => <Component {...props} style={{ color: 'blue' }} />
Then you can make blue buttons, blue divs, blue anything!
let BlueButton = blueify(Button)
let BlueDiv = blueify(props => <div {...props} />)

Imagine you had an app where certain screens were private and only available to authenticated users. Imagine you had 3 such screens. Now on each screen's container component you can have the logic to check if the user is authenticated and let them through if they are, or send them back to login when they are not. This means having the exact same logic happen 3 times. With a HOC you can code that logic just once and then wrap each private screen in with the HOC thus giving you the same logic over and over, but the code only needs to exist in one place. This is an example of great code reuse that HOCs offer.

Higher order components are more generalized, and so in theory can be applied to a broader number of cases. In the more general sense, higher-order components (and higher-level languages) tend to be more expressive.
In your case, the difference is readily apparent. The non-generalized (lower-order) component has hard-coded HTML in it. This is programming 101; constant declarations like PI are preferred over hard-coded declarations like 3.14159 because they give meaning to magic numbers and allow one point of modification.
A simple example of a higher order "component" (in this case a higher order function) is a sort function that takes as one of its arguments an ordering function. By allowing the ordering to be controlled by an outboard function, you can modify the behavior of the sort without modifying the sort function itself.

When to use state and when props?

I am studying the principles of react.
According to some reviews, some people says is better to keep your component stateless, what does it mean?
But other people says, that if you need to update your component, then you should learn how to set your state to the proper state.
I saw this.props / this.setProps and this.state / this.setState and I am confuse with that.
Something I am trying to figure is, how can I update a component by itself and not from a parent component? should I use props or state in this case?
I already read some docs about props and state, what I don't have clear, is: when to use one or another ?

Props vs. state comes down to "who owns this data?"
If data is managed by one component, but another component needs access to that data, you'd pass the data from the one component to the other component via props.
If a component manages the data itself, it should use state and setState to manage it.
So the answer to
how can I update a component by itself and not from a parent component? should I use props or state in this case?
is to use state.
Props should be considered immutable and should never be changed via mutation. setProps is only useful on a top-level component and generally should not be used at all. If a component passes another component a property, and the first component wants the second to be able to change it, it should also pass it a function property that the second component can call to ask the first component to update its state. For example:
var ComponentA = React.createClass({
getInitialState: function() {
return { count: 0 };
},
render: function() {
return <Clicker count={this.state.count} incrementCount={this.increment} />;
},
increment: function() {
this.setState({count: this.state.count + 1});
}
});
// Notice that Clicker is stateless! It's only job is to
// (1) render its `count` prop, and (2) call its
// `incrementCount` prop when the button is clicked.
var Clicker = React.createClass({
render: function() {
// clicker knows nothing about *how* to update the count
// only that it got passed a function that will do it for it
return (
<div>
Count: {this.props.count}
<button onClick={this.props.incrementCount}>+1</button>
</div>
);
}
});
(Working example: https://jsbin.com/rakate/edit?html,js,output)
For and object-oriented programming analogy, think of a class/object: state would be the properties you put on the class; the class is free to update those as it sees fit. Props would be like arguments to methods; you should never mutate arguments passed to you.
Keeping a component "stateless" means that it doesn't have any state, and all its rendering is based on its props. Of course, there has to be state somewhere or else your app won't do anything! So this guideline is basically saying to keep as many components as possible stateless, and only manage the state in as few top-level components as possible.
Keeping components stateless makes them easier to understand, reuse, and test.
See A brief interlude: props vs state in the React docs for more information.

Use state when you know the variable value is going to affect the view. This is particularly critical in react, because whenever the state variable changes there is a rerender(though this is optimized with the virtual DOM, you should minimize it if you can), but not when a prop is changed (You can force this, but not really needed).
You can use props for holding all other variables, which you think can be passed into the component during the component creation.
If you have want to make a multi-select dropdown called MyDropdown for example
state = {
show: true,
selected:[],
suggestions:this.props.suggestionArr.filter((i)=>{
return this.state.suggestions.indexOf(i)<0;
})
}
props={
eventNamespace:'mydropdown',
prefix : 'm_',
suggestionArr:[],
onItemSelect:aCallbackFn
}
As you can see, the objects in the state variable are going to affect the view some way or the other.
The objects in the props are mostly objects which should remain the same throughout the component life cycle. So these objects can be callback functions, strings used to namespace events or other holders.
So if you do want to update the component by itself, you need to have to look into how componentWillRecieveProps ,componentWillUpdate, componentDidUpdate and componentShouldUpdate works. More or less, this depends on the requirement and you can use these lifecycle methods to ensure that the rendering is within the component and not in the parent.