Не большой спец. Вроде, это единственный способ вернуть infer-значение. Говорю ж, наощупь всё.

ладно, тоже попробую пощупать :)
спасибо за инфу

Эта строчка говорит что если какое-то T расширяет ридабл от U то тип равен U иначе T

Соответственно StoreValue<Readable<object>> это просто object, а StoreValue<object> тоже просто object =)

оно работает с нюансами только в случае T extends A | B | C ? ... : ... и всяких T extends any , T extends never

Всем доброго вечера!
Поделитесь мудростью, а лучше шаблончиком, дружбы Svelte и Redux.
При условии что SPA модульное - динамически подгружаются не только компоненты, но и бизнес-логика.
И соответственно, store должен все подхватывать... reducers должен пухнуть, а возможно, и middleware то же.
У меня уже каша в голове. 8й раз переписываю проект, и не могу добиться красивого результата.

Да, я это понимаю. Я скорее о том, что я не очень шарю в деталях синтаксиса.

Использование редакса — это легаси-требование или осознанный выбор?

Осознанный выбор. Кусочек SPA - карта. На карте куча слоев. Составом и отображением слоев нужно управлять. Слои могут отображать данные из системы или из стороннего источника. Данные в слоях можно редактировать. Объекты в слоях имеют атрибутивную информацию, по которой нужно строить тематику (делать визуальную аналитику). Атрибутивная информация может браться как из системы, так и с внешних серверов. Могут динамически подгружаться модули провайдеров данных для слоев, или расширяющие или изменяющие работу базовых модулей.

Выходит очень сложный поток данных, который сложно контролировать.
Поэтому как средство централизации хранения данных и управления бизнес-логикой была выбрана архитектура Flux.
Свой велосипед изобретать не хочется, поэтому среди не привязанных к фреймверкам решений выбрали Redux.

а свелт вам зачем тогда?

начальство заставило? ;)

Нет, vanilla js уже проходили
Тяжелую артиллерию в виде Angular то же
Svelte - компонентный фреймверк, удобно разрабатывать модульные решения

пока звучит страшно 😱

Svelte Store конечно отличная вещь, но они не позволяют однозначно организовать однонаправленный предсказуемый поток данных.
Redux это решает, и даже дружит со Svelte через svelte3-redux, в результате чего получается все тот же Svelte Store и компоненты заводятся с полпинка.

Подгрузка и, местами, замена компонентов решается через <svelte:component> и контейнер не связанный с Redux - тут все отлично.

Но буксую на Redux, так как через него должно идти все - и регистрация компонентов Svelte, и расширение безнес-логики.
Через сам Redux можно расширять Redux Store, через добавление новых корневых элементов со своим обработчиком Actions - reducer. Но reducer, согласно концепции Redux чистые функции, и лишь изменяют Redux Store на основании предыдущего состояния стора и пришедших с Action данных. Нужны ещё запросы к серверу, обработка данных или выполнение команд модулями, что решается через middleware, в частности redux-saga.

По отдельности все вроде бы понятно и красиво, но в совокупности... карточный домик в какой-то момент рушится вместо того что бы взмыть в воздух и засиять под эпическую музыку

я думаю большинство присутствующих согласятся, что идеологически редукс - это не svelte way.  тут ценится чтобы было меньше бойлерплейта и быстрее работало.
любой однонаправленный dataflow можно выразить в виде derived store.  
если сильно хочется отвязать dataflow от свелта, то технически возможно его использовать с какими-нибудь observable библиотеками: modx, rxjs и так далее.

а для чего там infer U ?
спс за инфу :)