Pull to refresh
20
0
Руслан Лопатин @lorus

Программист

Send message

Вот тут предлагают публиковать type definitions рядом с кодом, через MF: https://spin.atomicobject.com/2022/07/19/typescript-federated-modules/

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

Микрофронт != MF.
Там делов сделать сборку на том же Rollup - вообще мизер. Не вижу проблем вообще.

В данном случае лучше монорепозиторий, а не две отдельные репы.

Ещё можно публиковать собранные пакеты в NPM (приватно). Поддерживается GitHub. Или можно поднять копоративный Verdaccio. Но монорепозиторий проще.

Я не работаю с module federation. А с чудовищем WebPack завязал лет 10 назад. Отсюда непонимание.

Вот сделали мы хостовое и дочерние приложения. Они должны собираться одновременно или порознь? Они должны как-то видеть настройки сборки друг друга?

Тут я вижу два варианта:

  1. Приложения собираются независимо. Значит хостовое приложение - просто CDN, который хостит разделяемые модули. Но это легко реализуется без module federation.

  2. Приложения собираются вместе и хостовое приложение делает tree-shaking, например, и хостит только те части кода (чанки), которые реально используется приложениями. Но, во-первых, это опять-же реализуется без использования module federation. Достаточно всю сборку делегировать в хостовое приложение. А во-вторых, как быть с развёртыванием? Ведь если обновить дочернее приложение, но не обновить хостовое (или наоборот), то приложение просто сломается. То есть обновлять их нужно одновременно, что "не очень", мягко говоря.

Я чего-то недопонимаю, наверное.

Эммм, package.json dependencies + import?

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

const getValue = withMemo(
  async () => ({ done: true, value: await someVeryLongOperation() }),
  { defaultValue: { done: false, value: undefined } },
);

Ещё проще, чтобы стала понятна проблема:

const getValue = withMemo(() => getValue());

Вычисленное значение попадает в кеш, очевидно, только после того, как завершится вычисление. Но рекурсивный вызов происходит во время вычисления. То есть значения в кеше ещё нет. Значит вызов произойдёт снова, и снова, и снова...

Утрирую:

const getValue1 = withMemo(() => getValue2() - 1);
const getValue2 = withMemo(() => getValue1() + 1);

getValue1(); // Бесконечная рекурсия.

В случае с промисами будет не бесконечная рекурсия с ошибкой, а бесконечное ожидание, что ещё хуже.
Я о том, вообще-то, что для разрешения таких ситуаций тоже можно придумывать различные стратегии.

К своему стыду, упустил этот раздел.
Но, после прочтения, вопрос всё-же остался.
Что если рекурсивное обращение произошло до того, как результат попал в кеш?

А чем это лучше продуманного разделения приложения на модули? Или это для тех, кто не смог?

А если рекурсия? То есть функция запросит мемоизированное значение прямо или опосредованно? Вполне себе вариант в сложных случаях отложенных вычислений

А вот после 15 лет на удалёнке вернуться в офис, кажется, не такая уж и плохая идея. Хотя бы ради общения. Потому что, да: «Как бы это ни выглядело на первый взгляд, проблема всегда в людях»

Cap'n proto не рассматривали? Вроде бы от одного из авторов Protobuf. Как работа над ошибками. Позиционируется как самый быстрый сериализатор.

А почему вы не используете бандлер? Он бы решил проблемы с импортами без всяких регулярных выражений.

Зато в СССР был Квейсик. И отличался он от Бейсика... типами! И компилятором.

Ничто не ново под луной.

Но вот про импорты не помню.

В пределах одного пакета вполне можно писать вот так:

import { UserService } from '../users';

class UserController {
    constructor(private readonly userService: UserService) {}
}

Достаточно добавить ../users/index.ts с содержанием типа:

export * from './user';
export * from './user.service';
// etc

...и не использовать default export.

Ну и, как выше уже писали, IDE вполне способна сама сгенерировать import для вас. Не нужно делать это руками. Вы ведь в Java вручную import не пишете? Это просто потеря времени.

Вот так, на пустом месте, вместо легковесного потока исполнения поднять Docker, образ OS, ещё один экземпляр Node.js, связать это всё сокетами вместо прямой пересылки сообщений... Облачные провайдеры любят вас.

Вопрос был о втором. О значениях свойств.


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


Более того, не очевидны преимущества перед представлением подобного в императивном стиле. Т.е. в виде метода или свойства, возвращающего словарь.


То есть вся "магия" — в преобразовании (транспиляции) декларативной функции в специфическом синтаксисе — в обычную, выполняющую перебор?

В текущем представлении все возможные комбинации описаны в одном месте. Если связь один — к одному, то это представлено в виде множества объектов (словаря) с правой стороны.


Но если арность выше, то что справа — словарь словарей? Для всех возможных комбинаций?

Information

Rating
Does not participate
Location
Томск, Томская обл., Россия
Registered
Activity

Specialization

Backend Developer, Fullstack Developer
Middle
From 5,000 $
TypeScript
Node.js
Web development