Simonium Mar 24 2021 at 10:58

Еще один подход к построению архитектуры на фронте

11 min

9.3K

JavaScript*ReactJS*TypeScript*ООP*Website development*

From sandbox

Technotext 2021

Comments 20

Argnist88 Mar 24 2021 at 12:00

Было бы неплохо увидеть аналогичные примеры для Angular и Vue.

Simonium Mar 24 2021 at 17:24

Эту архитектуру можно во Vue интегрировать по аналогии с React. Для этого подписка может быть в методе created, а отписка от изменений beforeDestroy. Сами сервисы можно передавать через метод provide по аналогии с контекстом.
По Angular написать не могу, так как опыта с ним не имел.

mayorovp Mar 24 2021 at 13:45

Не нравится мне ваш интерфейс Emmitable, потому что для него невозможно создать легковесную проекцию или фильтр:

class Foo {
    constructor(private bar: Bar) {}
    on(event: …, cb: …) {
        this.bar.on(event, e => cb(e.baz));
    }
    off(event: …, cb: …) {
        this.bar.off(event, ???);
    }
}

Ну и плюс метод emit тут совершенно лишний, не дело выставлять генерацию событий наружу.

Предлагаю рассмотреть следующий интерфейс:

interface Emmitable<E> {
    on<K extends keyof E>(event: K, cb: (event: E[K]) => void): () => void;
}

Ну или вот так, если не нравятся ничего не говорящие типы-функции:

interface EventSubscription {
    off(): void;
}

interface Emmitable<E> {
    on<K extends keyof E>(event: K, cb: (event: E[K]) => void): EventSubscription;
}

Simonium Mar 24 2021 at 17:35

Можно сделать интерфейс:

interface Eventable<E> {
    on<K extends keyof E>(event: K, cb: (event: E[K]) => void): void;
    off<K extends keyof E>(event: K, cb: (event: E[K]) => void): void;
}

Который будут реализовывать сервисы, а само управление подписками вынести в отдельный класс Emitter, который будет через композицию использоваться в сервисах:

interface NoteEvents {
    change: undefined;
}

class NoteService implements Eventable<NoteEvents > {
    emitter = new Emitter<NoteEvents>();

    on<K extends keyof E>(event: K, cb: (event: E[K]) => void): void {
        this.emitter.on(event, cb);
    }

    off<K extends keyof E>(event: K, cb: (event: E[K]) => void): void {
        this.emitter.off(event, cb);
    }
}

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

DmitryITWorksMakarov Mar 25 2021 at 08:31

В целом всё понравилось, но вот в конце когда мы в реакт контекстом передаём сервисы. Это такой ServiceLocator получается со всеми вытекающими. React context средство мощное, но я бы с помощью его бизнес логику внутрь реакта не заносил.
Чтобы уменьшить связанность, стоит связывать вызовы реакта с сервисами где-то на уровне монтирования, ну или через посредника/диспетчера/шину событий.

С другой стороны, если это сделано осознанно, как компромисс, то почему бы и нет. Архитектура всегда лучше хаоса.

mayorovp Mar 25 2021 at 12:02

ну или через посредника/диспетчера/шину событий

Но это же ещё хуже, чем ServiceLocator…

Кстати, ServiceLocator у автора не простой, а типизированный: там перечислены все возможные сервисы. Такой подход всё ещё не помогает выделять изолированные компоненты, но хотя бы помогает избежать ситуации "компонент запрашивает несуществующий сервис".