Создание структуры данных в Elm

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

Сегодня, законспектируем доклад «Make Data Structures» by Richard Feldman

Ричард работал над редактором для написания книги. В докладе он рассказывает о советах, которые бы он дал себе «прошлому». То есть, какие уроки он вынес приобретя опыт работы в Elm.

Некоторые мысли:

• думать о структуре данных;
• не бить код на модули, как в react (про это было и в докладе Life of file);
• попробовать и «замараться», затем попытаться сделать лучше;

Совет себе прошлому #1: Делать структуру данных

• придумывайте структуру данных, которая отражает UI;
• делайте интерфейс. Делайте «невозможное состояние», невозможным, продумывайте как взаимодействуют части модели;
• отображайте UI (не сразу, а только когда готова структура данных + интерфейс). Обычно, мы сразу начинаем с отображения, а потом думаем о данных. Здесь нужно наоборот.

С 25:45 начинается рассказ про моделирование структуры данных на примере Dreamwriter (редактора, который Ричард делал).

Когда моделируется структура данных, и есть maybe тип, то можно разложить всего его варианты. В докладе, например идет: Loading (Maybe Doc) (Maybe Problem). Стоит подумать, а действительно ли все эти комбинации 2х maybe могут быть?

Совет: начинайте с создания типа вручную, и затем, если видите какой-то патерн — используйте готовые типы. На деле это было так: Loading (Maybe Doc, Maybe Problem) (где maybe «готовый тип») превратилось в «созданный вручную»:

Как видим, Loading тип преобразился и отображает только возможные состояния.

Ричард рекомендует работать по схеме: build -> discover -> refactor. Что подразумевает: что-то сделали, сбилдили. Затем посмотрели как оно работает, вынесли какую-то новую информацию. Если видим, что нужно менять — отрефакторили.

Далее, в примере про view приводится еще один паттерн в Elm — build top level helpers (делайте хэлпер функции высшего порядка). Например:

Здесь, viewLoaded — top level helper. Так же стоит обратить внимание, на то, что у типа Loaded появился один аргумент типа LoadedModel, это record, куда были спрятаны все необходимые свойства. Конкретно для этого доклада, это:

С 39:36 начинается обсуждение моделирования типа Doc (документ, ядро приложения). Причем, сразу же выносится в отдельный модуль.

Началось обсуждение вариантов описания типа для id документа. Если сделать просто type alias DocId = Int, то можем получить не то, что ожидаем:

Обратите внимание, на getRelated. Аргументы doc.docId и resultsPerPage перепутаны местами, но так как они оба Int — компилятор не будет ругаться и все «сбилдится». Type alias docId в процессе билда превратится в Int. Рантайм ошибки не будет (не бывает в Elm), однако приложение работает не так, как мы ожидаем.

Решение — использовать кастомный тип:

Перед нами кастомный тип с одним вариантом. Но он сразу же закроет проблему, если аргументы будут переданы не в нужном порядке. Так как DocId будет содержать декодер и энкодер — выделяем в отдельный файл, т.е. модуль.

Так же, Ричард не expose (выставляет наружу) из модуля DocId конструктор типа, в итоге получаем opaque type.

Opaque type (не прозрачный тип) позволяет скрыть внутреннюю реализацию. Вы не сможете пройтись pattern matching’ом по этому типу, что-то поменять внутри… Вы можете работать с DocId только через то, что «экспозится» наружу, в нашем случае это функции encode и decode + сам тип DocId.

В случае с Problem, которая тоже уехала в отдельный модуль, Ричард экспортирует конструктор типа, потому что он хочет использовать «pattern matching» на данном Enum типе.

На 46:50 идет речь о том, как можно выставить наружу интерфейс для изменения полей внутри opaque типа в виде record: можно создать функции «мапперы».

В конце показан заключительный слайд «Make Data Structure»:

• начинайте с type (с описания типа)
• используйте opaque тип по умолчанию (в процессе, решайте нужно вам наружу выставлять конструктор или нет, если нет — то пусть остается opaque).