I want to use function instance, not pure object, as state object in react. But I'm not sure if that's ok:
class Test extends Component {
constructor(props) {
super(props);
this.state = new Domain();
}
}
So long as typeof new Domain() == 'object' it'll be fine.
What you have to remember (and possibly account for) is that React won't know about it if the instance updates itself.
All changes to this.state have to go through the setState interface and the Domain function probably doesn't know that.
this.state = new Domain();
// this won't cause your component to re-render
this.state.update(10);
// and this is an anti-pattern
this.setState(this.state);
It's very difficult to listen for changes to an object and if your domain object has instance methods which modify its state, you might find it starts to get tough to keep it in sync with your component.
Yes that's ok.
There's no such thing as a pure or non-pure object in javascript (there are pure functions). There are different notations that can be used to create a javascript object though.
One of these is the 'Function constructor' which is the one you used in new Domain(), and another common one is the object literal notation {}.
React just expects an object and he does not care which notation you used to create it.
Related
I have a base component where i want to have an instance level variable that is updated by subclasses. The only way i can get this work is to add it to state which i don't want to do due to the fact that the value of this variable is NOT related to the UI so i don't want to trigger a re-render.
So take following component:
class BaseComponent extends React.Component {
constructor(props) {
super(props);
this.params = [];
}
addParam(name) {
this.params.push(name);
}
getUrl() {//this.params is always undefined
return format("{0}?", this.constructor.name, this.params.join("&");
}
}
So this.params is always undefined which makes sense since it is not part of state. This variable is related to the url and not the UI so when the value is updated i don't want to have to trigger a re-render by updating the state.
Not sure what the best approach here is?
Options i know of:
1) Add to state which will trigger re-render
2) Call forceUpdate() which will also trigger re-render
I don't like either of these options so i am hoping someone knows the correct way to do what i am trying to do.
I'm new to ReactJs and trying to follow best practices. From my research, I've come across a couple of contradicting articles discussing how implementation should be.
Should state rely on the properties being passed down from a parent component? In the comparisons below, they are both following SRP, but not sure which is best. Would like your advice, Thanks!
1. -- Best Practices for Component State in React.js
First, and probably the most important of all, the state of a component should not depend on the props passed in. (see below for example of what we should not do)
class UserWidget extends React.Component {
// ...
// BAD: set this.state.fullName with values received through props
constructor (props) {
this.state = {
fullName: `${props.firstName} ${props.lastName}`
};
}
// ...
}
2. -- 7 architectural attributes of a reliable React component
Let's refactor to have one responsibility: render form fields and attach event handlers. It shouldn't know how to use storage directly.....The component receives the stored input value from a prop initialValue, and saves the input value using a prop function saveValue(newValue). These props are provided by withPersistence() HOC using props proxy technique.
class PersistentForm extends Component {
constructor(props) {
super(props);
this.state = { inputValue: props.initialValue };
}
// ...
}
3. -- In my case, I have something like the following (wondering if this is an acceptable implementation?) - Should state be handled in Tasks, or in another TasksWithPersistence type of component that sits between TasksWithData and Tasks?
export default function TasksWithData(TasksComponent) {
return class withData extends React.Component {
render() {
const tasks = TaskAPI.getTasks();
return (
<TasksComponent
tasks={tasks}
{...this.props}
/>
)
}
}
}
export default class Tasks extends React.Component {
state = {
tasks: [],
addItemInput: null
};
// ...
componentDidMount() {
this.updateComponentState({tasks: this.props.tasks});
}
componentDidUpdate() {
this.prepUIForNextAddition();
}
// ...
}
The gist of your question seems to revolve around the anti-pattern that is to take some props and duplicate it into the state. This, mutating of props, isn't the purpose of the state. Props are immutable, duping them to the state defeats this design.
The purpose of the state is to manage things that are specific to the React Component, i.e. tightly scoped to only that React component. For instance a showHide switch for something to display within the React component. Think of the state as a locally scoped variable if it helps.
Most of the time this anti-pattern of duping the props can be satisfied by a function within the React object. For example, your state.full_name variable becomes a named function, fullName, bound to the React Component. (all code examples are assuming JSX syntax)
Note: in JavaScript camelcase is the naming structure for functions and variables, I'm assuming you're coming from ruby based on the underscore naming convention. IMO it's best to stick to the convention of the language with which you're writing the code. This is why I use camelcased naming.
...
fullName() {
return this.props.firstName + " " + this.props.lastName
}
...
That function can then be called within the render of the component
# in render() portion of your React component, assuming jsx syntax
<p>Hello, {this.fullName()}</p>
Note: Remember that in ES6 you have to bind the methods in your react class in the constructor or use => syntax so that you can call them with this.
...
constructor(props) {
super(props);
this.fullName = this.fullName.bind(this);
}
...
You could also decompose the relevant parts to a new Component called FullName if it will be utilized by multiple components.
<FullName firstName={this.props.firstName} lastName={this.props.lastName} />
Technically, "the react way" is, at least in this author's opinion, to decompose this into another component for reusability. However component reuse needs to be weighed against the complexity added, i.e. don't optimize prematurely. So you may not want to take that too far at first. The times when it's necessary will emerge naturally.
A very broad generalization of React's props is that they are guaranteed, are immutable, and they flow down like a waterfall from the topmost component. If you need to update them, update them at the highest level where it makes sense.
In a soley React based approach, if you have something that a parent needs to be aware of, "lift" that part of the code up to the parent and vice versa bind it down to the child as a props, e.g. an AJAX function that calls an API. I think of it as trying to keep the components as dumb as possible.
The parent becomes the "source of truth" for the item you "lifted". The parent handles the updates, and then passes the results to the children. So in the parent, it may exist as a state variable and then get passed as props to the child object, which then passes it along as props to it's child object, etc. The children would update as the state gets changed in their parent when it propagates down through the chain as props.
If your app is React only, i.e. no stores that manage objects such as in the flux pattern or redux pattern, you may have to store things in the topmost objet's state which technically could be viewed as bad. As your system becomes more complex, this functionality would be better handled by flux or redux's parts.
Hope this helps!
There is a huge difference between example 1 & 2.
In example #1, the reason it's bad to set state from the those props in that way is that if the props change, the widget will not update. Best practices or not, that is just wrong and bad in any framework. In that particular case, there really is no point in even using the state. Props alone will suffice.
In example #2 the prop is only being used to give the state an initial value (The prop is even named initialValue), implying that further changes to the state will be controlled by the component regardless of prop changes. It does not break single responsibility principle to use props for an initial state, especially when it's explicitly use for that purpose.
I really don't see those two examples as being contradictory because they are completely different. Further, there is no rule in single responsibility principle that you can't set state from props, you just need to pay attention to the context in which you are doing it.
TL;DR: Can I trust the reconciliation algorithm not to re-instantiate my stateful component simply because the change in Virtual DOM was too complicted to keep track of it?
I believe, that React.Component instances are created and destroyed by React run-time to match the shape of Virtual DOM. As a programmer I declaratively describe the Virtual DOM, and the life cycle of instances is controlled by the React itself. I understand that a special reconciliation algorithm tries hard to reuse as much of old instances as possible when the Virtual DOM changes its shape. Also, I understand that if the only difference is in props, then an old instance simply gets its props updated and informed about it via lifecycle methods.
I also expect that for functional components which simply map props to Virtual DOM there is no point in talking about lifecycle, as it does not really matter if this is the same or not the same instance. In particular one does not have to trust the reconciliation algorithm to be very smart, as the component would look and behave the same regardless of if it is the same instance with updated props, or a fresh instance.
But can I, and should I, trust the reconciliation algorithm in case of stateful components?
Say, that I have a component which stores some data in its state and directly on its instance. Moreover, let's assume that the constructor of this component initializes both of them:
constructor(props) {
super(props);
this.state = {
value: ''
};
this.length = 0;
}
Also, assume that the state evolves in time, say, because of user actions
onChange = (e) => {
this.setState({value: e.target.value}
this.length = e.target.value.length;
}
Can I, or can I not, assume that this instance will not get killed and reconstructed on a whim of the React framework? The above component is not "functional", as it has an inner state, which as a developer I presume to be somehow "preserved" even if something complicated happens in the higher part of the components tree during reconciliation.
From the many examples in the docs and the web, I understand, that the community assumes, that the state and private properties of the instance are not reset, unless the parent explicitly changes the key property, or gets rid of the child, and instantiates a new one later on. But are these assumptions explicitly stated in the docs?
And the question in the other way round: is changing a key of a child guaranteed to make a new instance, or can react decide to reuse some old instance with a different key (thus reusing its state as well)? In other words: is the key trick guaranteed to work or is it just a hack?
EDIT
An example of a problematic situation: https://codesandbox.io/s/9rqrPJnLD. Here we have a stateful component:
class Stateful extends React.Component{
state = { now: new Date()};
render(){
return <div>{this.state.now.toString()}</div>
}
}
living in a hostile environment, of a parent who often changes mind about the layout, and the child is sometimes nested in a div, and sometimes not:
class App extends React.Component{
state = { div: true}
componentDidMount(){
setInterval(()=>{
this.setState(state => {
return {div: !state.div}
});
},2000)
}
render(){
return React.createElement(this.state.div ? 'div' : 'span',null,React.createElement(Stateful))
}
}
It seems that the child is re-instantiated each time the parent changes layout, and the state is not preserved when it happens. This partially answers my own question. The unanswered part being: what are the other cases which are difficult for the reconciliation algorithm.
Is it possible to define default contexts for components, so that if the parent component does not pass down the context to the child, the child does not break? The only thing I can think of at the moment is
constructor() {
super();
if (!this.context.role) {
this.context.role = 'public';
}
}
Would that work?
Context is similar to props except that a change in context doesn't actually trigger a render. Usually context takes its value from a state or a store so that's usually not a problem. Another downside is unlike props, React doesn't provide a way to set a default value for it.
You can probably make a feature request in react's repo. A workaround would be to assign a default value to it before you use it. e.g:
class MyComponent {
// use this.getRole to access the role
getRole() {
return this.context.role || 'public';
}
}
Edit: your code snippet would not work because the context value could possibly get overriden by the parent during the render pipeline; plus it's not documented what would happen when you update context object directly.
I've frequently encountering dynamic components not being able to update each other directly. Multiple models that update each other's attributes but not their views.
model2View.onClick=() {
model1.change;
model1View.forceUpdate();
}
i've often resorted to throwing in callback functions into the mix which is just a wrapper that updates the model and forceupdate the overhead view after change.
it gets worse when the model update is a modelside function that updates more than one model, in which case I've been using the nearest ancester view to perform the forceupdate.
model2View.onClick=() {
the following 3 could be wrapped in one method on model1
model1.change;
model2.change;
model3.change;
modelsWrapperView.forceUpdate();
}
After many force updates, I am just wondering if that's the way react was meant to be used or I'm missing something.
Here's an oversimplified example of the problem i'm trying to solve:
https://jsfiddle.net/x3azn/ann6qb30/1/
You are attempting to mutate an object that is part of your state and React won't re-render because it doesn't know that something has changed. That's why you're having to call forceUpdate.
You should treat state as immutable and use setState to update it (updated demo):
class TransformersApp extends React.Component {
toggleDeception() {
// Create a new object rather than mutating the existing one.
var newTransformer = Object.assign({}, this.state.transformer, {
isDecepticon: !this.state.transformer.isDecepticon
});
// Update the state.
this.setState({
transformer: newTransformer
});
}
}
This is made clear by the docs for setState:
NEVER mutate this.state directly, as calling setState() afterwards may replace the mutation you made. Treat this.state as if it were immutable.
You may find it helpful to use something like Immutable.Map as your state object as that will prevent you from mutating the state at all.