On Tuesday night I saw Travis Swicegood (center left) speak on Flux and Tim Tyrrell (center right) speak specifically on the views concept within Flux at Austin JavaScript. What is Flux? It is an architecture that Facebook uses in which data flows in one direction. In an AngularJS app there may be two way data data-binding, but there is none of that in Flux. Data flows from actions to dispatches to stores to views and then views may allow users to call out to actions such that the cycle recycles. In keeping with drawing a contrast to AngularJS, just as you might be told in a stereotypical what-is-Angular? orientation that the four concepts to understand are filters, services, directives, and controllers there are also four concepts to get your head around in Flux and I've just mentioned them too. Let's dig deeper. They are:
- actions
These are the events in your app, the click and/or double-click of a button and the like.
- dispatches
These keep track of everything that is happening. They are switchboard operators. What is supposed to be the reaction to an action on the code's part? ...and so on. It used to be that Flux, which is node-based, was only a concept, but now one may run...
npm install flux
...and actually get a skeleton for a Flux project! The code you will be given will be pretty sparse, but what there is to see will largely be in the shape of dispatches. The actions, stores, and views will be less fleshed out. This is a way to get started. Dispatches push data into the data stores and as much updates what users see in the views.
- stores
Keep data here. How they work and what shapes they take is left almost completely undefined in formal Flux dogma. Don't expect any guidance from the node package. It's not even true to say that stores have to be hydrated by something persistent beyond in-memory JavaScript state and to sync up against such an other service. At this other talk I did hear, before the talk started, a chunk of an intellectual discourse on whether it was wise to have just one store or many and in the case of many if child stores are updating a fat central parent what some of the challenges might be. Again, this is all up in the air and up to you. It seems like I might one day, after this all shakes out, go to a tech talk on the "right way" to do stores, but that isn't going to happen in 2015.
- views
The presentation layer in a Flux app is always going to be written in React.js. That is how views take shape. They may live non-intrusively in an existing page within an existing app. Tim somehow had... I dunno, a plugin for Google Chrome perhaps, which highlighted the areas which were React.js-driven in red at various web sites that used it and sometimes there would be a red box in a sidebar and sometimes there would red tint washing over the whole of a site. Go nuts as deeply or as little as you'd like. This is not all-chips-in gambling. Just use it where you want to use it. Again, in drawing a contrast to AngularJS, Tim suggested that he did not think it was wise to learn a very heavily-baked and do-things-our-way massive API for writing JavaScript, not given how quickly things change in the JS space. He has a history of slogging through jQuery taco hell (tacos are groupings of .js and .css files perhaps using something called JavascriptManager???) and would rather see you get your hands dirty than to be so "mature" that you're above playing in the mud. In React.js there are stateless components, smart components, and high order components, but I didn’t really take away from the talk what the distinction was between the three. Anyways, React.js is component-based. It's simple and declarative and easy to troubleshoot. Imagine, how in AngularJS how when something breaks and you try to step through the code to figure out what's up and you end up bouncing around in the thousands of lines of rat's nest that is Angular before things blow up and throw up an opaque unhelpful error message which cannot be googled. (All you can do in these scenarios is walk backwards from what you just did.) That shouldn't happen in the React.js space. Use webpack to wire up React.js. It's like browserify. index.js is the entry point for a React.js app. Some of Tim's code:
import React from 'react';
import Editor from './inlineEdit';
React.render(
<Editor text={false}/>,
document.getElementById('root')
);
I think the above is his index.js. The render above is going to put a component to the screen. It's going to call out to inlineEdit.js which will give you some text that you may then click to edit in a textarea. Pressing the escape key makes the editable area just copy again without saving your change and pressing return makes the editable area text again while retaining you change.
import React, { Component, PropTypes } from 'react';
import $ import 'jquery';
class InlineEdit extends Component {
constructor(props){
super(props);
}
state = {
editing: false,
text: this.props.text
}
static propTypes = {
text: PropTypes.string
}
static defaultProps = {
text "Some words"
}
_goToEditMode = () => {
this.setState({editing: true}, () => {
$(this.refs.editText.getDOMNode()).select();
});
}
_keyAction = (e) => {
if(e.keyCode === 27){
this.setState({editing: false});
} else if (e.keyCode === 13)
this.setState({editing: false, text: e.target.value});
}
}
render() {
if(this.state.editing){
return <input type="text"
defaultValue={this.props.text}
onKeyUp={this._keyAction}
ref='editText'
/>
} else {
return <div onDoubleClick={this._goToEditMode}>{this.props.text}</div>;
}
}
}
There might be something between ref='editText' ...and... /> above. I'm not sure. Tim coded on the fly and I took a bunch of pictures of it (it was projected on a screen) with my phone. What is above is what I've pieced together in looking back at the photos I took. You can see how he loops in jQuery as an external dependency. Also, the HTML-within-JavaScript craziness is JSX a JavaScript syntax extension that is kinda XMLesque.
Addendum 10/8/2015: TACO may actually reference Tools for Apache Cordova. I'm not sure.
No comments:
Post a Comment