Effect

Еще один виток развития программиста и коммьюнити - понимание преимуществ описаний (конфигов) vs непосредственным исполнением.

Так появились JVM, .Net(CLR) для которых можно писать на Java/Scala/Kotlin, C#/F#/Q# и пр. Так произошло с фронтедом когда появился React - теперь мы пишем компоненты - описание разметки вместо jQuery лапши. Так, надеюсь произойдет и с js/ts с популяризацией Effect - экосистемы вокруг примитива-вычисления.

Effect - является описанием некоего вычисления, так же как фронтенд-компонен - описанием некой разметки.

Какие преимущества это дает?

Ну, например, мы можем иметь несколько интерпретаторов-исполнителей этих самых описаний:
- давайте рендерить компоненты на сервере, в браузере и нативно в телефонах
- давайте исполним Effect в различных js окружениях

Давайте сделаем наше "описание" объектом высшего порядка? Будем передавать в его в функции и другие "описания" и модифицировать поведение?
- slots, renderProps, HOC
- и тут Effect предлагает огромное множество возможностей - функции-кобинаторы для повторений (`repeat`) различных видов, ретраев (`retry`) со стратегиями, контролируемого параллельного исполнения, последовательного исполнения

Тайпскрипт дал строгую типизацию, но он не сохраняет ниформацию о выбрасываемых ошибках

try {
    throw 'Error'
} catch (x: unknown) {}

Фронтенд компоненты не сохранают информацию о требуемых контекстах (зависимостях) - об этом, обычно, узнают из ошибок в рантайме

Effect в свою очередь позиционирует себя как missing ts standard library, better ts - его модель решает проблему трекинга возможных ошибок и требуемых зависимостей

type Result<A, E> = 
| { type: 'ok' , ok : A } 
| { type: 'err', err: E };

type Effect<A, E, R> = (requirements: R) => Promise<Result<A, E>>

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

const andThan = (
from: Effect<A1, E1, R1>, 
next: (prev: A1) => Effect<A2, E2, R2>
): Effect<A2, E1 | E2, R1 | R2>

Результирующая программа также является эффектом - удобство в том, что интерпретатор (runtime) этой программы требует чтобы "канал" зависимостей был типа never - нашей программе должны быть предоставлены все зависимости перед исполнением.

В настоящий момент экосистема Effect достаточно богата и влючает:
- @effect/schema - более универсальный старший брат zod для декодирования за авторством gcanti
- @effect/cli - фреймворк для CLI
- effect-http - фреймворк для описания rest-api с последующей генерацией OpenAPI схемы, и конструирования типобезопасного клиента и сервера
- @effect/rpc @effect/rpc-http
- @effect/opentelemetry
- @effect/platform @effect/platform-node @effect/platform-bun @effect/platform-browser

Вышеописанное не полность покрывает фичи предоставлямые Effect, но это уже делает его многообещающим подарком комьюнити. Кроме того авторы проекта - крутейшая команда высококлассных специалистов.

Надеюсь Effect скоро станет новым стандартом разработки и призываю всех поставить на эту лошадку, пока он ней никто не знает. Это как повысит вышу конкурентноспособность в будущем, так и сделает ваш настоящий не-effect код лучше - потомучто вы просто не сможете писАть по старому.

https://effect.website/

Матералы:
- https://www.youtube.com/@effect-ts
- https://github.com/antoine-coulon/effect-introduction
- https://github.com/ethanniser/effect-workshop