I am looking to create a one page application with ReactJS.
Is it advisable to combine it with angular or it is suitable just on its own? I would like to populate the one page site with sections - adding various features like carousels, sliders, isotope filters ...
<!DOCTYPE html>
<html>
<head>
<title>React Js one page</title>
<script src="https://fb.me/react-with-addons-0.14.7.min.js"></script>
<script src="https://fb.me/react-dom-0.14.7.min.js"></script>
</head>
<body>
<section>
One
<script>
var HelloMessage = React.createClass({
render: function() {
return <div>Hello {this.props.name}</div>;
}
});
ReactDOM.render(<HelloMessage name="Colonel Mustard" />, mountNode);
</script>
</section>
<section>
Two
<script>
var CommentBox = React.createClass({
render: function() {
return (
<div className="commentBox">
Hello, world! I am a CommentBox.
</div>
);
}
});
ReactDOM.render(<CommentBox />, mountNode);
</script>
</section>
<section>
Three
<script>
"use strict";
var MarkdownEditor = React.createClass({
displayName: "MarkdownEditor",
getInitialState: function getInitialState() {
return { value: 'Type some *markdown* here!' };
},
handleChange: function handleChange() {
this.setState({ value: this.refs.textarea.value });
},
rawMarkup: function rawMarkup() {
return { __html: marked(this.state.value, { sanitize: true }) };
},
render: function render() {
return React.createElement(
"div",
{ className: "MarkdownEditor" },
React.createElement(
"h3",
null,
"Input"
),
React.createElement("textarea", {
onChange: this.handleChange,
ref: "textarea",
defaultValue: this.state.value }),
React.createElement(
"h3",
null,
"Output"
),
React.createElement("div", {
className: "content",
dangerouslySetInnerHTML: this.rawMarkup()
})
);
}
});
ReactDOM.render(React.createElement(MarkdownEditor, null), mountNode);
</script>
</section>
</body>
</html>
If you're just starting out with React, I'd highly recommend following Pete Hunt's advice:
You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.
The best thing to do is get started with React by itself and manage application state using the local state that comes with each of your components.
When you find that you start having to pass data back up to parent components, then add Flux into the mix and rewrite your stateful components to instead use Flux stores.
We'll look at how to tackle writing a simplified version of the StackOverflow answer component as a React application from the bottom up.
Notice, I said React application, not React component. This is because there's no technical difference. A React application is a big React component made up of lots of smaller ones.
Identify Components
Once you have an interface for your application (anything from wireframes to html/css) you can visually subdivide them to work out how they'll fit together as React components.
There are no hard and fast rules about how exactly you decide what should or should not be it's own component, but you'll get a feeling for it the more times you do it.
is <Answer />
is <Votes />
is <AnswerText />
is <AnswerActions />
Because we're building from the bottom up, we'd start by implementing each of the child components and testing that they work alone.
At this point in the development lifecycle we'd just write static markup for each component. There's no need to think about props or state yet.
We can use the stateless component syntax to get started on the components we've identified. Here's an example of how we might write the <Votes /> component.
function Votes() {
return (
<div>
<a>▲</a>
<strong>0</strong>
<a>▼</a>
</div>
);
}
Of course this doesn't do anything, but it allows us to start composing our components to get a feel for the structure of the application.
We can render this into the DOM to check that it works at any time.
ReactDOM.render(<Votes />, document.getElementById('app'));
Once you'd finished implementing static versions of the other components, you could put them together to create the parent <Answer /> component.
function Answer() {
return (
<div>
<Votes />
<AnswerText />
<AnswerActions />
</div>
);
}
Design Data Flow
The next thing to do is to figure out how data flows through your application.
At this point we can create some dummy data in the form of an answer object that looks something like this:
{
"id": 0,
"votes": 0,
"text": "This is an answer"
}
Initially we can render the <Answer /> component by passing this answer object to it as a prop.
<Answer answer={answer} />
Now it's that components job to pass down the appropriate data to its children.
Obviously not each child needs all of the data though, so we'll have to decide what data goes where. Let's update our <Answer /> component.
function Answer(props) {
var answer = props.answer;
return (
<div>
<Votes id={answer.id} count={answer.votes} />
<AnswerText text={answer.text} />
<AnswerActions id={answer.id} />
</div>
);
}
The <Votes /> component needs know the current number of votes and it also needs to know the id of the answer so that it can communicate change to the server.
The <AnswerText /> component just renders a block of text, so that's all we need to pass it.
Finally, the <AnswerActions /> component renders a list of links that allow the user to perform some action (share, edit, flag) on the answer. This component also needs the answer's id so that it can communicate with the server.
Now we have to update these child components in turn to use these new dynamic values, instead of the static values we used at first. We'll revisit the <Votes /> component to see this happen.
function Votes(props) {
var urls = {
upvote: '/api/answers/' + props.id + '/upvote',
downvote: '/api/answers/' + props.id + '/downvote'
};
return (
<div>
<a href={urls.upvote}>▲</a>
<strong>{props.votes}</strong>
<a href={urls.downvote}>▼</a>
</div>
);
}
Now our vote component will make a HTTP request to the appropriate endpoint when we click on the vote buttons, however, we'd rather make this update without reloading and re-rendering the entire application.
Identify Stateful Components
The final piece of the component development process is to identify stateful components. These components have moving parts and data that will change during the lifetime of the application.
Each time the state inside a component changes, the entire component re-renders. We can revisit the wireframes to see which of our components needs to manage changing data.
This application only has one stateful component () and that's `. When we click on one of the arrows, we need to update the number to reflect the new count.
It's the only one of our components that ever needs to re-render.
This means we'll need to upgrade the component to use React's createClass syntax. This allows it to start managing it's own state.
var Votes = React.createClass({
getInitialState: function() {
return { votes: this.props.votes };
},
upvote: function() {
var newVotes = this.state.votes + 1;
this.setState({
votes: newVotes
});
},
downvote: function() {
var newVotes = this.state.votes - 1;
this.setState({
votes: newVotes
});
},
render: function() {
return (
<div>
<a onClick={this.upvote}>▲</a>
<strong>{this.state.votes}</strong>
<a onClick={this.downvote}>▼</a>
</div>
);
}
});
I've jumped the gun a bit and implemented the full component, but hopefully you'll get the idea.
First we use getInitialState to set up some state to represent the initial number of votes in the component.
Next we implement upvote and downvote component methods that update the component state.
Finally we re-implement the render method from before, but have the arrows trigger the new component methods, not page requests.
Each time we make a call to setState, React will re-render the component. Hopefully you can see why we put the state in the <Votes /> component and not the <Answer /> component. It would be crazy to re-render the answer text and actions, just because the votes had changed.
Flux It Up
Once we've identified and implemented all of our stateful components, we can start to move their state out into Flux stores.
It's much more likely that a real application would have an <AnswerStore /> than a <VoteStore />, so that's what we'll implement. For now we'll just keep mocking our data.
var AnswerStore = {
_listeners: [],
_answers: {
"0": {
"id": 0,
"votes": 0,
"text": "This is an answer"
}
},
get: function(id) {
return this._answers[id];
},
update: function(id, update) {
var answer = this.get(id);
var updatedAnswer = Object.assign({}, answer, update);
this._answers[id] = updatedAnswer;
this.emit();
},
listen: function(f) {
this._listeners.push(f);
},
emit: function() {
this._listeners.forEach(function(f) {
f();
});
}
};
In this example, I've written a fairly generic store that contains data, provides simple handlers for listening to model changes and finally exposes methods for mutating the data in the store.
It's important that our update method treats the individual answers as immutable in this application, otherwise we risk mutating an object that other parts of the application have a reference to, causing the object to change underneath them. We use Object.assign to create a new object each time, based on the old one.
The next thing we need to do is set up some action handlers for this store.
dispatcher.register(function(action) {
switch(action.type) {
case 'UPVOTE':
var votes = ActionStore.get(action.id);
ActionStore.update(action.id, { votes: votes + 1 });
break;
case 'DOWNVOTE':
var votes = ActionStore.get(action.id);
ActionStore.update(action.id, { votes: votes - 1 });
break;
}
});
This simply wires the update method to two actions called 'UPVOTE' and 'DOWNVOTE'
Now we connect Flux to our <AnswerComponent /> which needs to be re-written in the long form.
var Answer = React.createClass({
getInitialState: function() {
return { answer: {} };
},
componentWillMount: function() {
this.update();
AnswerStore.listen(this.update);
},
update: function() {
var id = this.props.id;
this.setState({ answer: AnswerStore.get(id) });
},
render: function() {
var answer = this.state.answer;
return (
<div>
<Votes id={answer.id} count={answer.votes} />
<AnswerText text={answer.text} />
<AnswerActions id={answer.id} />
</div>
);
}
});
In our componentWillMount method we fetch our initial data for the store, then set up a listener on the store that fetches and updates the component state, whenever the store changes.
Finally, we need a way to dispatch the appropriate actions from our <Votes /> component.
The most popular way to do this is with action creators. An action creator is a function which takes some data as parameters, then packages it up and dispatches it as an action.
var Actions = {
upvote: function(id) {
dispatcher.dispatch({
type: 'UPVOTE',
id: id
});
},
downvote: function(id) {
dispatcher.dispatch({
type: 'DOWNVOTE',
id: id
});
}
};
Then we call these actions from inside our <Votes /> component (which can become stateless again).
function Votes(props) {
var id = props.id;
return (
<div>
<a onClick={Actions.upvote.bind(null, id)}>▲</a>
<strong>{props.votes}</strong>
<a onClick={Actions.downvote.bind(null, id)}>▼</a>
</div>
);
}
This component now uses the action creators to dispatch actions for our Flux store(s) to handle.
If we look at the flow of data through our application, we can see that we now have a unidirectional cycle, rather than a tree.
The <Answer /> component passes the id down to the <Votes /> component.
The <Votes /> component dispatches an action using that id.
The AnswerStore processes the action and emits a change.
The <Answer /> component hears the update and updates its state, re-rendering its children.
Here's a jsfiddle of this demo application.
Scale Up
This is a very simple component that only handles a tiny amount of data flow and even less application state, however, it's enough to show you how to compose a React component and that's all you need to build a React app.
Let's imagine we were implementing a StackOverflow question as a React application.
function App() {
return (
<Page>
<Navigation />
<SideBar>
<MetaDetails />
<Ads />
<RelatedQuestions />
</SideBar>
<Question />
<AnswerList />
<AnswerEditor />
<Footer />
</Page>
);
}
It might seem like a complex application, but you can break it down and express it as distinct components, then you can implement and test the components individually, just like we did here and bring them altogether to form a complex application.
Don't Over Complicate
For most simple React applications like this one, Flux is not actually necessary. It's worth remembering that React was released over a year before Flux and yet it was adopted by a lot of developers regardless.
Of course, I've only really covered structuring and implementing components here. Taking an application from wireframes to deployment is a much more complicated process and there's no way it could be covered in detail in one answer. In time, you'll probably also want to learn about:
Package management and dependencies
Module bundlers
Routing
Hot Reloading
ES6/Babel
Redux
Server Side Rendering
Immutable Data
Inline Styles
Relay/Falcor/GraphQL
It takes some time to get through this list of things, the trick is not to rush. Don't overcomplicate your existing project until you find the reasons that these solutions exist, naturally.
I think react-howto is the best guide out there. Although it's not heavy on detail, it links to a lot of good resources and most importantly it provides an opinionated guide to the order in which you should learn these technologies on your way to becoming a competent ReactJS developer.
The choice of framework (Angular/React) does not prevent building any of the functionality you described, and your site could be built with neither, either, or both of those frameworks.
While you certainly could combine Angular and React, I'm not sure why you would want to, and it's not going to be the easiest of tasks. It's doable, of course, but it's going to provide a lot of difficulty for very little ultimate gain.
If you want to build a SPA with React, I would focus more on finding a Flux implementation that you like, and learning how to integrate that. Flux is designed specifically with React in mind to handle large SPAs which might have complicated data flow, and it's certainly a tool that is easier to incorporate early on.
The only other library I would consider out of the gate would be Immutable.js, which pairs very well with both React and Flux.
But otherwise, until you find a need to bring in additional frameworks/libraries, attempt to hold off. With all of the exciting JS frameworks out there, it's tempting to want to use them all, but in reality you're better off picking one to focus on, and then maybe bringing in some tools from another later on when they are necessitated.
Related
Can't find any recent official info if any of the three options below is allowed?
constructor(props) {
this.state = {
item: <SomeItem />,
item1: () => <SomeItem />,
item2: SomeItem,
};
}
I found this answer but it references an old link from web archive which says:
What Shouldn’t Go in State?
...
React components: Build them in render()
based on underlying props and state.
But that link doesn't say why that is a bad idea, if it will introduce bugs, etc.
This is a really good question.
The reason that putting components in state is advised against is just that it goes fundamentally against the React model, which is that a component provides a render method (which is a pure function) that the React engine uses to automatically update the DOM to reflect the values of the component's props and state.
The output of that render, i.e. the React Element, is supposed to be used directly by the React engine. The contract is that your app, and all its components, generate a bunch of Elements in a pure way for the React engine to manage.
By doing things like introducing side effects in render, or putting the Elements in state, you're essentially breaking the 'pure' contract and it may give unpredictable results, which may or may not be considered bugs in your application. The specifics of the bugs may even change with different versions of React, with different engine implementations. The point is that you're breaking the React contract, so whilst it may work in some cases, it also may not in others or even the same cases as React itself changes. The behaviour is not guaranteed.
React has built-in ways to cache renders based on prop values, like React.memo, that the engine provides and understands, and are part of the contract. If you want to cache render output for performance reasons, this is the way to do it.
Indeed, this is exactly why such functions are provided by the React API rather than just letting you do it yourself.
At the end of the day, React component instances are just objects, and you can store objects in state, so it shouldn't cause any trouble if you avoid pitfalls. One such pitfall is that if you're creating handlers to put on their props, those handlers will close over the context in which they're created, which may lead to some unexpected outcomes. Here's an example of that:
const {useState, Fragment} = React;
function Thingy({onClick}) {
return <div onClick={onClick}>A</div>;
}
// STALE CLOSURE
function Example() {
const [value, setValue] = useState(0);
const [comp, setComp] = useState(
<Thingy onClick={() => { console.log("A: value = " + value); }} />
);
const handler = () => {
setValue(v => {
++v;
console.log("B: value = " + v);
return v;
});
};
return <Fragment>
{comp}
<div onClick={handler}>B</div>
</Fragment>;
}
ReactDOM.render(<Example />, document.getElementById("root"));
<div id="root"></div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.13.0/umd/react.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.13.0/umd/react-dom.production.min.js"></script>
This is the classic stale closure thing. It's probably a bit easier to do accidentally using functional components and hooks (as I did there) rather than class components, but it's definitely possible to do with class components as well.
But if you're not doing that (either not creating functions for the component you're storing, or creating ones that don't use anything they close over that may change), it should be fine.
But look at React.memo, which may be a better answer depending on what your reason for wanting to put component instances in state is.
You can do something like this, if I understand you right
const Title = () => {
return <h1>Hello CodeSandbox</h1>;
};
class App extends React.Component {
state = {}
constructor(props) {
super(props)
this.state = {
item: function() {
return <Title />;
}
};
}
render() {
return (
<div className="App">
{this.state.item()}
<h2>Start editing to see some magic happen!</h2>
</div>
);
}
}
export default App;
You can do it, but it's a bit strange. A React element is an object like any other. In this case, it will be the result of a method call:
// `<SomeItem/>` compiles to
React.createElement(SomeItem, null);
// A similar `React.createElement("div", null)` becomes
const el = {
$$typeof: Symbol(react.element),
key: null,
props: {},
ref: null,
type: "div",
_owner: null,
}
It's strange because it's unnecessary (and a little confusing). You can just generate the element (including any state or props updates) whenever you need it.
There's also a risk that you break one of the core guarantees of React: elements are immutable. Storing the element like this gives you a chance to mutate it and thus confuse React.
If you need many copies of the same element then it may be slightly more performant to keep it like this, especially if it is expensive to generate.
I'm trying to understand stateless components and what the difference is between these examples:
class App {
render() {
return (
<div>
{this.renderAFunction('hello')}
</div>
);
}
renderAFunction(text) {
return (
<p>{text}</p>
);
}
}
and this:
class App {
render() {
return(
<div>
<RenderAFunction text='hello'/>
</div>
);
}
}
const RenderAFunction = ({text}) => (
<p>{text}</p>
);
Or if there is any difference at all?
Functionally, there is absolutely no difference. Both end up rendering a paragraph element, but there are other aspects to consider. There are three points to make (in my opinion) when examining both methods:
Reusability: You have to understand to separate components when you need to. If renderAFunction is just meant to generate some JSX based on, for example, an API request, then it's fine being in a method. But if you want to reuse it somewhere else, then separate it into it's own component. A huge part of React is component reusability and getting rid of code duplication. Separating the method into it's own component would be imperative to accomplish this.
Purpose: There are reason to use stateless function components and reasons not to. The whole point of stateless functional components is to not have state and be presentational. If you need to do something that involves the React lifecycle or internal state, keep it as a method, or new class depending on if you want it reusable.
Performance: Using a stateless functional component would be less efficient. This is because it's a component, not just some JSX returned from a method. As of right now, the React team plans on making some optimizations for stateless functional components because they do not contain state and are merely presentational, but this probably won't happen until after React Fiber is done and thus your stateless functional component has no optimizations versus a regular full-fledged class component. That makes it incredibly inefficient versus a method returning some JSX, especially if it's just used once in another component.
A good rule of thumb is to ask yourself, do I need it anywhere else? If not, then keep it in a method. If you don't need it anywhere else, separating the JSX into a separate component would have worse performance and wouldn't follow React's core principles.
If you are going to need it somewhere else, then separate the component so you follow React's concept of reusability.
Your App's render function will be translated into following JS code for your first example:
render() {
return React.createElement(
'div',
null,
this.renderAFunction('hello')
);
}
And the following one for the second one:
render() {
return React.createElement(
'div',
null,
React.createElement(RenderAFunction, { text: 'hello' })
);
}
While they both looks almost the same, there is one significant difference: laziness. React will execute RenderAFunction body only in case it gonna be mounted to the DOM hierarchy.
It is insignificant is your case, but imaging following example:
const LazyApp = () => {
const heavy = <div><HeavyStuff /></div>
// ...
return <div>done it</div>
}
const HardWorkingApp = () => {
const heavy = <div>{HeavyStuff()}</div>
// ...
return <div>done it</div>
}
const HeavyStuff = () => {
// ... do heavy rendering here
}
Lazy app will not perform any heavy stuff at all. Maybe it is not very clear from that synthetic example why one would do anything like that at all. But there are real-world examples out there, when something conceptually similar (creating Components without rendering them) is happening.
Basically, both will serve the same purpose. But the real advantage of creating a component is its reusability.
If you have to render that particular piece of jsx just for this component. Then, there is no need to create a separate component.
I need to render a widget which takes in settings from a SettingsPanel and passes them to a LayoutPanel (which would then re-render itself based on the updated settings). I can't seem to figure a 'clean' way to do this. Here's what I have so far:
Widget.js
class Widget extends Component {
handleSettingsChange() {
//need to let layout know of change
}
render() {
<div>
<SettingsPanel
onSettingsChange={handleSettingsChange}
initialSettings={this.props.settings}
/>
<Layout
data={ this.props.data}
/>
</div>
}
}
App.js
const settings = {
hideImages: true,
itemsPerPage: 5
}
<Widget settings={ settings } data={ data } />
My first thought was that, within Widget, I could do
constructor() {
super()
this.setState({ settings: this.props.settings });
}
handleSettingsChange(data) {
//Assuming data is of the form {changedProperty: value}
this.setState({ settings: Object.assign({}, this.state.settings, data) });
}
render() {
<div>
<SettingsPanel
onSettingsChange={handleSettingsChange}
initialSettings={this.props.settings}
/>
<Layout
data={ this.props.data}
settings={ this.state.settings }
/>
</div>
}
This way the parent is a dump message broker, and doesn't not have to know the specifics of what specific settings are being change. But of course, this doesn't work because,
a. I'm told setting state from props is an anti-pattern
b. The constructor doesn't have access to this.props anyway, and doing it else-where (componentDidMount?) feels wrong.
My second thought was to go to setProps to set props on children from the parent, but of course that's deprecated.
How do I solve this? I could probably re-architect this so this isn't a problem, but frankly I'd just like to understand what I'm missing, or what the 'react' way of solving things like this is.
This question is similar to the same problem I'm having but I'm having trouble understanding/applying what the accepted solution suggests to my problem.
tldr; "How can I make a parent component pass state from one child to another, while being ignorant of what exactly it's passing?"
While lukewestby's answer is correct in that it solves the problem in the original question, after further reflection I realized that that was the wrong question to ask - i.e., it was an architecture issue which is why I was having trouble with the implementation.
In this case the data-flow is [data]-> App -> Widget -> Children. "App" fetches data, so App owns it. Widget should not be able to to modify, handle changes to data it doesn't own. Hence, the callback needs to be passed to the grandparent (App), not the parent (Widget). Here's what I ended up doing.
App.js
constructor() {
this.state = { settings: { hideImages: true } };
}
handleSettingsChange(data) {
this.setState({ settings: data });
}
render() {
<Widget settings={ this.state.settings }
onSettingsChange={ this.handleSettingsChange }
/>
}
Widget.js
handleDisplaySettingsChange(data) {
this.props.onSettingsChange(data);
}
render() {
return (
<div>
<SettingsPanel
onSettingsChange={ this.handleDisplaySettingsChange }
/>
<Layout
{...this.props.settings }
/>
</div>
);
}
The advantage of doing it this way is that there is a single source of truth for settings, which is maintained by the owner (App). In the original suggestion, if on a later fetch by App the settings had changed the inner components wouldn't receive it (which explains why the React docs claim setting state from props is an anti-pattern)
It's not necessarily true that setting state from props is an anti-pattern. It seems completely reasonable to initialize a component's state from props in the constructor. Doing so doesn't degrade testability or reliability much if at all.
You can access props in the constructor as they are passed as the first parameter. You'll need to call super first, but then you can do whatever you'd like:
class Widget extends React.Component {
constructor(props) {
super(props);
this.setState({ settings: props.settings });
}
}
Then you can continue down the path you were originally headed. Another slightly more complex option would be to use a state container like Redux to handle state management and transitions for you, but only do this if you don't mind the additional learning and complexity of adding more to your app setup.
I am currently learning react and I have run into the problem of elegently extracting states from my components.
basically I have a few components which contains forms and other inputs from which I need the data in my business logic, the data I need is coupled with the state of the component. From what I understand the data should have unidirectional flow but I can't think of how I can make my data flow back towards my business logic. I could just make some interface functions which call the respective, but I feel this would violate the unidirectional flow.
anyhelp with some examples would be greatly appreciated!
You typically pass down callbacks from parent components to child components as props. When the state changes in any of the child components, it invokes that callback and passes whatever data is appropriate in each use case. Your "controller-view" (the root component that implements the actual callback) then does whatever business logic you need based on the current state and then updates its state accordingly (causing a re-render of the component tree from that component down). Read the docs about component communication.
Something like this:
var Child = React.createClass({
onTextChange: function() {
var val = 13; // somehow calculate new value
this.props.onTextChange(val);
},
render: function() {
return <input type="text" value={this.props.val} onChange={this.onTextChange} />
}
});
var Parent = React.createClass({
onTextChange: function(val) {
var newVal = someBusinessLogic(val);
this.setState({val: newVal});
},
render: function() {
return <Child onTextChange={this.onTextChange} val={this.state.val} />
}
});
The best way to work with data flow in React is to use the Flux pattern. You need some time to understand how it works, but it will make your life much easier as your project grows.
Look at some Flux tutorial, for example this one (using the Alt flux implementation): https://reactjsnews.com/getting-started-with-flux/
I'm trying to create a simple grid-based editor for a data structure and I'm having a couple conceptual problems with React.js. Their documentation is not very helpful on this, so I'm hoping someone here can help.
First, what is the correct way to transfer state from an outer component to an inner component? Is it possible to have state changes in the inner component "bubble up" to the outer component(s)?
Second, can two separate components share data, so that a mutation in one is visible in the other?
Below is a simplified example of the sort of thing I want to do (JSFiddle version):
I have a company object containing an array of employee objects. I want to lay out the employee list in an editable grid. When I click the button, I want to see the resulting company object, along with any mutations (writes to the console).
/** #jsx React.DOM */
var Cell = React.createClass({
getInitialState: function () {
return {data: ""};
},
componentWillMount: function () {
this.setState({data: this.props.data});
},
onChange: function (evt) {
console.log(this.state, evt.target.value);
this.setState({data: evt.target.value});
},
render: function () {
var data = this.props.data;
return <input value={this.state.data} onChange={this.onChange} />
}
});
var Row = React.createClass({
render: function () {
return (<div className="row">
<Cell data={this.props.data.name} />
<Cell data={this.props.data.location} />
<Cell data={this.props.data.phone} />
</div>);
}
});
var Grid = React.createClass({
render: function () {
var rows = this.props.data.map(function (rowData, index) {
return <Row key={index} data={rowData}>Row</Row>;
});
return <div className="table">{rows}</div>;
}
});
var Button = React.createClass({
getInitialState: function () {
return {data: {}}
},
componentWillMount: function () {
this.setState({data: this.props.data});
},
onClick: function () {
console.log(this.state);
},
render: function () {
return <button onClick={this.onClick}>Update</button>;
}
});
var company = {
name: "Innotech",
employees: [
{id: "1", name: "Peter", location: "IT", phone: "555-1212"},
{id: "2", name: "Samir", location: "IT", phone: "555-1213"},
{id: "3", name: "Milton", location: "loading dock", phone: "none"}
]
};
React.renderComponent(
<div><Grid data={company.employees} /><Button data={company} /></div>,
document.getElementById('employees')
);
I think this is the most underdocumented part of React right now. The suggested way to communicate between components is to simply set props when communicating from parent to child and to pass callbacks through props when communicating from child to parent.
When you feel that you want to share data between sibling components, it means that there should be a parent component managing the state and passing it to both components. Most of the time, your state should live near the top of your component hierarchy, and each piece of info should live in (at most) one component's state, not more.
For a bit more about this, see Pete Hunt's blog post, Thinking in React.
With this in mind, I've updated your fiddle.
I've changed Grid so that it doesn't maintain its own state but instead always displays the data passed via its props, and calls onCellChange from its props when it wants to request a change of the data from its parent. (The Grid component will expect its parent to update the grid's data prop with the modified data. If the parent refuses (perhaps because of failed data validation or similar), you end up with a read-only grid.)
You'll also notice that I created a new Editor component to wrap the grid and its sibling button. The Editor component now essentially manages the entire page. In a real app, it's likely that the contents of the grid would be needed elsewhere and so the state would be moved higher. I removed your Button component because it wasn't doing much beyond the native <button> tag; I left Cell but it too could be removed -- Row could easily use <input> tags directly.
Hope this makes sense. Feel free to ask if anything's unclear. There are usually also people around in the #reactjs IRC room if you want to chat more about any of this.
I have been exploring ReactJS for the past week or so. My input to your question is asking a new question: why do you separate the Cell component from the Row and Grid components?
Coming from a Backbone background, Cell & Row & Grid makes sense, to have granular control over individual Cell Backbone.Views. However, it seems like that granular control & DOM update is what ReactJS tries to solve for you, which to me speaks for having a Grid component which implements a Row/Cell inside itself:
var Grid = React.createClass({
onChange: function(evt, field) {
this.props.data[field] = evt.target.value;
},
render: function () {
var rows = this.state.data.map(function (rowData, index) {
return (
<div className="row" key={index}>
<input value={rowData.name} onChange={this.onChange.bind(null, "name")} />
<input value={rowData.location} onChange={this.onChange.bind(null, "location")} />
<input value={rowData.phone} onChange={this.onChange.bind(null, "phone")} />
</div>
);
});
return <div className="table">
{rows}
</div>;
}
});
(Ignore the on*Change handling, room for improvement there. Untested code)
The question is, would you ever re-use Cell or Row as individual components elsewhere? To me the answer is a "very likely no". In which case my solution above makes sense, IMHO, and gets rid of the problem of passing data and changes up & down.
Another way to share data between sibling components when a parent component doesn't make sense is to use events between components. For example, you can use Backbone.Events, Node.js Emitter ported to the browser or any similar lib. You can even use Bacon.js if you prefer reactive streams. There's a great and simple example of combine Bacon.js and React.js here : http://joshbassett.info/2014/reactive-uis-with-react-and-bacon/