Формулировка про годы опыта в вакансии обычно подразумевает именно продакшен использование в какой-то компании. Я бы на вашем месте заменил на конкретное описание, что ожидается от кандидата, как выше в чате прозвучало: язык, паттерны, платформа.

А слак эльма жив весьма. По крайней мере с вопросами и трудностями как помогали там, так и помогают

ладно, давайте накидаю:
@kana_sama сегодня как-то сказал что в елм в отличие от редакса апдейт плосские (а не иерархический) - имеет ли это место быть или это просто потому что такие примеры в документации?
2. в док-ции есть пример композиции из архитектур, ну там вроде приводился виджет каунтер - так кто-нибудь делает? (всё таки там не рекомендуется так делать)
3. если ответ на второй пункт – нет, то как быть в случае если ваш СПА многостраничный? то есть между страницами шарится по минимуму модель и экшоны?

ок, спасибо, поменяю

Имеет место быть, потому что тип сообщений обычно делают плоской. С вложенными редьюсерами пришлось бы писать много _ -> кейсов.

Хоть при разбиении проекта на фичи делают вложенные сообщения, типа, TasksMessage (AddTask "new"), главный апдейтер достает AddTask и отдает его в апдейтер фичи

Культуры "редьюсер на каждое поле" нет, так как теряется проверка кейса на тотальность

2. Иногда да, для некоторой части приложения подходит «фрактальная» архитектура
3. Видел примеры, где для многостраничности как раз используется очень тупое приложение верхнего уровня, содержащее по сути только роутинг, а страницы - самостоятельные приложения, которые из верхнего инициализируются по необходимости.

> проверка кейса на тотальность
в каком смысле?

собственно у нас так и сделано

главный модуль занимается роутингом и обработкой url, а под страницы уже отдельные модули

Я писал, приходиться писать

type Message = A | B | C

updateX msg model =
  case msg of
    A -> 1
    B -> 2
    _ -> model

updateY msg model =
  case msg of
    B -> 1
    C -> 2
    _ -> model

update msg model =
  { x = updateX msg model.x
  , y = updateY msg model.y
  }

Собственно из-за _ -> model мы теряем профит от того, что компилятор показывает нам, что мы обрабатали не все ветки кейса, а это мощная фишка

Это можно решить, делая сообщения вложенными

type MessageX = A | B
type MessageY = B' | C
type Message = ForX MessageX | ForY MessageY

Но теряется возможность использования экшона в двух редьюсерах. Ну так для отдельных фич и делают

на самом деле неочевидный пример
более жизненно как ты во втором случае написал

сложности начинаются когда между двумя страницами есть переиспользуемая вьюха

Просто если у нас 5 слоев редьюсеров, то это ад. Поэтому я чаще видел, что апдейтер плоский, и апдейты там адовые, обновлять вложенные структуры не очень красиво, а линзы очень бойлерплейтные

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

Переиспользуемая вьюха может возвращать абстрактный Html msg, и в качестве конфига принимать функции типа String -> msg для использования в обработчиках событий

почему string?

просто пример

я например в собственных модалках использую
view : Modal msg -> List (Html msg) -> Html msg
где у Modal есть поле toMsg : ModalState -> msg

по сути это тот же Html.map только прописанный в конфиге а не в апдейте