All streams
Search
Write a publication
Pull to refresh
13
0
Send message
Вы опять же не поняли. Разумеется, на проекте вы не будете реализовать сами curry, partial и прочее, а просто подключите библиотеку.

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

Цитата из статьи:
Заключение

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

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

К слову, вы можете продолжить развитие этого модуля работы с палиндромами и развить его идеи, например загружать строки по апи, преобразовывать в наборы букв и отправлять на сервер, где будет генерироваться строка палиндром и многое другое… На ваше усмотрение.

Также неплохо было бы избавится от дублирования в процессах этих строк:

replaceAllNotWordSymbolsToEmpltyGlobal,
toLowerCase,

В общем, совершенствовать код можно и нужно постоянно!
Ну да, выдернул из теста. В тесты она видим попала из определения палиндрома.
Это переход к функциональному стилю, т.е. к бесточечному коду на верхнем уровне. Довольно распространённая практика.

Вот почитайте.

Такой подход очень часто применяется в совокупности с теми концепциями, которые я описал в статье.
Ну так я и описал функции, которые делают реальную работу.

const allNotWordSymbolsRegexpGlobal = () => /[\.,\/#!$%\^&\*;:{}=\-_~()?\s]/g;
const replace = (regexp, replacement, str) => str.replace(regexp, replacement);
const toLowerCase = str => str.toLowerCase();
const stringReverse = str => str.split('').reverse().join('');
const isStringsEqual = (strA, strB) => strA === strB;


Это пример хелпера для каких либо целей.

Далее мы используя ФП инкапсулируем определённую бизнес логику в продуктовые функции.

Опять же, данный код не более чем обучающий пример на темы композиция, каррирование, частичное применение. В качестве допущения для данной задачи было выбрано: необходимость достижения функциональной чистоты. Кстати, вполне вероятная задача на собеседованиях.
Цель данной статьи: проиллюстрировать некоторые концепции Функционального программирования. Для достижения этой цели мною был выбран следующий метод: на примере популярной задачи из собеседования показать тонкости этих концепций(композиция, каррирование, частичное применение). Поэтому постановка задача была сформулирована так: создайте набор инструментов для решения проблемы. Данная постановка исключает императивный стиль в принципе.
ФП очень хорошо подходит для организации утилей и хелперов на реальных проектах. Разумеется бизнес логику на ФП не нужно организовывать, а вот «набор инструментов для той или иной задачи» в хелперах или утилях будет правильным реализовать на ФП.
Понимаете, ничего не существует в вакууме. Применительно к программированию любой код служит определённым целям. Данный код и данный пример преследует учебные цели: проиллюстрировать определённые техники и практики.

На реальных проектах другие законы. Люди опытные в функциональном программировании не будут читать такие простые статьи, они им не нужны, а для постигающих эти концепции будет простой и понятный пример, который, кстати, может встретится на собеседовании.
Статья о трёх концепциях ФП. Как видите, я реализовал композицию, каррирование и частичное применение нативными средствами. Остальное лишь иллюстративный пример. Данный код нужно воспринимать как код задачи.

На проекте всё слишком специфично и зависит от архитектуры. Для каких — то проектов организация кода в статье — антиреклами ФП, а для каких-то очень даже уместно.

Задача в статье поставлена так: создайте набор инструментов! Не было сказано «напишите две функции». Набор инструментов подразумевает, что мы должны получить на выходе апи, с помощью которого сможем организовать любой тех процесс работы с палиндромами. Собственно поэтому я и показал примерное разбиение на бандлы. В сравнении с начальным вариантом код результата более переиспользуемый и чистый. С точки зрения поставленной задачи код вполне хорош.
Прочитайте ТЗ пожалуйста. Задача создать набор инструментов, а не только две функции, т.е. мы не знаем точно как мы будем использовать элементы набора в коде, поэтому в итоге я приводил весь код с условным разделением на бандлы. На мой взгляд, в реалиях тех задач, которые были поставлены набор абстрактных функций выглядит лучше, чем 2 конкретные функции.

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

Выбор способа использования целиком на совести разработчика, ответственность за результат тоже.
Я извиняюсь! Как бы это иллюстративный пример, речь шла о программировании, а не о русском языке. Фразу я взял с тестов к задаче, которую мы даём на собеседовании. Как она туда попала я не знаю, уж извините.
На мой взгляд, вопрос стоит не так! Не «для каких проектов», а «для каких частей проекта».

Например, на текущем проекте у нас действует следующее соглашение:
— в утилях и хелперах только фп
— в колбеках только фп
— в вотчерах компонентов только фп
— в фабриках старые добрые декларации функций
— моделях ес6 классы

На мой взгляд, удобно.
Так и есть! я не пропагандирую применять ФП везде и всюду! Это лишь инструмент.

Молотком, гвоздями и лопатой можно как человека бить, так и сарай на даче построить. Это уже на совести человека, как распорядится инструментами.
Приветствую! производительность кода в первую очередь зависит от архитектуры приложения и его алгоритмической составляющей. Грубо говоря, как напишите.

Например, лишних сущностей можно как в ФП, так и в ООП наплодить.
Можно сразу и учебников с десяток «понадовать». Парочку по алгоритмам, парочку по ООП, бессмертный труд Фленагана по яваскрипт, десяток книг по паттернам, матан и введение в ФП и т.д.

В ФП ничего не изменяется. Концепция имутабельности справедлива для всех сущностей ФП. Об этом и статья.
Здравствуйте! В рамках статей я сознательно использую нативный js, чтобы показать как та или иная концепция работает. Разумеется, на проекте мы все используем готовые инструменты. Авторы этого коммента я не ответил т.к. очевидно, что он не понял тему.

Information

Rating
Does not participate
Registered
Activity