​MVC на пальцах

Приветики-пистолетики. Вот так вот интересно зайду сегодня, могу себе позволить.
В этом посте хочу поговорить о такой прекрасной штуке, как MVC в применении к веб-разработке. Крайне популярная тема для всей Front-End движухи в принципе, которую требуют знать практически у каждого джуна. Поэтому сегодня об этом.

MVC — это паттерн проектирования. Аббревиатура от слов Model, View, Controller. И, несмотря на такую большую распространненность и важность в целом, всё максимально просто. Суть заключается в том, что приложение разбивается на 3 блока, каждый из которых имеет свои функции. Три этих блока, соответственно, — модель, представление и контроллер.

Рассмотрим каждый из блоков отдельно:
• Модель — это блок, который отвечает за данные нашего приложения, и, по сути, во многом определяет его. Этот блок кода определяет данные и способы взаимодействия с ними.
• Представление — блок, который отвечает исключительно за представление наших данных. Этот блок кода отвечает только за то как будет выглядеть наше приложение и не несет в себе никакой бизнес-логики.
• Контроллер — блок, который организовывает взаимодействие модели и представления. В контроллере мы вешаем прослушку событий, взаимодействуем с данными и в целом организуем в этом блоке всю бизнес-логику нашего приложения.

На примере,
Ноутбук: монитор (представление), память (модель), и процессор (контроллер)
Ресторан: вкусный кофе (представление), официант (контроллер), и повар (модель)

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

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

Спасибо за прочтение, это важно ❤️

#theory #patterns

​​Что такое BFF

В мире разработки чуть ли не каждый день возникают новые архитектурные подходы, особенно во FrontEnd'e. Один из относительно новых затрагивает и BackEnd.

BackEnd for FrontEnd, или BFF — это архитектурное направление, которое подразумевает создание отдельного интерфейса взаимодействия для каждого из FrontEnd'ов. Вместо создания одного общего API разработчики ограничивают зоны ответственности и появляются отдельные интерфейсы для каждого из клиентов.

На примере телеграм, у нас есть:
— Веб версия
— Десктопные клиенты
— Мобильные приложения
— Sticker API
— Bot API
— и так далее

И BFF, как часть микросервисного мышления гласит, что один интерфейс-монолит — это неудобно. Зачем делать огромный API, если мы можем сделать несколько поменьше, дабы увеличить скорость работы, поставить зоны ответственности и сделать систему более динамичной, уменьшив связность?

При соблюдении BFF, у Telegram будет несколько интерфейсов API:
— Bot API
— Sticker API
— Mobile API
— Web API

При том допускается разделение Mobile и Web API на, например:
— Chat API
— Channel API
— Audio Call API
— Video Call API
— и так далее

Этих интерфейсов может быть достаточно много для такого большого сервиса. Подробнее можно почитать в разборе Сэма Ньюмана, автора книги «Building Microservices» в издательстве O'REILLY.

На этом у меня всё. Спасибо за прочтение, это правда важно для меня.

#web #theory #patterns #principles

Именованный и неименованный экспорт​

Начнем с того, что экспорт бывает разный — именованный и неименованный.

Именованный экспорт — это использование ключевого слова export перед каждой сущностью или при использовании «паттерна» export list, когда все экспортируемые сущности перечисляются в одном месте файла:

// именованный экспорт
export const a = 1

// export list
const c = 3
const d = 4
const f = 5

export {
 c,
 d,
 f
}

Стандартный же экспорт — это экспорт с использованием конструкции export default:

// стандартный экспорт
const b = 2
export default b

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

import { 
 Status, 
 getUser, 
 render as renderFunction
} from './file'

Стандартный импорт:

import React from 'react'

А также их комбинация:

import React, { useState, useMemo } from 'react'

Но что насчет проблематики? Почему разработчики каждый раз сталкиваются с вопросом какой лучше экспорт выбрать?

Чтобы понять это, рассмотрим следующий пример:

import Angular from 'react' // абсолютно валидно

import { Status as UserStatus } from './file'

В двух импортах выше видна основная проблема — неявные переименования. Такие переименования сущностей могут путать разработчиков, никак не защищают от опечаток, что в совокупности приводит к неоднозначности именований. Из-за всех этих проблем export default является инструментом, использование которого только усложнит поиск чего-либо по коду и его отладку.

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

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

Мой вывод: я стараюсь сократить использование export default до минимума, предпочитая именованный экспорт и импорт. Использовать export default валидно только для интеграции вашего кода с уже готовыми решениями, например, это может быть React.lazy и React.memo, которые работают только с export default по умолчанию. У меня есть удобный хак как это обойти, но это тема для отдельного поста.

Спасибо за прочтение, это важно для меня ❤️

#web #javascript #react #patterns

Что такое мемоизация​

Мемоизация — техника оптимизации кода, сокращающая время его исполнения.

Представим, что у нас есть функция foo, которая выполняется 10 секунд. Нам нужно вызвать эту функцию 3 раза подряд с одними и теми же аргументами. Несложно посчитать, что такой код будет выполняться 30 секунд. Но мы можем применить мемоизацию:
1. Вызовем функцию, подождём 10 секунд и сохраним результат её выполнения в кэш
2. Вызовем функцию ещё раз с теми же аргументами. Вместо того, чтобы исполнять тяжелый код, обратимся к кэшу и проверим нет ли там нужного для нас результат вычислений
3. Если нужный результат есть, вернём его. Если нет, см. шаг 1

Любую ли функцию можно мемоизировать? Конечно же нет. Мемоизировать можно только чистые функции. О том, что это такое, я писал отдельный пост.

Также стоит учитывать, что со временем жизни программы кэш может очень сильно разрастись. Из-за этого сама программа может занимать очень много памяти. Решением может быть несколько подходов:
1. Установить время жизни для каждого из значение кэша
2. Подход LRU (Last Recently Used), когда мы удаляем из кэша значения, которые дольше всего не запрашивались. Такой подход позволяет сохранять в кэше только самые часто используемые данные.
3. Ограничение размера кэша, то есть, когда кэш достигает порогового значения по количеству записей или памяти, старые записи удаляются для освобождения места под новые
4. Просто удалять весь кэш по какому-то таймауту

Сложность тут в том, что нам необходимо реализовать собственный кэш с поддержкой всех необходимых апи для того, что мы описали выше. В JavaScript, например, LRU кэша из коробки, то есть его придётся написать самостоятельно. Самая примитивная же форма кэша для мемоизации, которая и используется чаще всего — Map или же обычный объект.

Если нет желания писать свой велосипед, что прекрасно, можно использовать готовые реализации, например, из библиотеки lodash — вот исходники функции

В следующем посте рассмотрим реализацию примитивной мемоизации в коде.

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #javascript #patterns #data

Что такое Callback Hell и как с ним бороться?

Частый вопрос с собеса, особенно если идти куда-то повыше стажёра.

Callback Hell — это ситуация в асинхронном программировании, когда вложенные друг в друга функции обратного вызова (он же callback) образуют "лесенку", что делает код трудным для чтения и сопровождения.

doSomething(function(result) {
    doSomethingElse(result, function(newResult) {
        doAnotherThing(newResult, function(finalResult) {
            doSomethingMore(finalResult, function(lastResult) {
                console.log(lastResult);
            });
        });
    });
});

Как с этим можно бороться?

Конечно же промисы и async/await синтаксис:

Промисы позволяют писать асинхронный код более линейно и читаемо благодаря цепочке вызовов (chaining):

doSomething()
    .then(result => doSomethingElse(result))
    .then(newResult => doAnotherThing(newResult))
    .then(finalResult => console.log(finalResult))
    .catch(error => console.error(error));

А async/await — это более современный синтаксис над промисами, который так же позволяет развернуть вложенные колбеки в плоский код:

async function process() {
    try {
        const result = await doSomething();
        const newResult = await doSomethingElse(result);
        const finalResult = await doAnotherThing(newResult);
        console.log(finalResult);
    } catch (error) {
        console.error(error);
    }
}

process();

И о Promise, и о async/await у меня уже есть более подробные посты

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #code #javascript #patterns #data

Составные компоненты

Есть такой паттерн для реакта, который называется Compound Components. Это можно перевести как "составные компоненты"

Смысл этого паттерна заключается в том, что мы можем связать компоненты общим окружением и эффективнее использовать их вместе

То есть мы можем заранее объединить компоненты каким-то контекстом и переиспользовать их, например, через общее пространство имён, в качестве которого чаще всего выступает родительский компонент

Запутались в словах? Лучше посмотреть в коде:

Вот пример прям из доки Ant Design:

import { Layout } from 'antd';

<Layout>
    <Layout.Header>Header</Layout.Header>
    <Layout.Content>Content</Layout.Content>
    <Layout.Footer>Footer</Layout.Footer>
</Layout>

Обратили внимание, как компоненты Header, Content и Footer мы получаем напрямую из компонента Layout? Это и есть пример паттерна Compound Components. Компоненты связаны, а используются они из общего пространства — компонента Layout

Зачем же так сделали? Тут преследуется три цели:
1. Явно показать на уровне нейминга, что использовать Layout.Footer вне Layout не нужно
2. Расшарить общий контекст между всеми компонентами Layout
3. Корректно стилизовать части Layout в зависимости от значения внутри общего контекста

С неймингом и стилями, думаю, всё предельно ясно. Но что насчёт контекста? На самом деле, Layout под собой содержит ещё и LayoutContext, который содержит в себе состояние компонента Sider и распространяет его на все дочерние компоненты. Схематически это выглядит примерно так:

InternalLayout  
└ LayoutContext <-- инициализируем контекст
   ├ Header
   ├ Content <-- а в этих компонентах получаем его значение
   ├ Footer
   └ Sider

В итоге получится, что все дочерние компоненты, пытающиеся получить доступ к контексту, без обёртки работать будут криво или и вовсе не будут

С точки зрения типов всё тоже не сложно. Тот же Ant Design делает так:

import InternalLayout, { Content, Footer, Header } from './layout';
import Sider from './Sider';

// получаем тип базового layout компонента
type InternalLayoutType = typeof InternalLayout;

// создаём тип, который определит какие компоненты мы вложим в layout
type CompoundedComponent = InternalLayoutType & {
  Header: typeof Header;
  Footer: typeof Footer;
  Content: typeof Content;
  Sider: typeof Sider;
};

// нагло переприсваиваем тип
const Layout = InternalLayout as CompoundedComponent;

// нагло биндим нужные компоненты
Layout.Header = Header;
Layout.Footer = Footer;
Layout.Content = Content;
Layout.Sider = Sider;

// не менее нагло экспортируем как public-api
export default Layout;

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #typescript #theory #code #react #patterns