Тут бы я, на самом деле, выделил интерфейс.

Тут, увы, потенциальная бага, ибо, если создать несколько экземпляров класса - у их статического HttpClient будет попытка повторного добавления тех же header-ов. Хз пока что, насколько критично

тут должен быть TipButtonBuilder, конечно же. А вообще, нужно подумать про вынесение интерфейса билдера и возвращать IModelBuilder

Захуярим в ioc и в конструктор.
Надо будет на его подключение отдельное issue написать, чтоб в board отображать активность.

@MaxVortman. При инициализации ioc нужно будет сконфигурировать его, чтобы он просматривал только сборку Alice.NET, иначе загрузка пользовательского приложения может быть долгой. В любом случае, он лишь создаст накладные расходы, а нужен не в таком уж и большом количестве мест. Нужно ли нам тянуть за собой груз в виде ioc в таком небольшом проекте, а, к тому же, это будет неочевидно для пользователей, что там где-то конейнер что-то инициализирует? Нужно подумать.

@DedSec256 В рамках нашей сборки просматривать ничего не надо. Можем пихать нативно. Не думаю, что их много будет.

@MaxVortman, я уже и отвык что-то вручную пихать :D
Тогда пойдёт.

Мне не нравится, что стринг открытый инитит.
Наверное, стоит сделать класс конфигов, который тоже через контейнер подключим. В нем все константы можно писать. Если их много расплодится, подумаем насчет xml конфига.

Вообще это не нравится. Поле можно инитить и так:

public CardType Type { get; set; } = CardType.BigImage;

Ради одного поля создавать базовый класс? Чет не очень.
К тому же BigImageCard и CardItem дублируют код друг друга (и как следствие их билдеры тоже). Уж лучше сделать базовый класс под их поля, дабы избежать дублирования.

@MaxVortman, мне тоже не очень нравится, я подумаю, что можно сделать ещё покрасивее.

Хочу отдельную директорию Enums, где такое лежать будет.
А то не ясно, где искать в случае чего.

Не нравится такой способ задания хедера и футера.
Считаю, что лучше бы так:

public ItemsListCardBuilder WithFooter(Func<FooterBuilder, Footer> buildFooterFunc)
{
    Card.Footer = buildFooterFunc(new FooterBuilder());
    return this;
}

Тогда пользователь будет пользоваться более привлекательным вариантом:

cardBuilder.WithFooter(fb =>
   fb....
    .Build();
);

@MaxVortman, тоже подумал об этом. Тогда нужно будет то же самое провернуть везде и для Button. И я бы не убирал WithFooter(Footer footer), а лишь добавил бы твою перегрузку, ибо хз, как юзер собирается добавлять их.

Тут тоже, что и с футером.
Мне не хотелось бы отдельно использовать много билдеров.
Кстати, их конструкторы можно скрыть как internal.

Не очень нравится пока что, но зато теперь у нас есть инвариантный контракт, который гарантирует надёжность)!0!))

Но осталась проблема ссылочного типа - один из объектов массива могут поменять случайно позже. Хуёво, чё.

чтобы не создавать его интерфейс и реализацию, можно в IImageCardBuilder добавить CreateBigImageCard(). Но тогда мы не сможем вообще различить билдер для обычного CardItem и BigImageCard