Согласитесь, соблюдать баланс читабельности кода и производительности нужно. Автор привёл весьма удачный пример с useEffect: кейс когда значение одного useState зависит от значения другого useState и синхронизация происходит через useEffect -- действительно ест лишнее процессорное время и память. Так же, произвести все вычисления стейтов в одном месте (в reduce) и не размазывать логику по useEffect'ам -- должно быть "читабельнее" || "снижать когнитивную нагрузку" || "упрощать дебаг". К тому же Дэн Абрамов не отменяет useReducer.
Респект. Тоже занимался линзами недавно в своей библиотеке `@codeleaf-sdk/core`
Что могу заметить: сложновато пока соблюсти строгую типизацию линз в TypeScript.
И вам спасибо, поправил. :)
Спасибо, поправил ссылку. :)
Согласитесь, соблюдать баланс читабельности кода и производительности нужно. Автор привёл весьма удачный пример с useEffect: кейс когда значение одного useState зависит от значения другого useState и синхронизация происходит через useEffect -- действительно ест лишнее процессорное время и память. Так же, произвести все вычисления стейтов в одном месте (в reduce) и не размазывать логику по useEffect'ам -- должно быть "читабельнее" || "снижать когнитивную нагрузку" || "упрощать дебаг". К тому же Дэн Абрамов не отменяет useReducer.
Что могу заметить: сложновато пока соблюсти строгую типизацию линз в TypeScript.