ChatGPT на русском языке, бесплатноНовости и обновления в Telegram
На sponsr есть решения ваших задач
Полезные видео о фронтенде. Подпишись на Rutube
Парадигмы программирования - императивная и декларативная
2 года назад·5 мин. на чтение
В этой статье поговорим о парадигмах программирования. Затронем императивную и декларативную парадигмы. Для сравнения разберем несколько небольших примеров. В конце мы взглянем на парадигмы с точки зрения эволюции.
Это серия статей о функциональном программировании:
Как видим, если мы хотим сравнить обе парадигмы (императивную и декларативную), то декларативная парадигма (в нашем случае Функциональная парадигма) больше похожа на шестеренки. Вы разрабатываете свои шестеренки как отдельные единицы, затем добавляете их туда, где они вам нужны. Но в императивной парадигме это больше похоже на тесто. Почти все смешано и слито в один и тот же кусок код.
В целом декларативная парадигма — это:
- Парадигмы программирования (рассматривается в этой статье)
- Композиция
- Функторы
- Каррирование
- Чистые функции
- Функции первого класса
Парадигмы программирования
Парадигма программирования — это стиль или "способ" программирования. Поэтому некоторые языки заставляют нас писать в определенной парадигме. Другие языки оставляют варианты открытыми для программиста, где каждая парадигма следует набору понятий. За всю историю компьютерного программирования инженеры разработали разные языки. Каждый язык основывался на одной или нескольких парадигмах. Эти парадигмы принадлежат к одной из следующих двух основных категорий:1. Императивная парадигма
В императивных языках программирования поток управления является явным, где программист инструктирует программу, как изменить ее состояние. В императивную парадигму также включается:- Структурная парадигма
- Объектно-ориентированная парадигма
2. Декларативная парадигма
В декларативной парадигме поток управления является неявным, когда программист указывает программе, что следует делать, не указывая, как это должно быть сделано. В декларативную парадигму также включается:- Функциональная парадигма
- Логическая парадигма
- Математическая парадигма
- Реактивная парадигма
Императивная парадигма
Императивная парадигма немного изменилась из-за структурной парадигмы, но у нее все еще есть проблемы:- Указание программе, как что-то делать (поток управления является явным)
- Общее состояние
Проблема 1: Указание программе, как что-то делать (поток управления является явным)
Кейс: представьте себе 1000 сотрудников с руководителем, который ведет их по проекту. Руководитель начинает рассказывать 1000 сотрудников, как делать вещи одну за другой. Как вы думаете, насколько это будет плохо? Я почти уверен, что вы видите, что этот стиль управления на микроуровне имеет большие риски, ловушки и даже не сработает. Решение: Сгруппировать людей по зонам ответственности и делегировать в каждую группу руководителя группы. Руководитель каждой группы должен знать, как делать что-то для достижении цели. Это значительно уменьшит сложность, узкие места и станет намного проще в управлении. В этой аналогии- Руководитель = Программист
- Руководители групп = Функции более высокого уровня
- Сотрудники в каждой группе = Строки кода
Проблема 2: Общее состояние
Кейс: Представьте отца, у которого двое детей. У них есть общий банковский счет. Каждый месяц отец кладет на этот счет 1000 долларов. Оба ребенка не знают, что учетная запись используется совместно. Таким образом, они оба думают, что у каждого есть 1000 долларов, которые он может потратить на себя. В конце месяца оказывается, что на этом счету осталось -1000 долларов. Решение: У каждого ребенка должна быть отдельная учетная запись и указанная ежемесячная сумма. В этой аналогии:- Дети = Функции
- Общий банковский счет = общее состояние
Пример императивной парадигмы
Давайте посмотрим, как функция для суммирования может быть реализована в императивной парадигме.Почему этот код считается императивным?const sum = (list) => { let result = 0 for (let i = 0; i < list.length; i++) { result += list[i] } return result }
-
Указание программе, как что-то делать (поток управления является явным): мы явно сообщаем циклу
for
, как работать. Также мы обращаемся к каждому элементу в массиве явно. - Совместное состояние: результирующая переменная является общим состоянием, изменяющимся на каждой итерации (с общим состоянием в более крупных решениях будет гораздо сложнее справиться).
Декларативная парадигма
Декларативная парадигма — это когда программист указывает программе, что должно быть сделано, не указывая, как. В декларативной парадигме мы пишем функции, которые:- Описывают, что должна выполнять программа, а не как (неявный поток управления).
- Не производят побочных эффектов (о которых мы поговорим позже).
Пример декларативной парадигмы
Мы увидели, как функцияsum
может быть реализована в императивной парадигме. Давайте посмотрим, как ее можно реализовать декларативно.
Похоже на магию? Но почему это считается декларативным?const add = (a, b) => a + b const sum = (list) => list.reduce(add)
- Описано, что программа должна выполнять, а не как (неявный поток управления): нет явного итератора, нет явного указания циклу, как работать или как получить доступ к элементам. Это было достигнуто с помощью метода
reduce
. - Не производит побочных эффектов: общее состояние — это форма побочных эффектов, которая была полностью устранена с помощью метода
reduce
и функцииadd
.
Еще одно сравнение
Что, если мы хотим суммировать только четные числа? Разберем эту задачу на примерах в разных парадигмах.Императивная реализация
const evenSum = (list) => { let result = 0 for (let i = 0; i < list.length; i++){ if(list[i] % 2 === 0) { result += list[i] } } return result }
Декларативная реализация
const evenSum = (list) => { const isEven = (n) => n % 2 const add = (a, b) => a + b return list.filter(isEven).reduce(add) }
- Предсказуемость
- Тестируемость
- Многоразовость
- Настраиваемость
- Кэшируемость
- Поддерживаемость
- Компонуемость
sum
, но будут иметь смысл в следующих статьях о функциональном программировании.
Эволюция парадигм
Итак, у нас есть 2 основные парадигмы: императивная и декларативная, каждая из которых имеет подпарадигмы. Теперь поговорим подробнее о структурной, объектно-ориентированной и функциональной парадигмах. с эволюционной точки зрения. Каждая парадигма ограничивала способ программирования, вводя что-то новое.-
Структурная парадигма: ограниченное использование
goto
и «потока передачи управления» за счет введения в наш код такой структуры, какif
/else
/then
/loop
и других. Другими словами, он ограничивает поток передачи управления. - Объектно-ориентированная парадигма: ограничение полиморфизма с использованием указателей на функции за счет введения полиморфизма с использованием наследования.
- Функциональная парадигма: ограничения общего состояния и побочные эффекты за счет введения иммутабельности.
Итоги
В реальной жизни у нас разные парадигмы с разными стилями, которые требуют разного уровня мастерства. Практика большего количества парадигм даст вам больше возможностей. У объектно-ориентированной парадигмы есть свои особенности, у функционального программирования - свои. Чем сильнее вы становитесь в этих парадигмах, тем мощнее будут ваши решения.Оптимизация производительности React - memo, useMemo, useCallback
год назад·6 мин. на чтение
Мемоизация — довольно продвинутая концепция в React, и в 95% случаев в ней нет необходимости. Процесс согласования React (reconciliation, алгоритм React, который определяет, следует ли обновлять компоненты) и виртуальный DOM (то, как React сообщает DOM об обновлении) в большинстве случаев настолько быстры, что невооруженным глазом вы не заметите никакого прироста производительности от использования этих улучшений производительности. Многие React разработчики будут ждать, пока производительность станет заметной проблемой, чтобы приступить к оптимизации.
Является ли ожидание снижения производительности хорошим способом оптимизации компонентов? Мы проектируем наши дороги и автомагистрали так, чтобы они «просто работали», не принимая во внимание транспортный поток? Конечно, нет! Вместо того, чтобы ждать, пока производительность станет проблемой, чтобы начать использовать или изучать методы оптимизации, начните использовать их при написании своих компонентов.
По умолчанию всякий раз, когда
Теперь всякий раз, когда значение
При сравнении пропсов, чтобы определить, должен ли компонент обновляться,
Каждый раз, когда этот компонент перерисовывается, массив будет создаваться заново. Несмотря на то, что
Теперь
Массив в конце
Как и в примере с
Теперь этот компонент будет пересоздавать
Что оно делает:
Обертывает функциональный компонент, перерисовывая компонент только тогда, когда проп или состояние «поверхностно» изменились.
Когда его использовать:
Что оно делает:
Запоминает значение, которое будет пересчитываться только при изменении одной из его зависимостей.
Когда его использовать:
Что оно делает:
Запоминает функцию, которая будет пересчитываться только при изменении одной из ее зависимостей.
Когда его использовать:
memo
Из трех методов мемоизации,memo
, возможно, является самым трудным для осмысления и понимания и, возможно, самым важным. Проще говоря, memo
по умолчанию предотвратит повторный рендеринг компонента. Он будет перерисовывать компонент только в том случае, если внутреннее состояние или проп изменяются. Сравнение происходит поверхностно. Рассмотрим такой пример.
import React, { useState } from 'react'; const Text = ({ text }) => { return <p >{text}</p> }; const ParentComponent = () => { const [firstName, setFirstName] = useState(''); const [lastName, setLastName] = useState(''); return ( <> <input onChange={(e) => setFirstName(e.target.value)} /> <input onChange={(e) => setLastName(e.target.value)} /> <Text text='Your name is:' /> <Text text={firstName} /> <Text text={lastName} /> </> ); };
ParentComponent
обновляется, он перерисовывает все 3 текстовых компонента. Подумайте, сколько символов пользователь может ввести в каждый из этих инпутов. Каждый раз, когда значение меняется, Text
каждый раз перерисовывается. Хотя это простой пример, легко увидеть, как это может стать более серьезной проблемой производительности, учитывая более крупные компоненты, которые отображают множество дочерних компонентов. Давайте посмотрим, как мы можем использовать memo
для оптимизации этого компонента и предотвращения повторного рендеринга всего по умолчанию.
import React, { useState, memo } from 'react'; // Компонент обернут в memo const Text = memo(({ text }) => { return <p >{text}</p> }); const ParentComponent = () => { const [firstName, setFirstName] = useState(''); const [lastName, setLastName] = useState(''); return ( <> <input onChange={(e) => setFirstName(e.target.value)} /> <input onChange={(e) => setLastName(e.target.value)} /> <Text text='Your name is:' /> <Text text={firstName} /> <Text text={lastName} /> </> ); };
firstName
или lastName
изменяет значение, он будет обновлять только соответствующий Text
, связанный с ним. Оборачивание Text
в memo
говорит Text
ререндериться только тогда, когда один из его пропсов изменяется.
Если мы будем менять input
, связанный с firstName
, обновится только второй Text
(<Text text={firstName} />
). Решая, обновлять или нет, Text
сравнивает текущее значение пропса text
с новым значением, и если они совпадут, компонент не обновится. Первый и третий Text
увидят, что их пропсы не поменяли своих значений, и решат, что рендериться не надо.
memo
поверхностно сравнивает пропсы. Это достигается за счет перебора ключей сравниваемых объектов и возврата значения true
, когда значения ключа в каждом объекте не строго равны.
Это определение может сбивать с толку, поэтому можно думать о нем с точки зрения равенства JS. Можно представить поверхностное сравнение, как строгое сравнении JS (===
) для каждого prevProp
и каждого newProp
. Если все возвращают true
, повторный рендеринг не запускается, если все возвращают false
, то рендеринг запускается. Т.е. значения типов boolean
, string
, number
, undefined
, null
будут приводить к ререндеру при изменении их значения. Значения типов array
, object
, function
будут вызывать повторную визуализацию КАЖДЫЙ раз, потому что их равенство объектов всегда будет возвращать false
. Потому что они сравниваются по ссылке.
В этот момент вам может быть интересно, как можно мемоизировать компонент с пропсами в виде массива, объекта или функции. Рассмотрим useMemo
и useCallback
.
useMemo
useMemo
может помочь вам оптимизировать функциональные компоненты, не пересчитывая значение переменной при каждом рендеринге. Он принимает список зависимостей в качестве аргумента, и когда он изменяется, он пересчитывает значение. Рассмотрим такой компонент:
// Пример без использования useMemo import React from "react"; const ComponentThatRendersOften = ({ prop1, prop2 }) => { const array = [prop1]; return ( <MemoizedComponent prop={array} /> ); };
MemoizedComponent
запоминается, он все равно будет перерисовываться каждый раз, когда рендерится ComponentThatRendersOften
. Переменная массива будет воссоздаваться при каждом рендеринге, и, поскольку поверхностное сравнение пропсов определяет повторный рендеринг, он будет каждый раз перерисовываться. Однако мы хотим перерисовывать только при изменении prop1
(массив зависит только от prop1
). Давайте посмотрим, как мы можем использовать useMemo
для пересчета значения только при изменении пропса prop1
.
// Пример с useMemo import React, { useMemo } from "react"; const ComponentThatRendersOften = ({ prop1, prop2 }) => { const array = useMemo(() => { return ([prop1]); }, [prop1]); return ( <MemoizedComponent prop={array} /> ); };
array
будет пересчитываться только при изменении prop1
. Если бы только prop2
обновлял и вызывал повторный рендеринг, array
использовал бы свое последнее вычисленное значение, а не пересчитывался заново. Он будет пересчитан только при изменении prop1
.
useMemo
имеет 2 аргумента:
- функция обратного вызова, которая возвращает запомненное значение.
- массив зависимостей, которые сообщают
useMemo
, когда он должен возвращать новое значение.
useMemo
, [prop1]
— это то, как мы сообщаем ему, чтобы он перезапускал вычисления только при изменении prop1
. Если бы мы хотели запустить его при изменении prop2
, это выглядело бы как [prop1, prop2]
. Если бы мы хотели, чтобы он вычислялся только при начальном монтировании, это выглядело бы как []
.
useMemo
может предложить значительное повышение производительности для функциональных компонентов, которые имеют сложные вычисления значений и часто перерисовываются.
useCallback
useCallback
концептуально схож с useMemo
. Единственное отличие состоит в том, что вместо того, чтобы запоминать значение, useCallback
запоминает функцию. Рассмотрим пример.
import React, { useState } from 'react'; const ComponentThatRendersOften = ({ cb1, cb2 }) => { const [state, setState] = useState(...); const func = () => { setState(...); cb1(); }; return ( <MemoizedComponent onClick={func} /> ); };
useMemo
, каждый раз, когда этот компонент выполняет повторный рендеринг, он будет воссоздавать функцию. Несмотря на то, что MemoizedComponent
запоминается, он все равно будет перерисовываться каждый раз, когда ComponentThatRendersOften
рендерится, потому что func
пересоздаются. Мы могли бы переместить эту функцию за пределы области действия компонента, чтобы не перерисовывать его каждый раз, но тогда мы будем передавать пропсы, локальные переменные и установщики состояния. Это было бы невероятно раздражающим при большом количестве переменных, и это ухудшает читабельность. Давайте мемоизируем эту функцию с помощью useCallback
, чтобы воссоздавать эту функцию только при изменении пропса cb1
.
import React, { useState, useCallback } from 'react'; const ComponentThatRendersOften = ({ cb1, cb2 }) => { const [state, setState] = useState(...); const func = useCallback(() => { setState(...); cb1(); }, [cb1, setState]); return ( <MemoizedComponent onClick={func} /> ); };
func
только при изменении cb1
.
useCallback
имеет 2 аргумента:
- функция обратного вызова, которая запоминается и возвращается
- массив зависимостей, которые сообщают
useCallback
, когда следует воссоздать функцию.
useMemo
, массив в конце useCallback
- [cb1])
- это то, как мы сообщаем ему воссоздавать функцию только тогда, когда cb1
меняет значение. Если бы мы хотели запустить его, когда cb2
и state
также изменились, это выглядело бы как [cb1, cb2, state]
. Если бы мы хотели, чтобы он вычислялся только при начальном монтировании, это выглядело бы как []
.
Когда и что использовать
Самая сложная часть мемоизации — это знать, следует ли ее использовать и когда. Вот краткий список, который поможет решить, является ли мемоизация хорошим решением. Если отмечено большинство или все пункты «когда использовать» и не отмечен ни один пунктов «когда не использовать», вы можете и должны его использовать.memo
Что оно делает:
Обертывает функциональный компонент, перерисовывая компонент только тогда, когда проп или состояние «поверхностно» изменились.
Когда его использовать:
- Вы хотите перерендерить компонент только в том случае, если проп изменился (он все равно будет перерисовываться при обновлении внутреннего состояния).
- Компонент среднего или большого размера или находится выше в дереве React.
- Компонент часто перерисовывается с заметно низкой производительностью.
- Компонент функциональный (не классовый).
- Чтобы обернуть классовый компоненты (для классовых компонентов используется
PureComponent
). - Компонент небольшой или находится ниже в React дереве.
- Компонент не имеет заметно низкой производительности.
useMemo
Что оно делает:
Запоминает значение, которое будет пересчитываться только при изменении одной из его зависимостей.
Когда его использовать:
- Вы передаете переменную в мемоизированный компонент, при этом тип переменной не относится к типу
boolean
,string
,number
,undefined
,null
. Чаще всего оборачивает массивы и объекты. - Только внутри функциональных компонентов
- Вы передаете переменную в мемоизированный компонент, который возвращает
true
со строгим равенством JS (===
). - В классовых компонентах.
useCallback
Что оно делает:
Запоминает функцию, которая будет пересчитываться только при изменении одной из ее зависимостей.
Когда его использовать:
- Вы передаете локально объявленную функцию в мемоизированный компонент или другой массив мемоизированных зависимостей.
- Компонент - функциональный
- У вас есть функция, которая не передается в мемоизированный компонент.
- Вы можете легко переместить свою функцию за пределы компонента (очень простые аргументы функции).