Динамічні сніпети

Досить часто під час розробки додатків виникає потреба виконувати AJAX-операції, наприклад, над окремими рядками таблиці або елементами списку. Для прикладу можемо взяти виведення статей, причому для кожної з них дозволимо зареєстрованому користувачеві вибрати оцінку “подобається/не подобається”. Код презентера та відповідного шаблону без AJAX виглядатиме приблизно так (наводжу найважливіші фрагменти, код розраховує на існування сервісу для позначення оцінок та отримання колекції статей – конкретна реалізація не важлива для цілей цього посібника):

public function handleLike(int $articleId): void
{
	$this->ratingService->saveLike($articleId, $this->user->id);
	$this->redirect('this');
}

public function handleUnlike(int $articleId): void
{
	$this->ratingService->removeLike($articleId, $this->user->id);
	$this->redirect('this');
}

Шаблон:

<article n:foreach="$articles as $article">
	<h2>{$article->title}</h2>
	<div class="content">{$article->content}</div>
	{if !$article->liked}
		<a n:href="like! $article->id" class=ajax>{* це мені подобається *}</a>
	{else}
		<a n:href="unlike! $article->id" class=ajax>{* мені це вже не подобається *}</a>
	{/if}
</article>

Аяксифікація

Тепер давайте оснастимо цей простий додаток AJAX. Зміна оцінки статті не настільки важлива, щоб вимагати перенаправлення, тому ідеально було б, щоб вона відбувалася за допомогою AJAX у фоновому режимі. Ми використаємо скрипт обробки з доповнень зі звичайною конвенцією, що AJAX-посилання мають CSS-клас ajax.

Однак, як це зробити конкретно? Nette пропонує 2 шляхи: шлях так званих динамічних сніпетів та шлях компонентів. Обидва мають свої переваги та недоліки, тому ми розглянемо їх по черзі.

Шлях динамічних сніпетів

Динамічний сніпет в термінології Latte означає специфічний випадок використання тегу {snippet}, коли в назві сніпета використовується змінна. Такий сніпет не може знаходитися будь-де в шаблоні – він повинен бути обгорнутий статичним сніпетом, тобто звичайним, або всередині {snippetArea}. Наш шаблон можна було б змінити наступним чином.

{snippet articlesContainer}
	<article n:foreach="$articles as $article">
		<h2>{$article->title}</h2>
		<div class="content">{$article->content}</div>
		{snippet article-{$article->id}}
			{if !$article->liked}
				<a n:href="like! $article->id" class=ajax>{* це мені подобається *}</a>
			{else}
				<a n:href="unlike! $article->id" class=ajax>{* мені це вже не подобається *}</a>
			{/if}
		{/snippet}
	</article>
{/snippet}

Кожна стаття тепер визначає один сніпет, який має в назві ID статті. Всі ці сніпети потім разом обгорнуті одним сніпетом з назвою articlesContainer. Якби ми пропустили цей обгортаючий сніпет, Latte повідомить нас про це винятком.

Залишається додати до презентера перемальовування – достатньо перемалювати статичну обгортку.

public function handleLike(int $articleId): void
{
	$this->ratingService->saveLike($articleId, $this->user->id);
	if ($this->isAjax()) {
		$this->redrawControl('articlesContainer');
		// $this->redrawControl('article-' . $articleId); -- не потрібно
	} else {
		$this->redirect('this');
	}
}

Аналогічно змінимо і сестринський метод handleUnlike(), і AJAX запрацює!

Однак рішення має один недолік. Якщо ми детальніше дослідимо, як відбувається AJAX-запит, то виявимо, що хоча зовні додаток виглядає економним (повертає лише один єдиний сніпет для даної статті), насправді на сервері він відрендерив усі сніпети. Потрібний сніпет він помістив у payload, а решту відкинув (отже, також абсолютно марно отримав їх із бази даних).

Щоб оптимізувати цей процес, нам доведеться втрутитися там, де ми передаємо колекцію $articles до шаблону (скажімо, в методі renderDefault()). Ми скористаємося тим фактом, що обробка сигналів відбувається перед методами render<Something>:

public function handleLike(int $articleId): void
{
	// ...
	if ($this->isAjax()) {
		// ...
		$this->template->articles = [
			$this->db->table('articles')->get($articleId),
		];
	} else {
		// ...
}

public function renderDefault(): void
{
	if (!isset($this->template->articles)) {
		$this->template->articles = $this->db->table('articles');
	}
}

Тепер при обробці сигналу до шаблону передається замість колекції з усіма статтями лише масив з єдиною статтею – тією, яку ми хочемо відрендерити та надіслати в payload до браузера. {foreach} таким чином пройде лише один раз, і жодних зайвих сніпетів не відрендериться.

Шлях компонентів

Абсолютно інший спосіб вирішення уникає динамічних сніпетів. Трюк полягає в перенесенні всієї логіки в окремий компонент – відтепер про введення оцінки дбатиме не презентер, а спеціалізований LikeControl. Клас виглядатиме наступним чином (крім того, він міститиме також методи render, handleUnlike тощо):

class LikeControl extends Nette\Application\UI\Control
{
	public function __construct(
		private Article $article,
	) {
	}

	public function handleLike(): void
	{
		$this->ratingService->saveLike($this->article->id, $this->presenter->user->id);
		if ($this->presenter->isAjax()) {
			$this->redrawControl();
		} else {
			$this->presenter->redirect('this');
		}
	}
}

Шаблон компонента:

{snippet}
	{if !$article->liked}
		<a n:href="like!" class=ajax>{* це мені подобається *}</a>
	{else}
		<a n:href="unlike!" class=ajax>{* мені це вже не подобається *}</a>
	{/if}
{/snippet}

Звичайно, шаблон view зміниться, і нам доведеться додати до презентера фабрику. Оскільки ми створимо компонент стільки разів, скільки статей отримаємо з бази даних, ми використаємо для його “розмноження” клас Multiplier.

protected function createComponentLikeControl()
{
	$articles = $this->db->table('articles');
	return new Nette\Application\UI\Multiplier(function (int $articleId) use ($articles) {
		return new LikeControl($articles[$articleId]);
	});
}

Шаблон view зменшиться до необхідного мінімуму (і повністю позбавиться сніпетів!):

<article n:foreach="$articles as $article">
	<h2>{$article->title}</h2>
	<div class="content">{$article->content}</div>
	{control "likeControl-$article->id"}
</article>

Майже готово: додаток тепер працюватиме за допомогою AJAX. Тут також нас чекає оптимізація додатку, оскільки через використання Nette Database при обробці сигналу марно завантажуються всі статті з бази даних замість однієї. Перевагою, однак, є те, що їх рендеринг не відбудеться, оскільки відрендериться дійсно лише наш компонент.