Ну вот, например, минималистичная, но вполне функциональная реализация фреймворка Servant на Хаскелле, в 81 строчке кода: http://www.well-typed.com/blog/2015/11/implementing-a-minimal-version-of-haskell-servant/

Elmworkshop на Reactiveconf. Сейчас

Скажите, как вы определяете Model, когда у вас большое приложение со множеством совершенно разных частей? Ну, допустим, у нас e-commerce marketplace, где есть витрина для клиентов, корзина, личный кабинет юзера со списком исполненных и исполняющихся заказов и его профилем, админка для продавцов, админка для администрации маркетплейса и т.д.

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

type alias Model =
    { ...
    , page : Page
    , ...
    }

type Page
    = PageDataIsNotFetched
    | LoadingPageData
    | Failure HttpError
    | ProductPage ProductModel
    | ListOfProductsPage ListOfProductsModel
    | UserPage UserModel
    | ...

А как делаете вы и почему именно так?

Либо так, либо можно вообще разделить модели на независимые и рисовать их в отдельных div'ах (у каждого div'а свой Model-View-Update)

Думается, что всё же на верхнем уровне модели будет таки рекорд - чтобы те же данные пользователя хранить, а уже в нем будет page, переключающая подмодели для страниц.

Разделить на независимые приложения, мне кажется, не самый удачный вариант. Вам все равно от приложения к приложению нужно таскать за собой как минимум userId, token и, для удобства, список ролей пользователя (Client, Admin, Vendor и т.д.). Можно, конечно, каждый раз записывать эти данные в local storage, а в новом приложении вытаскивать их оттуда, но это не решает всех проблем.

Разделять на независимые приложения удобно, когда они действительно независимые - на разных статических страницах показываются, например - но съэкономить на размере js-ки хочется :)

А вот отдельные куски, общающиеся через local storage - это реально странная затея :) Стейт должен быть явным. В LS его можно только сохранять для будущих сеансов.

Я бы сделал, как делают в redux: разделил Model на подобъекты и редиректил бы сообщения на эти подобъекты.

Ну как бы так и делают обычно - подмодели с подапдейтами по подсообщениям :)

Жалко, что FRP у нас отобрали. Можно было бы в отдельных foldp сливать подмодели с сообщениями, а потом всё каким-то образом мержить.

Но всё зависит от семантики: если приложение - страничное, то и модель верхнего уровня будет union'ом. А если просто хочется немного подекомпозить, то подмодели будут полями рекорда

Модель - юнион? Эээ? При переключении этого юниона всё состояние сбросится же.

Если данные всё равно подгружаются с сервера, то это хороший способ зафорсить обновление данных :)

А если надо состояние сохранять, то union + record

Но я бы, например, zipper сделал.

Логично. Способ обработать провал отравки состояния на сервер-то у нас есть?

Zipper над чем?