Препарируем React и находим родовые травмы

Выбор двух миллионов разрабов, но..

• Не умеет в реактивность.

• Ререндеры по любому чиху.

• Смешивает инициализацию и обновление, логику и шаблон.

• Путается между пересозданиями и перемещением.

• Все компоненты либо неуправляемые, либо неполноценные, либо ожиревшие.

• Кривая эмуляция объектов через функции с хуками.

• Не типизируемый VDOM на выходе.

• Разобщённая экосистема со слабой поддержкой TS.

• Горы бойлерплейта по мере приближения к проду.

В продолжение темы: Реактивный React, Читерские бенчмарки.

Копилка благодарностей: https://boosty.to/hyoo

Шаблон декомпозиции ModelView Fractal

Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

$my_user_list $my_view
	- \Owner ModelView
	users? /$my_user
	kids /
		<= Row*0 $my_user_row
			user <= user*

$my_user_row $my_card
	- \Having ModevView
	user $my_user
		avatar => image
		nickname => message

$my_card $my_view
	- \View not Model
	kids /
		<= Image $my_image
			uri <= image \about:blank
		<= Message $my_text
			text <= message \
	
$my_user $my_model
	- \Model not View
	avatar? \
	nickname? \

✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.
✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.
✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.
✅ Фрактальная структура легко масштабируется на приложения любого размера.

Шаблон декомпозиции Model-View-Presenter

Модели и отображения пассивны, и не знают друг о друге - они управляются презентером, который выступает и в качестве посредника между ними.

// Presenter
class User_preview {
	user: User
	card = new Card({
		image: ()=> this.user.avatar,
		message: ()=> this.user.nickname,
		color: ()=> this.user.skin.color,
		click: ()=> this.skin_change(),
	})
	skin_change() {
		this.user.skin = Skin.random()
	}
}

// View
<div class="Card" onclick={click} style={{ background: color }}>
	<img src={ image } />
	<p>{ message }</p>
</div>

// Model
class User extends Model {
	avatar: string
	nickname: string
	skin: Skin
}

✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
✅ Изменение интерфесов модели или отображения требует изменения только лишь презентеров.
❌ Трёх слоёв слишком мало на больших масштабах.
❌ Для использования состояния одного презентера из другого необходимо искусственное вынесение его в модели.

Шаблон декомпозиции Model-View-Controller

Контроллер создаёт отображение, и говорит ему с какой моделью работать. Так же он обрабатывает все команды от пользователя, и управляет своими подопечными.

// Controller
class Users_resource {
	GET() {
		return User.all.map( user_brief )
	}
}

// View
function user_brief( user: User ) {
	return {
		id: user.guid,
		name: user.passport.name_full,
	}
}

// Model
class User {
	
	static all = [] as User[]
	
	guid: GUID
	passports: Passport[]
	resumes: Resume[]
	
	get passport() {
		return this.passports[0]
	}
	
}

✅ Отображение может использовать произвольные модели с тем же интерфейсом.
✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
❌ Для отображения разных типов моделей необходимо дублировать код отображения.
❌ Изменение интерфейса модели требует обновления всех использующих её отображений и контроллеров.
❌ Трёх слоёв слишком мало на больших масштабах.

Шаблон декомпозиции Model-View-ViewModel

Отображения работают с моделями через посредников, которые трансформируют абстракции предметной области в абстракции отображения и обратно. ViewModel также выступает хранилищем состояния отображения, не связанного с предметной областью.

// View
<li class="User_card" model="User_card_model">
	<img src={ image } />
	<p>{ message }</p>
</li>

// ViewModel
class User_card_model {
	user = User.current
	get image() {
		return this.user.avatar
	}
	get message() {
		return this.user.nickname
	}
}

// Model
class User {
	avatar: string
	nickname: string
	static current = new User
}

✅ Отображение может использовать произвольные вьюмодели.
✅ Легко добавлять новые отображения, не меняя ни модели, ни вьюмодели.
✅ Изменение интерфейса модели или отображения требует изменения только лишь вьюмодели.
✅ Одну и ту же вьюмодель можно шарить между несколькими отображениями.
❌ Для отображения разных моделей необходимо дублировать код отображения и вьюмодели.
❌ Трёх слоёв слишком мало на больших масштабах.

Шаблон декомпозиции View-Model

Код работы с моделями пишется прямо в отображении.

// View
function Task_list() {
	return <ul>{
		Task.list.map( task =>
			<li><Task_row {task} /></li>
		)
	}</ul>
}

// Model
class Task {
	static list = [] as Task[]
}

✅ Отображение может использовать произвольные модели.
✅ Легко добавлять новые отображения, не меняя модели.
❌ Для отображения разных моделей необходимо дублировать код отображения.
❌ Изменение интерфейса модели требует обновления всех использующих её отображений.
❌ Двух слоёв слишком мало на больших масштабах.

Шаблон декомпозиции Model-View

Модель знает как себя по разному представлять.

class User { // Model
	
	_id: bigint
	_nickname: string
	
	toString() { // View
		return 'user=' + this._id
	}
	
	toJSON() { // View
		return {
			id: String( this._id ),
			name: this._nickname,
		}
	}
	
}

✅ Удобно из модели получать любые отображения.
❌ Добавление нового отображения требует изменения модели.
❌ Отображение полностью определяется одной основной моделью.
❌ Загрузка модели вытягивает по зависимостям и все её отображения.
❌ Двух слоёв слишком мало на больших масштабах.

Articles about various aspects of reactivity for communicating with foreigners:

• Components of Reactivity

• Wishes for Reactivity

• Reactive Paradigms

• Reactive Change Detection

• Preventing Equivalent Reactive Computing

• Directions of Reactivity

• Tonus of Reactivity

• Reactive Computing Order

• Reactive Dataflow Configurations

• Exceptions in Reactivity

• Cyclic Reactive Dependencies

• Depth of Reactive Dependencies

• Atomicity of Reactive State Changes

• Reactive Interactions with External Systems

• Reactivity Practicality in Popular JS Libraries

Препарируем Material Design и находим родовые травмы

Подробнейшая документация, но..

• Неконсистентный и неуниверсальный дизайн.

• Сомнительный пользовательский опыт чуть ли не в каждом компоненте.

• Реализация от Гугла в Вебе безбожно тормозит и глючит.

• Тяжёлая поддержка разных форм-факторов и инпут-девайсов.

В продолжение темы: Бестолковый дизайн, Mathematics Driven Design.

Мета: Форум Гипер Дев, Канал с новостями, Донаты.

Выводим Мурыча на чистую воду

Топ перлов:

• В JS нет переменных и присваивания, но есть потоки

• Все числа выделяются в куче

• TS не годится для разработки

• let и const - главные перфоманс ботлнеки

Упоминаемые материалы:

• Исправление Object.assign в TS

• Бенчмарк деструктуризации

• Императивный язык с формальными проверками

• Язык с мощным метапрограммированием

• Сравнение редакторов документов

Мета-сслыки:

• Форум Гипер Дев: https://t.me/h_y_o_o

• $mol_news: https://t.me/mol_news

• Донаты: http://boosty.to/hyoo

Препарируем Tailwind CSS и находим родовые травмы

Бандлинг лишь используемых стилей, но..

• Тормоза при любой динамике.

• Раздутый HTML.

• Крайне слабая кастомизация стороннего кода.

• Сложный массовый рефакторинг.

• Куча стилей компонента в одну строку.

Копилка благодарностей: https://boosty.to/hyoo

Препарируем StyleX и находим родовые травмы

Решение от большой компании, но..

• Раздутый как CSS, так и HTML, и даже JS

• Несемантичный CSS и HTML

• Околонулевая типизация без автодополнения

• Много бойлерплейта

• Зависимость от Babel

• Тормозная сборка

• Сложная отладка

Копилка благодарностей: https://boosty.to/hyoo

Препарируем Feature Slices Design и находим родовые травмы
https://youtu.be/tNx05dfFHRU

Стандартизированная декомпозиция, но..

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

• Нечёткие сомнительные правила

• Тонны бойерплейта на синглтонах

• Ограниченная масштабируемость и гибкость

Поблагодарить, Обсудить.

Чтобы окончательно решить вопрос с кнопками, я создал Фонд Синей Кнопки.

Если наберётся миллион рублей, то все вложившиеся получат свои деньги обратно.

Иначе, для отказавшихся вложиться ничего не изменится, а вот вложившиеся потеряют свои деньги навсегда.

Препарируем Nano Stores и находим родовые травмы
https://youtu.be/Q2rzPc7EEa8

Крайне малые размеры, но..

• Лишние вычисления и сайд-эффекты

• Медленная работа: и архитектурно, и по реализации

• Только статические зависимости с ручным приводом

• Нестабильность поведения

• Автор без этических ограничений

Поблагодарить, Обсудить, Бенчмарки, $mol_wire.

Запуск тестов параллельно с мокнутыми импортами, но..

• Медленное исполнение каждого теста

• Врут про Zero Config

• Развесистый сложный API

• Заточка под модульные тесты вместо компонентных

• Красивые отчёты не помогают в отладке

Поблагодарить: https://boosty.to/hyoo

Централизованный сериализабельный тайм-тревел, но..

• Много бойлерплейта с кишками наружу

• Врут про undo/redo

• Утечки памяти by design

• Тормоза на больших проектах

• Сложно переиспользовать свой код

• Требует кучи тяжёлых костылей

Столько обещаний, но..

• Линейная бизнес-логика превращается в лапшу.

• Много бойлерплейта с ручным приводом.

• Деградация производительности по мере роста приложения.

• Нестабильная работа при возникновении исключения.

• Легко допустить конфликт инвариантов, который приводит к дребезгу, неконсистентности или даже зависанию.

Классные метрики, но..

• Тормоза и глюки в дев-режиме.

• Сетевые задержки при любой навигации.

• Падение при лагающей/потерянной сети.

Богатый набор компонент, но..

• Медленная работа

• Огромный вес

• Слабая кастомизируемость

• Сомнительные практики