Editing a rich data structure in React.js - javascript

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/

Related

React adding child outside render()

The title could be clearer, but this is really the best I could come up with, sorry.
So, I am trying to create a filtered table component in React. However, I want the filter to be defined independently from the definition of the table itself. So, here is what I am doing.
I created a Filter component:
var Filter = React.createClass({
handleChange : function (value) {
this.props.updateTable(this.props.columnName,value);
},
render : function () {
//an input that will report its value to this.handleChange
}
});
Then, I create a Table component:
var Table = React.createClass({
filterChanged : function (column, value) {
//this will be wired as a updateTable prop for the Filter
},
render : function () {
//I am trying not to define a filter here,
//I am trying to use the previously-defined Filter component.
//I want the Table component to remain generic and re-usable,
//with optional filters.
var thisComponent = this;
//I can have as many filters as I want.
var filterToRender = React.Children.map(this.props.children, function (child) {
var filterUI;
if (child.type.displayName === 'Filter') {
filterUI = React.cloneElement(child, {updateTable : thisComponent.filterChanged});
}
return (<div>{filterUI}</div>);
});
//along with the rest of the table UI,
return (<div>
<table>bla bla</table>
{filterToRender}
</div>);
}
});
Then, in my main page, I render it like this:
ReactDOM.render( (<Table>
<Filter columnName='status'></Filter>
</Table>), document.getElementById('appHolder'));
It renders fine. The change functions also seem to be wired fine. However, I find that every time the filter value is changed, it triggers the Table's filterChanged method, increasing number of times. First change, it will trigger 2 times; second change, 6 times; 3rd change, 14 times.
Weird and uncanny. What am I doing wrong here?
The above procedure for doing things is correct as far as React is concerned. The bug I was getting was due to another framework (Materialize) that uses a jquery plugin to initialize some components. Since it mutates the DOM, I need to manually make sure the onChange events are properly attached to the right node.
Fwiw, I was attaching the onChange to this.handleChange in a drop-down list in the ComponentDidMount and ComponentDidUpdate of the Filter component. Removing initialization from ComponentDidUpdate, solved the problem. This, because multiple instances of handleChange were being bound to the onChange event each time the component updated.

_React Js one page application

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.

React.js properties

I am currently going through the documentation of React.js and have a question about this.props, which according to the docs should be considered immutable and only pushed downwards down the ownership tree since bubbling custom events upwards is discouraged.
Say that I have a UI where the state of a component in the header of the page should be shared with another component that is nested somewhere in the body of the page, let's take a simple checkbox that represents some specific state that will influence the visibility of some nested spans or divs.
The only I way I currently see this achieved is by creating a state property that is pushed downwards from the top element to the child elements.
The two related questions I have with this is:
Does this mean that I should create one component that owns the entire page? (Is rendering the entire page with a single owner component an acceptable thing to do? I understand the concepts of Virtual DOM and diffing so I assume it's not a problem, still I'd like some confirmation in case I miss out on something relevant);
Is it ok to change the property on this.props when clicking the checkbox, in order to re-render the other components on the page? This doesn't make the props immutable (perhaps they mean just that setting new props on this.props down the chain is not accepted to avoid an untransparent stack trace in case of bugs, but changing the value of a state property is?).
Some confirmation would be appreciated.
Thanks.
1) It is fine to have one parent for the whole page, but is not always necessary. It depends on if it is necessary to share the state between components.
2) You never want to alter props via this.props.someValue = newValue. If you need to modify the parent state from a child component, it should always be done with a callback. The example below shows how to share the checkbox state between multiple components using the callback function handleClick to modify the state of is_checked.
JSFiddle of example: https://jsfiddle.net/mark1z/o7noph4y/
var Parent = React.createClass({
getInitialState: function(){
return ({is_checked: 0})
},
handleClick: function(){
this.setState({is_checked: !this.state.is_checked})
},
render: function(){
return (
<div>
<CheckBox is_checked={this.state.is_checked} handleClick={this.handleClick}/>
<OtherComponent is_checked={this.state.is_checked} />
</div>
);
}
});
var CheckBox = React.createClass({
render: function() {
return (
<input type="checkbox" onChange={this.props.handleClick}> Show other component </input>
);
}
});
var OtherComponent = React.createClass({
render: function() {
return (
<div style={{marginTop: 20}}>
{this.props.is_checked ? 'The checkbox is ticked' : 'The checkbox is not ticked'}
</div>
);
}
});
React.render(<Parent />, document.getElementById('container'));
I guess having one master component isn't an issue. The docs suggest that you find the topmost component that can supply it's children with the needed data - and this could easily be the toplevel master component. As I understand this you would have a master component for your main page - that should be the only one that uses state, the children just render what they are given in props. So no, props should not be altered by a child that doesn't own the data, it is the topmost components prerogative to do so. Let's say you have another widget on the page that only cares for a distinct set of data you would make this the root of another tree that fetches data and sets it's state and the props of it's children.
Here is a crappy graph for this situation:
App -(props)-> ItemList -(props)-> Item -(props)-> Photo
+ + |
+ ++++++++++ |----(props)-> LikeButton
+ + |
(fetch) + |
+ + * ---(props)-> Description
++(setState)++
Widget -(props)-> Whether
However it gets more interesting when facebook's graphql is finalized and every component can declare the needed data on it's own, I'm looking forward to it. But until then the toplevel component has to know which data every child needs and all the parent nodes need to hand this data down.

In React JS, when should you use a store vs directly manipulating the view's state?

Now I understand the concept of stores as the source of truth for a React app, but it seems that sometimes using stores is overkill, especially in UI-only situations.
For example, say I'm making an app which contains a list of movies. The app contains a search bar which lets you filter these movies according to their title. Should the value of this search bar (let's call it searchTerm) be contained in a store? Its only impact is on the list of movies shown, which is purely a UI feature. It won't be sent to the server or saved to local storage. So in my handleTextChange function, should I alert a store, or simply set the component's state:
Should it be this (using a store):
var Actions = Reflux.createActions([
"searchChanged"
]);
var Store = Reflux.createStore({
listenables: [Actions],
getInitialState: function () {
return data;
},
onSearchChanged: function (searchTerm) {
this.trigger(data.filter(function (el) {
return el.name.toLowerCase().indexOf(searchTerm.toLowerCase()) != -1;
}));
}
});
var View = React.createClass({
mixins: [Reflux.connect(Store, "movies")],
handleTextChange: function (e) {
Actions.searchChanged(e.target.value);
},
render: function(){
//Render here. Somewhere there is this input element:
<input onChange={this.handleTextChange} type="text"/>
}
)};
or this (not using a store):
var Store = Reflux.createStore({
getInitialState: function () {
return data;
},
});
var View = React.createClass({
mixins: [Reflux.connect(Store, "movies")],
handleTextChange: function (e) {
this.setState({searchTerm: e.target.value});
},
render: function(){
var filtered = this.movies.filter(function (el) {
return el.name.toLowerCase().indexOf(this.state.searchTerm.toLowerCase()) != -1;
});
//Render here using the filtered variable. Somewhere there is this input element:
<input onChange={this.handleTextChange} type="text"/>
}
}
The latter example is obviously simpler. Is there a good reason to use a store to filter the data? Or should the view have a searchTerm variable and perform the filtering in the render() function?
As your examples indicate, not using a store is simpler, and arguably correct in this case.
A weak question to answer is:
Does any other component need to know about the search results?
A better question is:
Might some other component need to know about the search results?
Consider that if you add paging through results, or even a simple header of "12 results found", then those components need to know the result and will need to get it from the store. Or perhaps you'll want to add a router and have the search update the url and the url change to drive the app.
If you can say for certain that ONLY subcomponents will ever care about a value, then state is OK.
Both approaches are correct! But for your situation, filtering in component is better. Because searching result is calculable. The store should just keep the original data. The book "Developing the React edge" has an example for filterableForm, keep the search keyword in the view component is perfectly fine.

React component loading pattern (or anti-pattern?)

I've recently started using ReactJS in my UI projects which has greatly simplified my UI workflow. Really enjoyable API to work with.
I've noticed recently that I've had to use a pattern in a couple of my projects that needed to aggregate data on a page. This data would live in the DOM and not be dependent on using the React state for data transitions.
This is an example implementation:
var Component = module.exports = React.createClass({
componentDidMount: function() {
this.component = new Component();
this.component.start();
},
componentWillUnmount: function(prevProps, prevState) {
if (this.component !== undefined) {
this.component.destroy();
}
},
render: function() {
return (
<div id="componentContainer"></div>
);
}
});
var Component = function(){
// Some object that dynamically loads content in a
// pre-packaged NON-react component into componentContainer
// such as a library that renders a graph, or a data loader
// that aggregates DOM elements using an infinite scroll
}
My question is whether or not this is the proper way to aggregate data into the DOM using React. I looked around for the idiomatic way of doing this, but my google-foo was unable to come up with anything.
Thanks!
EDIT - as a side note, does anyone think there will be a problem with the way I destroy the container, using the componentWillUnmount?
The main problem is that you're using an id, which is inflexible and makes assumptions about the rest of the components (because ids must be globally unique).
module.exports = React.createClass({
componentDidMount: function() {
// pass a DOM node to the constructor instead of it using an id
this.component = new Component(this.getDOMNode());
this.component.start();
},
componentWillUnmount: function() {
this.component.destroy();
},
render: function() {
return <div />;
}
});
Your componentWillUnmount was fine, but the one place you set this.component will always run before componentWillUnmount, and there's no other reason it'd be assigned/deleted, so the if statement isn't needed.
Also the arguments both weren't used, and aren't provided to componentWillUnmount. That signature belongs to componentDidUpdate.

Categories