mirror of
https://github.com/kay-is/react-from-zero.git
synced 2026-04-24 03:00:06 -04:00
107 lines
3.1 KiB
HTML
107 lines
3.1 KiB
HTML
<!doctype html>
|
|
|
|
<title>13 Element Refactor - React From Zero</title>
|
|
|
|
<script src="https://unpkg.com/react@16.4.0/umd/react.development.js"></script>
|
|
<script src="https://unpkg.com/react-dom@16.4.0/umd/react-dom.development.js"></script>
|
|
<script src="https://unpkg.com/create-react-class@15.6.3/create-react-class.js"></script>
|
|
<script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
|
|
|
|
<div id="app"></div>
|
|
|
|
<script type="text/babel">
|
|
// Refactoring an element is a bit more tricky
|
|
// First, casing of JSX determines whether a tag is an element or a
|
|
// component
|
|
// lower case means element
|
|
// upper case means component
|
|
|
|
var element = <div />;
|
|
// becomes
|
|
element = React.createElement("div", null);
|
|
|
|
try {
|
|
var component = <Div />;
|
|
// becomes
|
|
component = React.createElement(Div, null);
|
|
} catch (e) {}
|
|
|
|
// Second, React converts all events these elements trigger, to
|
|
// synthetic events. This is often no problem, they are simply events.
|
|
// But we can't trigger our own. So even if our <Input> component
|
|
// accepts an onClick callback as property, we can't call it with the
|
|
// same event as an <input> element would.
|
|
|
|
// One approach could be this.
|
|
// We simply implement our own onChange caller
|
|
// Here we create a number input that only calls onChange on numbers
|
|
// (non-numbers trigger an empty change)
|
|
var NumberInput = createReactClass({
|
|
getInitialState: function() {
|
|
return { value: "" };
|
|
},
|
|
|
|
handleInput: function(e) {
|
|
// we could try to modify the event to get our data in
|
|
// but this could mess things up
|
|
// instead we prevent this event from further actions
|
|
e.preventDefault();
|
|
|
|
var newNumber = e.target.value;
|
|
|
|
// filter empty-changes
|
|
if (newNumber.length < 1 || newNumber === this.state.value)
|
|
return;
|
|
|
|
this.setState({ value: newNumber });
|
|
|
|
// then we extract our data and give it to onChange
|
|
this.props.onChange(newNumber);
|
|
},
|
|
|
|
render: function() {
|
|
return (
|
|
<input
|
|
type="number"
|
|
value={this.state.value}
|
|
onChange={this.handleInput}
|
|
/>
|
|
);
|
|
}
|
|
});
|
|
|
|
function logChange(v) {
|
|
console.log(v);
|
|
}
|
|
|
|
// Here we see, that the new NumberInput has a different interface
|
|
// it's onChange property implies that events will be received, but
|
|
// this isn't the case. Also, even if we would want to call it like
|
|
// the original input, we would need to use upper case, and wouldn't
|
|
// win anything.
|
|
var reactElement = (
|
|
<div style={{ width: 300, margin: "auto" }}>
|
|
<h2>Logging number inputs</h2>
|
|
|
|
<h2>Before Refactor</h2>
|
|
<input
|
|
type="number"
|
|
onChange={function(e) {
|
|
logChange(e.target.value);
|
|
}}
|
|
/>
|
|
|
|
<h2>After Refactor</h2>
|
|
<NumberInput onChange={logChange} />
|
|
</div>
|
|
);
|
|
|
|
ReactDOM.render(reactElement, document.getElementById("app"));
|
|
|
|
// Other approaches include not using "default" prop names in the
|
|
// first place onUpdate instead of onChange. It could also happen that
|
|
// a component uses onMouseDown to do something internal and triggers
|
|
// an onChange, which could cause confusion. Often components deliver
|
|
// richer interactions than elements in the first place so their prop
|
|
// methods can reflect that with the name
|
|
</script> |