Комментарии 7
С моей точки зрения, стало сложнее.
1. Вы стали описывать типы пропертей компонента в нескольких местах (копипаст)
2. Теперь у вас есть метод render() внутри самого React-компонента и есть еще какой-то коллбек render(args) для connectRxProps
3. compose со последующим запутанным куском кода – лишь все усложняет, и это для тривиального примера, что будет, если пример будет более сложным?
4. Теперь у вас в коде компонента есть 2 способа изменить состояние этого компонента: this.setState и render( state )
ps: в последнем примере вы потеряли пропертю loading
1. Вы стали описывать типы пропертей компонента в нескольких местах (копипаст)
2. Теперь у вас есть метод render() внутри самого React-компонента и есть еще какой-то коллбек render(args) для connectRxProps
3. compose со последующим запутанным куском кода – лишь все усложняет, и это для тривиального примера, что будет, если пример будет более сложным?
4. Теперь у вас в коде компонента есть 2 способа изменить состояние этого компонента: this.setState и render( state )
ps: в последнем примере вы потеряли пропертю loading
+1
1. Это не обязательно
2. Ну не какой то, а описаный в API. Очень часто API какие то вещи добавляет
3. compose достаточно популярная библиотека, что бы кого то запутать. Запутанный дальнейший код является таковым только пока вы мало работали с Observables
4. Ну их всегда было два: изменить props или state. С учетом, что мы получили stateless компонент — смысл делать setState утрачен.
5. loading не потерян — он передается через props
2. Ну не какой то, а описаный в API. Очень часто API какие то вещи добавляет
3. compose достаточно популярная библиотека, что бы кого то запутать. Запутанный дальнейший код является таковым только пока вы мало работали с Observables
4. Ну их всегда было два: изменить props или state. С учетом, что мы получили stateless компонент — смысл делать setState утрачен.
5. loading не потерян — он передается через props
0
Может лучше Angular использовать? Он и с rxJs дружит, и сервисы есть, чтоб подобные вещи из компонента выносить.
0
React тоже отлично с ним дружит, просто это не столь популярно. Предлагать заменить React на Angular для внедрения RxJs — это достаточно кардинальные меры, не говоря о вкусах людей.
+1
Не столь важно React или Angular, но RxJs для фронтенда, действительно, более удобный чем Redux/Flux/etc., потому что он позволяет работать с классическими моделями предметной области. Реактивные потоки использовались в dojo начиная еще с 2010 года (кстати, dojo2 тоже собирается переходить на RxJs). Безусловно, Redux/Flux имеет право на существование, но фронтенд — не совсем то место, где разновидности реализаций «Event Sourcing» паттерна могут полноценно проявить свои достоинства.
0
Не спора ради, чисто для сравнения то же самое на SvelteJS:
Реализацию calculateFibonacci опустил, потому что она вобщем-то роли не играет, но предполагается что она возвращает промис, а не принимает коллбек как в статье.
Поиграться можно тут.
Fibonacci.html
<div class="{{className}}">
{{#await fibonacci}}
Loading...
{{then result}}
Fibonacci of {{value}} = {{result}}
{{/await}}
</div>
<script>
import calculateFibonacci from './calculateFibonacci';
export default {
data: () => ({
className: '',
useServerCall: false,
value: 0,
fibonacci: 0
}),
oncreate() {
const observer = this.observe('value', (value) => {
let fibonacci = calculateFibonacci(value, this.get('useServerCall'));
this.set({ fibonacci });
});
this.on( 'destroy', () => observer.cancel());
}
};
</script>
Реализацию calculateFibonacci опустил, потому что она вобщем-то роли не играет, но предполагается что она возвращает промис, а не принимает коллбек как в статье.
Поиграться можно тут.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Упрощаем ReactJS компоненты с помощью RxJs