React.scala.js?
Mar. 18th, 2015 05:42 pmGUI-компоненты это одно из редчайших мест, где classical OOP (мутабельная объектно-ориентированность с наследованием и типизированными интерфейсами) уместна, оправдана и полезна. Если честно, это не просто одно из редчайших мест, а "других таких мест я не знаю".*
Недавно (как я выяснил благодаря комментарию
bvlb) вышел React v0.13, где описания компонентов выглядят уже очень близко к тому, как мне кажется надо в идеальном мире:
* Кроме GUI-компонентов, ещё в Actor Systems наследование и типизированные интерфейсы полезны, но мутабельность там должна быть тщательно обёрнутая (в STM или монадки), то есть всё скальные радости (особенно миксин-наследование и cake pattern) там очень к месту, а вот необёрнутое состояние, т.е. "var"-поля, совершенно не к месту.
Во всех остальных известных мне местах требуются только иммутабельные структуры и работа с потоками/сигналами.
Недавно (как я выяснил благодаря комментарию
export class Counter extends React.Component {
constructor(props) {
super(props);
this.state = {count: props.initialCount};
}
tick() {
this.setState({count: this.state.count + 1});
}
render() {
return (
<div onClick={this.tick.bind(this)}>
Clicks: {this.state.count}
</div>
);
}
}Ещё лучше я могу себе это представить только на какой-нибудь слеюдущей версии Scala.js:
export class Counter(initialCount = 0) extends React.Component {
var count: Int = initialCount;
def tick() {
count = count + 1
}
renders {
<div onClick={tick()}>
Clicks: {count}
</div>
}
}Вот оно, вот оно где Scala-классы с их var'ами и валентностями к месту!* Кроме GUI-компонентов, ещё в Actor Systems наследование и типизированные интерфейсы полезны, но мутабельность там должна быть тщательно обёрнутая (в STM или монадки), то есть всё скальные радости (особенно миксин-наследование и cake pattern) там очень к месту, а вот необёрнутое состояние, т.е. "var"-поля, совершенно не к месту.
Во всех остальных известных мне местах требуются только иммутабельные структуры и работа с потоками/сигналами.