We are currently refactoring to use higher-order components. For the most part this is making everything much simpler.
We have HOCs for fetching data and listening to stores. For example, we have connectStores, which takes a list of stores to subscribe to and a function to fetch the data (to pass as extra props):
connectStores(FooComponent, [FooStore], function (props) {
return {
foo: FooStore.get(props.id),
};
});
However, there are a few places where the process of fetching the data from the store depends upon the state. For example, we have a SelectFooPopup the presents the user with a list of items to select from. But there is also a search box to filter the list, so at the moment the component listens directly to the store and then fetches the data itself like this:
componentDidMount() {
var self = this;
this.listenTo(FooStore, 'change', function () {
self.forceUpdate();
});
}
render() {
var items = FooStore.search(this.state.searchText);
// render...
}
(this.listenTo is a mixin which we're trying to replace with HOCs so we can use ES6 classes)
I can think of a few options, but I don't like any of them:
Option 1: Remove listenTo and cleanup the listener manually
componentDidMount() {
var self = this;
this.listener = function () {
self.forceUpdate();
};
FooStore.on('change', this.listener);
}
componentWillUnmount() {
if (this.listener) {
FooStore.removeListener('change', this.listener);
}
}
render() {
var items = FooStore.search(this.state.searchText);
// render...
}
I really hate having to do this manually. We did this before we had the listenTo mixin and it's far too easy to get wrong.
This also doesn't help when the subscription has to fetch the data from the server directly rather than using a pre-filled store.
Option 2: Use connectStores but don't return any extra data
class SelectFooPopup extends React.Component {
render() {
var items = FooStore.search(this.state.searchText);
}
}
connectStores(SelectFooPopup, [FooStore], function (props) {
// Just to forceUpdate
return {};
});
This just feels wrong to me. This is asking for trouble when we start optimising for pure components and suddenly the child component doesn't re-render anymore.
Option 3: Use connectStores to fetch all the data and then filter it in render
class SelectFooPopup extends React.Component {
render() {
var items = filterSearch(this.props.items, this.state.searchText);
}
}
connectStores(SelectFooPopup, [FooStore], function (props) {
return {
items: FooStore.getAllItems(),
};
});
But now I have to have a completely separate filterSearch function. Shouldn't this be a method on the store?
Also, it doesn't make much difference in this example, but I have other components with a similar issue where
they are fetching data from the server rather than subscribing to a pre-filled store. In these cases the
data set is far too large to send it all and filter later, so the searchText must be available when fetching the data.
Option 4: Create a parent component to hold the state
Sometimes this is the right solution. But it doesn't feel right here. The searchText is part of the state of this component. It belongs in the same place that renders the search box.
Moving it to a separate component is confusing and artificial.
Option 5: Use a "parentState" HOC
function parentState(Component, getInitialState) {
class ParentStateContainer extends React.Component {
constructor(props) {
super();
this.setParentState = this.setParentState.bind(this);
if (getInitialState) {
this.state = getInitialState(props);
} else {
this.state = {};
}
}
setParentState(newState) {
this.setState(newState);
}
render() {
return <Component {...this.props} {...this.state} setParentState={ this.setParentState } />;
}
}
return ParentStateContainer;
}
// Usage:
parentState(SelectFooPopup, function (props) {
return {
searchText: '',
};
});
// In handleSearchText:
this.props.setParentState({ searchText: newValue });
This also feels really wrong and I should probably throw this away.
Conclusion
In React we have 2 levels: props and state.
It seems to me that there are actually 4 levels to think about:
props
data that depends on props only
state
data that depends on props and state
render
We can implement layer 2 using HOCs. But how can we implement layer 4?
Related
I have a render method in my container component like this:
render() {
const { validationErrors } = this.state
const { errorsText, errorsFields} = validationErrors.reduce(
(acc, error) => {
acc.errorsText.push(error.text)
acc.errorsFields[error.field.toLowerCase()] = true
return acc
},
{
errorsText: [],
errorsFields: {},
},
)
return (
<MyViewComponent
errorsText={errorsText}
errorsFields={errorsFields}
/>
)
}
As you can see every render there are some computations happens (returned array and object with the new values), then I pass it into my child component as a props. I have a feeling that this is a wrong pattern. We should keep render function 'pure'. Isn't it? The question is: Where is the best place for making such computations outside the render?
If this were a functional component (which I highly recommend you use in the future, by the way), you'd be able to use the 'hook' useEffect to recalculate errorsText and errorsField whenever this.state.validationErrors changes, and only when it changes.
For your Class Component, however, I assume at some point you set this.state.validationErrors. What you should do is create a method that runs your reducer and stores errorsText and errorsField to state, then place a call to this method after each point you set this.state.validationErrors. Then, remove the logic in the render method and replace errorsText and errorsField with this.state.errorsText and this.state.errorsField respectively.
Doing this will ensure you only ever run your reducer when necessary (i.e. when this.state.validationErrors changes).
Your component would end up looking something like this:
class MyComponent extends Component {
...
someCallback() {
const validationErrors = someFunctionThatReturnsErrors();
// We do the logic here, because we know that validationErrors
// could have changed value
const { errorsText, errorsFields } = validationErrors.reduce(
(acc, error) => {
acc.errorsText.push(error.text);
acc.errorsFields[error.field.toLowerCase()] = true;
return acc;
}, {
errorsText: [],
errorsFields: {},
},
);
// Put everything in the state
this.setState({
validationErrors, // you may not even need to set this if it's not used elsewhere`
errorsText,
errorsFields
});
}
...
render() {
const {
errorsText,
errorsFields
} = this.state;
return (
<MyViewComponent
errorsText={errorsText}
errorsFields={errorsFields}
/>
);
}
}
It is pure, as it has no side effects.
As long as this does not create performance issues I see no problem with this. If it does create performance issues, you should look into memoizing the reduce. If you were using hooks you could use the built-in React.useMemo for this. While using class version you could look into something like https://www.npmjs.com/package/memoize-one
I'm using react + mobx + typescript and want to send a json array from my logic layer to a UI component. The json comes from an async api call. I"m saving it in a mobx #observable variable and sending it as props to my UI component. I'm relying on componentDidUpdate() in my UI to detect when changes happen, since it's coming from an api call. Things aren't working as expected.
Here's a trimmed version of my logic component:
#observer
class DeadletterLogic extends Component<Props, State> {
#observable queues: any[];
#observable deadletterQueues: any[];
#observable temp: any;
private service: DeadletterService;
constructor(props: any) {
super(props);
// create new service object
this.service = new DeadletterService();
this.returnDeadletterInfo(this.service);
}
async returnDeadletterInfo(service: DeadletterService) {
await this.getQueues(this.service); // get all queues from the service layer
await this.getDeadletters(this.service);
}
async getQueues(service: DeadletterService) {
// in order to gets a list of queues here, a fetch call must be made in the service layer to the MessageQueueAPI
let queues = await service.getQueues(); // gets a json array of all the queues
this.queues = queues.map(data =>
data.id
);
}
async getDeadletters(service: DeadletterService) {
this.deadletterQueues = []; // initialize the array
let queues = this.queues;
for (var i = 0; i < queues.length; i++) {
let queueToGet = queues[i]; // gets current queue name
let deadletters = await service.getByQueue(queueToGet); // gets the json object with this name from service layer
this.deadletterQueues.push(deadletters); // pushes that object onto the array
}
}
render() {
return (
<div>
<Deadletters deadletterQueues={this.deadletterQueues}/>
</div>
);
}
}
And here's a trimmed version of my UI:
deadletterQueues: any[];
}
interface State {
loading: boolean
}
#observer
class Deadletters extends Component<Props, State> {
#observable oneDeadletter: any;
constructor(props: any) {
super(props);
this.state = { loading: true };
}
componentDidUpdate(prevProps) {
if (this.props.deadletterQueues !== prevProps.deadletterQueues) {
// here is where I would map the information I need, but this is only hit once
}
}
render() {
return (
<div>
{this.oneDeadletter}
</div>
);
}
}
The issue is that componentDidUpdate is only triggering once, so the intial prop value (of nothing) is all I can get from props.deadletterQueues in the child component. I'd like componentDidUpdate to hit whenever the #observable array is pushed to (or modified) in the parent component so that I can extract data from it in the UI.
Even more confusing, I do get my desired functionality of the prop updating in the child component if I change my logic layer to something like:
this.temp = deadletters.map(data =>
data.messageId);
this.deadletterQueues.push(this.temp); // pushes that object onto the array
and push this.temp as props instead. However, I need to be able to map from the UI, so this doesn't work for me. I'm struggling to see why one of these actions causes componentDidUpdate to trigger when the #observable in the parent changes and the other does not.
Any enlightment on this would be very much appreciated. I believe it's a mobx thing and has to do with pushing values to an array not being recognized as a change, but I'm not sure about that.
Please try to insert one line in render function.
render() {
const { deadletterQueues } = this.props;
return (
<div>
{this.oneDeadletter}
</div>
);
}
In fact, I don't know the reason.
It is much similar to my case here.
I will update my answer when I find the reason. :)
EDIT: I found the reason:
MobX only tracks data accessed for observer components if they are directly accessed by render
For more details: check these below
here and here
It's easiest to explain what I'm trying to accomplish with an example:
addContact = ev => {
ev.preventDefault();
this.props.setField('contacts', contacts => update(contacts, {$push: [{name: 'NEW_CONTACT'}]}));
this.props.setFocus(`contacts.${this.props.data.contacts.length-1}.name`);
};
In this example, this.props.setField dispatches an action which causes an extra field to be added to my form.
this.props.setFocus then attempts to focus this new field.
This won't work because the form hasn't re-rendered yet when setFocus is called.
Is there any way to get a callback for when my component has been re-rendered after a dispatch call?
If you need to see it, setField looks like this:
setField(name, value) {
if(_.isFunction(value)) {
let prevValue = _.get(data, name);
if(prevValue === undefined) {
let field = form.fields.get(name);
if(field) {
prevValue = field.props.defaultValue;
}
}
value = value(prevValue);
}
dispatch(actions.change(form.id, name, value));
},
I would put
this.props.setFocus(`contacts.${this.props.data.contacts.length-1}.name`);
in componentDidUpdate and I would call it on some condition. Like let's say, prevProps.data.contact.length < this.props.data.contacts.
UPDATE
You should keep this:
addContact = ev => {
ev.preventDefault();
this.props.setField('contacts', contacts => update(contacts, {$push: [{name: 'NEW_CONTACT'}]}));
};
In a parent component, and in that component you will render all the sub components:
render() {
return {
<div>
{contacts.map(c => <ContactComponent key='blah' contact={c}>)}
<a onClick={addContact}>Add Contact</a>
</div>
};
}
Then your contact component, will be as you like, the same goes for all the other elements you want to accommodate with this functionality.
At that point, you're asking:
Where is the focus thingy?
What you need for this abstraction-ish is higher order composition. I will give you an example, but please make time to read about HOCs.
This will be you HOC:
function withAutoFocusOnCreation(WrappedComponent) {
// ...and returns another component...
return class extends React.Component {
componentDidMount() {
// contacts string below can be changed to be handled dynamically according to the wrappedComponent's type
// just keep in mind you have access to all the props of the wrapped component
this.props.setFocus(`contacts.${this.props.data.contacts.length-1}.name`);
}
render() {
return <WrappedComponent {...this.props} />;
}
};
}
And then in each child component you can use it as a decorator or just call it with your HOC and that's all. I won't write more, but do make the time to read more about HOCs, here is the official documentation's page
official documentation's page. But you can check Dan Abramov's video on egghead as well. I hope my answer helps you, please accept it if it does :) Take care!
I would like to set the state of a component based on the current size of the browser window. The server-side rendering has been used (React+Redux). I was thinking about using the Redux store as a glue - just to update the store on resize.
Is there any other/better solution that doesn't involve Redux.
Thanks.
class FocalImage extends Component {
// won't work - the backend rendering is used
// componentDidMount() {
// window.addEventListener(...);
//}
//componentWillUnmount() {
// window.removeEventListener('resize' ....);
//}
onresize(e) {
//
}
render() {
const {src, className, nativeWidth, nativeHeight} = this.props;
return (
<div className={cn(className, s.focalImage)}>
<div className={s.imageWrapper}>
<img src={src} className={_compare_ratios_ ? s.tall : s.wide}/>
</div>
</div>
);
}
}
I have a resize helper component that I can pass a function to, which looks like this:
class ResizeHelper extends React.Component {
static propTypes = {
onWindowResize: PropTypes.func,
};
constructor() {
super();
this.handleResize = this.handleResize.bind(this);
}
componentDidMount() {
if (this.props.onWindowResize) {
window.addEventListener('resize', this.handleResize);
}
}
componentWillUnmount() {
if (this.props.onWindowResize) {
window.removeEventListener('resize', this.handleResize);
}
}
handleResize(event) {
if ('function' === typeof this.props.onWindowResize) {
// we want this to fire immediately the first time but wait to fire again
// that way when you hit a break it happens fast and only lags if you hit another break immediately
if (!this.resizeTimer) {
this.props.onWindowResize(event);
this.resizeTimer = setTimeout(() => {
this.resizeTimer = false;
}, 250); // this debounce rate could be passed as a prop
}
}
}
render() {
return (<div />);
}
}
Then any component that needs to do something on resize can use it like this:
<ResizeHelper onWindowResize={this.handleResize} />
You also may need to call the passed function once on componentDidMount to set up the UI. Since componentDidMount and componentWillUnmount never get called on the server this works perfectly in my isomorphic App.
My solution is to handle resize event on the top-most level and pass it down to my top-most component, you can see full code here, but the gist is:
let prevBrowserWidth
//re-renders only if container size changed, good place to debounce
let renderApp = function() {
const browserWidth = window.document.body.offsetWidth
//saves re-render if nothing changed
if (browserWidth === prevBrowserWidth) {
return
}
prevBrowserWidth = browserWidth
render(<App browserWidth={browserWidth} />, document.getElementById('root'))
}
//subscribing to resize event
window.addEventListener('resize', renderApp)
It obviously works without Redux (while I still use Redux) and I figured it would be as easy to do same with Redux. The advantage of this solution, compared to one with a component is that your react components stay completely agnostic of this and work with browser width as with any other props passed down. So it's a localized place to handle a side-effect. The disadvantage is that it only gives you a property and not event itself, so you can't really rely on it to trigger something that is outside of render function.
Besides that you can workaround you server-side rendering issue by using something like:
import ExecutionEnvironment from 'exenv'
//...
componentWillMount() {
if (ExecutionEnvironment.canUseDOM) {
window.addEventListener(...);
}
}
I've been playing around with React Native lately and I reached a point where I became interested in managing my state more properly, as a start achieving a shared state between all the components.
The answer of course is Flux. Before moving forward with some more advanced solutions (e.g. Redux, Alt, MobX) I thought I should start with understanding the raw structure itself, with the help of one small tool, that is the Flux dispatcher.
import React, { Component } from 'react';
import { AppRegistry, Text, View } from 'react-native';
import EventEmitter from 'EventEmitter';
import { Dispatcher } from 'flux';
class Store extends EventEmitter {
list = [];
actions = {
add: title => dispatcher.dispatch({ type: 'add', payload: { title } })
};
handle = ({ type, payload }) => {
switch(type) {
case 'add': this.add(payload.title); break;
}
};
add(title) {
this.list.push(title);
this.emit('change');
}
}
const store = new Store(), dispatcher = new Dispatcher();
dispatcher.register(store.handle);
class App extends Component {
state = { list: store.list };
componentWillMount() {
this.listener = store.addListener('change', () => this.setState({ list: store.list }));
}
componentDidMount() {
setInterval(() => store.actions.add(new Date().getTime()), 1000);
}
componentWillUnmount() { this.listener.remove(); }
render() {
return (
<View style={{ marginTop: 20 }}>
<Text>{JSON.stringify(this.state.list)}</Text>
</View>
);
}
}
AppRegistry.registerComponent('straightforwardFlux', () => App);
Notice in the view layer, we have {JSON.stringify(this.state.data)}, naturally when the store is updated the view will be re-rendered since it is linked to the state.
When changing to {JSON.stringify(store.data)} the view is also re-rendered! this shouldn't happen because the view should only update when there is a change in the state that affect the view directly, in this case there is no state rendered in the view whatsoever. Am I missing something here? why would we encounter this behaviour?
This leads to another question, does render() get called every time there is a state change? even if it doesn't affect the way the view layer looks? I've looked into this and I got two different answers, one says yes and that componentShouldUpdate() returns true by default, meaning that some changes need to be made here (if so, how?), and the other one was simply no, it doesn't update with each setState().
Overall, is this implementation correct?
Per the documentation...
setState() will always trigger a re-render unless conditional rendering logic is implemented in shouldComponentUpdate(). If mutable objects are being used and the logic cannot be implemented in shouldComponentUpdate(), calling setState() only when the new state differs from the previous state will avoid unnecessary re-renders.
tl;dr; React isn't analyzing your view to see explicitly what state it is depending on, that is up to you to optimize with shouldComponentUpdate().
shouldComponentUpdate(nextProps, nextState) {
// check if your view's attributes changes
let check1 = nextState.foo != this.state.foo
let check2 = nextState.bar != this.state.bar
// if return is true, the component will rerender
return check1 || check2
}