Как стать автором
Обновить

Комментарии 34

В методе render() не следует изменять состояние компонента (даже с использованием setState), выполнять HTTP-запросы. Не обращайтесь из этого метода к jQuery, не выполняйте запросы на загрузку неких данных.


Кто-то использует React с jQuery???
Как минимум, при постепенной миграции с jQuery на React они вполне могут какое-то (потенциально неограниченное) время сосуществовать.
Я. И очень много людей сидящих на плагинах с jquery за основу.
Пока составлялось это руководство, componentWillUpdate() и componentWillMount() успели уйти в UNSAFE :{
Пока составлялось это руководство классовые компоненты с жизненным циклом по-тихоньку уходят в «UNSAFE» с ноября прошлого года
Думаю, для HOC, аггрегирующих большое количество других компонент в себе, чтобы не утонуть в useState/useEffect/useCallback полотнах, все же будут использоваться компоненты с их жизненными циклами

Я бы не согласился. Теперь стало наоборот проще в рамках функционального компонента с хуками избавиться от спагетти-кода и изолировать независимый код друг от друга в одном компоненте.

Говорить, что они уходят в UNSAFE неправильно, ибо их не депрекейтили и пока даже не планируют.

Задепрекейчены только componentWill{Mount,ReceiveProps,Update}, классы никуда не уходят.

Только сейчас доехал о смысле поста, на который отвечал. Конечно, классы никуда не уходят и не уйдут в ближайшее время)
Метод render() всегда должен оставаться чистой функцией

Судя по отсутствию аргументов эта функция должна всегда давать один и тот же результат, независимо от стейта.

this — тоже как бы аргумент, и чистые методы вполне могут к нему обращаться.

Только, если этот this будет иммутабельным, что, очевидно, бесполезно.

Эдак надо требовать, чтобы любой переданный в чистую функцию объект был иммутабельным, чего никто обычно не делает.


Обычно всё-таки считается достаточным чтобы функция не изменяла this сама, и возвращала то же самое значение при том условии, что this не изменил никто другой.

Так я и не спорю. Вот только в определении присутствует понятие "одинаковости", которое можно понимать разными способами.


Так вот, если потребовать ссылочной эквивалентности, то окажется что даже простейшая функция вроде x => [x] не является чистой, из-за чего определение становится практически бесполезным.


А вот если потребовать эквивалентность структурную, то выходит, что мутабельный объект, взятый в разные моменты времени, не является эквивалентным самому себе — а потому совсем не мешает чистоте функции.

А ещё можно пофантазировать о том, что Math.random() — тоже чистая функция, так как между разными вызовами Math — это структурно разные объекты.

Нет, нельзя, потому что Math — пространство имён, а не полноценный объект; у Math нет состояния.


И даже если бы у Math было состояние — Math.random его менял бы.

Что вы, выражение this.x += 1 — ничего не меняет, это же просто синтаксический сахар для создания нового this, который неявно возращается нашей безусловно чистой функцией.

Вот как раз "неявный возврат значения" и называется побочным эффектом.

НЛО прилетело и опубликовало эту надпись здесь

Давайте зайдём с другой стороны. Вот у нас есть функция render():


render() {
    return <span>count = {this.state.count}</span>
}

У нас же javascript, и мы её всегда можем вызвать вот так:


render.call(Object.freeze({
    state: Object.freeze({
        count: 5,
    }),
}));

При таком вызове мешает ли что-то считаться функции чистой?

Object.defineProperty(Object, 'freeze', {
  enumerable: false,
  configurable: false,
  writable: false,
  value: () => alert("hola")
});

а при таком коде мешает ли что-то считаться функции, описанной выше, чистой?)

Я вот недавно рассказывал людям, что «теплый ламповый» реакт с классами и методами — это как геоцентрическая вселенная Птолемея с эпициклами, а хуки — это как гелиоцентрическая система Коперника. Известно, что если взять предел по всем эпициклам Птолемея, то результат получится точно таким же, как у Коперника (и совпадет с наблюдаемым миром). Но только коперниковская система неизмеримо проще и логичнее.


Точно так же и с хуками: магическим образом от трети до половины кода просто исчезает при рефакторинге с классов на хуки. Это какой-то очень фундаментальный закон мироздания был открыт.


Так что нет тут никакого «используете ли вы хуки». Есть «весь ли код вы уже перевели на хуки, или пока еще в процессе».

А сколько кода исчезнет при переходе с React на $mol...

Сколько?

Половина так точно.
https://github.com/eigenmethod/todomvc/blob/master/examples/react/js — 10KB
https://github.com/eigenmethod/todomvc/blob/master/examples/mol — 5.5KB


Ну вот взять в пример использование глупого компонента:


<TodoItem
    key={todo.id}
    todo={todo}
    editing={this.state.editing === todo.id}
    onToggle={this.toggle.bind(this, todo)}
    onDestroy={this.destroy.bind(this, todo)}
    onEdit={this.edit.bind(this, todo)}
    onSave={this.save.bind(this, todo)}
    onCancel={this.cancel}
/>

Аналог на $mol:


Item!id $my_todo_row
    todo?val <=> todo!id?val
    editing?val <=> todo_editing!id?val

Ну или, что то же самое:


@ $mol_mem
Item( id : string ) {
    return $my_todo_row.make({
        todo : val => this.todo( id , val ) ,
        editing : val => this.todo_editing( id , val ) ,
    })
})

Не знаком глубоко с $mol, но выглядит так, будто в react версии есть всякие onSave, onCancel, в $mol версии такого не вижу

Потому что они для реализации той же функциональности не нужны.


Вместо onSave этот компонент дёргает this.todo({ completed , title }), а вместо onCancelthis.editing( false ).


Благодаря двусторонним каналам API компонента получается гораздо проще, без 100500 колбэков для управления им.

С таким же успехом можно запихнуть все данные и callback'и в один объект и передать в react компонент и сократить все до:
<TodoItem todo={todoGodObject} />
Ваш пример на самом_лучшем_фреймворке ничем не лучше такого подхода.

От того, что вы часть кода переложите из одного места в другое, его меньше не станет. Скорее даже наоборот.

С одной стороны я с вами соглашусь — на хуках код писать удобнее и проще. Но кидаться переписывать рабочий код я бы не стал — мало ли что там пойдёт не так. Работает — и пусть работает.

Уточнение: проста и логична система Кеплера, которая с эллипсами. А у Коперника, при попытках натянуть его систему на реальные наблюдаемые данные, получались всё те же эпициклы.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий