books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-08-10 21:51:42 +02:00
Code Issues Releases Activity

Backend-driven UI

Browse Source
This commit is contained in:
Sergey Konstantinov
2023-09-14 22:55:27 +03:00
parent f5dcaec39e
commit 3305b238dd
10 changed files with 286 additions and 125 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/API.en.epub
View File

Binary file not shown.

2
docs/API.en.html
View File

@@ -5804,7 +5804,7 @@ api.<span class="hljs-title function_">subscribe</span>(
<li>The functionality of the underlying API</li>
<li>The methods of visualizing data and interacting with UI controls that are conventional for the application platform (possibly, creatively improved by our UX designers).</li>
</ul>
<p>These two subject areas could be far away from each other. Furthermore, <strong>the closer a UI is to representing the raw data, the less convenient it is for the user</strong> (huge forms for entering field values as a classical example<a href="#ref-chapter-43-no-84" id="ref-chapter-43-no-84-back" class="ref"><sup>1</sup></a>). If we aim to make an interface ergonomic, we need to replace “forms” with complex interfaces built atop both data and graphical primitives of the platform. This eventually leads to piling up complexities in the SDK architecture:</p>
<p>These two subject areas could be far away from each other. Furthermore, <strong>the closer a UI is to representing the raw data, the less convenient it is for the user</strong> (huge forms for entering field values as a classical example<a href="#ref-chapter-43-no-84" id="ref-chapter-43-no-84-back" class="ref"><sup>1</sup></a>). If we aim to make an interface ergonomic, we need to replace “forms” with complex interfaces built atop both data and graphical primitives of the platform. Furthermore, these complex UI components will inevitably have their own inner state. This eventually leads to piling up complexities in the SDK architecture:</p>
<h5><a href="#chapter-43-paragraph-1" id="chapter-43-paragraph-1" class="anchor">1. Coupling Heterogeneous Functionality in One Entity</a></h5>
<p>We have placed two buttons (to make an order and to show the coffee shop's location) plus a cancel action onto the offer view panel. These buttons may look identical and they react to the user's actions in the same way, but the way the <code>SearchBox</code> component handles pressing each of them is completely different.</p>
<p>Imagine if we allow developers to add their own action buttons onto the panel, for which purpose we introduce a <code>Button</code> class. We will soon learn that this functionality will be used to cover two diametrically opposite scenarios:</p>

BIN
docs/API.en.pdf
View File

Binary file not shown.

BIN
docs/API.ru.epub
View File

Binary file not shown.

154
docs/API.ru.html
View File

File diff suppressed because one or more lines are too long

BIN
docs/API.ru.pdf
View File

Binary file not shown.

2
docs/index.ru.html
View File

@@ -131,7 +131,7 @@
<li><a href="API.ru.html#sdk-decomposing">Глава 44. Декомпозиция UI-компонентов</a></li>
<li><a href="API.ru.html#sdk-mv-frameworks">Глава 45. MV*-фреймворки</a></li>
<li><a href="API.ru.html#sdk-backend-driven">Глава 46. Backend-Driven UI</a></li>
<li><a href="API.ru.html#chapter-47">Глава 47. Разделяемые ресурсы и асинхронные блокировки</a></li>
<li><a href="API.ru.html#sdk-shared-resources">Глава 47. Разделяемые ресурсы и асинхронные блокировки</a></li>
<li><a href="API.ru.html#chapter-48">Глава 48. Вычисляемые свойства</a></li>
<li><a href="API.ru.html#chapter-49">Глава 49. В заключение</a></li>
</ul>