Он может быть какого угодно мнения, реальности это не меняет. Весь визг про ФП в рамках реакта/редакса — не более чем маркетинговый прием. Недобросовестная реклама.
> Так почему паттернов ФП нет? там все задачи уникальные?
Нет, потому что решения тривиальны (например, паттерн «стратегия» — просто ф-я, и паттерн «фабрика» — тоже просто функция, и эти функции ничем друг от друга не отличаются, глядя на них вы даже не сможете сказать, какой там паттерн). Основная причина того, что паттерны в ООП существуют — это низкая гибкость применяемых в ООП методов. Ну трудно выражать какие-то вещи через обвязку из наследования, интерфейсов, вот этого вот всего, потому и появляются всякие хитрые схемы, предназначенные для того, чтобы каким-то единым образом описывать вещи, которые сложно описываются. В ФП же гибкость, наоборот, высокая (возможно даже, что слишком высокая), там нет смысла описывать реализацию паттернов в силу их очевидности. На паттерны могут тянуть монады/стрелки/етц., да рекурсивных схемы и их обвязка — но эти вещи слишком абстрактны и не имеют конкретного назначения (в то время как паттерны, вроде, должны иметь).
> Достаточная абстракция, в данном случае, позволяла бы писать код, не зная особенностей HTML и/или DOM. Позволяет ли вам React не знать, как будет выглядеть HTML разметка? Не думать об особенностях веб среды, а сконцентрироваться на вашем приложении?
Вы какбы не совсем понимаете, как оно устроено. Что в реакте, что в ангуляре, о разметке как раз вы и не думаете, потому что там разметки нет. Там есть декларативное описание интерфейса (которое выбрали намеренно «под html», так же как это делается и в современных гуитулкитах вроде какого-нибудь javafx), но это не html, он не работает как html и даже генерит оно в результате не html (в реакте — вдом, в ангуляре — вью, в обоих случаях — это js-объекты на js) :)
А выводом всего это на экран (в виде реального дом, в виде хтмл в случае server-side рендеринга, в случае нативных интерфейсов для мобилок/десктопа, или если угодно, для рисования розовых единорогов) — занимается конкретно слой рендера. Поменяли рендер — и никакого хтмл не осталось и в помине, при этом jsx/шаблоны у вас останутся.
В случае специфических проблем с производительностью без профилировщика обычно, конечно же, никуда, но вот для чего вам в вышеприведенных примерах отладчик нужен — ума не приложу. Конкретно с вашими примерами я не встречался, но вещи, связанные с особенностями конкретного браузера, конечно, вызывали иногда проблемы. Но никогда не приходилось использовать для решения этих проблем отладчик. Собственно, я вообще не использую отладчик. Зато использую ИДЕ :)
> Perl за слишком высокую плотность и нечитабельность кода, а потом с умным видом то же самое делают в JavaScript.
Плотность плотности рознь. Если плотность достигается за счет использования всяких cryptic-конструкций, однобуквенных названий и прочего — это ведет к снижению читабельности, при той же сложности программы. Если же она достигается за счет снижения количества синтаксического мусора и семантической нагрузки в коде — это плотность полезная.
Это неизменяемая коллекция. Точнее, это скорее observable. То есть сама она может измениться (если поменяется содержимое компонента), но поменять ее напрямую нельзя.
> Эммм… Как тогда шаблонизатор, не имея обоих значений, понимает, перезапускать ли пайп или нет?
Я же говорю, он _вместо_ одного значения (результат ф-и) хранит другое (ее аргумент). Естественно, может быть ситуация, когда аргумент больше результата. Или наоборот. Но это уже вопрос статистику, в среднем будет ± одинаково.
> Так вы же сами захотели одноуровневый.
Я просто описывал работу пайпов, а их можно сравнить именно с одноуровневым кешем per instance пайпа.
> Совершенно без разницы, где хранится предыдущее значение, оно все-равно хранится
Оно хранится вместо другого значения. То есть, в итоге оверхеда нет.
> Так и пайп будет каждый раз перезапускаться
Но не будет сохранять предыдущее значение.
> Почему мильон? Мы ж про одноуровневый кэш.
Почему одноуровневый? А если пайп ф-я в нескольких местах применяется?
В любом случае, это бессмысленные рассуждения. Я объяснил, зачем конкретно были введены пайпы — для оптимизации, которую иначе (без изменения алгоритма cd) сделать нельзя. Это единственная причина, а какая-то «теснота» или еще там что не при делах. То, что могут быть какие-то другие варианты оптимизации — факт нерелевантный.
Так вижу я текущий грид, а в кеше мемоизированной функции будет еще мильон старых гридов, которые я уже не вижу :)
Например, я применяю разные фильтры, убираю/добавляю строки, редактирую где-то что-то. В итоге грид меняется, каждый раз вызывается ф-я преобразования (которую мемоизируем), каждый раз она сбрасывает значения в кеш.
> Более того, в пайпах так же должна храниться ссылка на входящий аргумент
В пайпах ничего не хранится — это во View хранятся предыдущие значения биндингов. В случае наличия пайпа, просто в этом месте вместо значения биндинга хранится значение аргумента пайпа, вот все, что делает в этом плане пайп.
> Нет, так как, если вы устраиваете хранилище на инстансе компонента, то это хранилище уничтожится при его анмаунте.
Для анмаунта надо на другую страницу перейти. А если у меня большой грид, и я его тыкаю час? Напоминаю, что вобщем-то вопрос «не пересчитывать то, что не надо» как раз и актуален, когда мы говорим о каких-то больших коллекциях (иначе «тяжелые» функции бывают достаточно редко). Так что это не абстрактный пример, а именно дефолтный кейз.
> Храните-то вы ссылки на эти списки, так что все норм.
Верно. Из-за этого сборщик мусора не может память из-под этих списков освободить — хотя эти списки уже никому и не нужны (кроме как кешу мемоизирующей функции). В результате — утечка. В случае пайпов никаких лишних ссылок не хранится.
> Как же, я же могу вызвать метод из шаблона при подстановке значения
И тогда он будет вызван.
> Если аргумент мемоизированной функции не меняется, возвращается предыдущее значение, а ее тело не запускается заново, такое же ж поведение.
Нет, не такое же. Как минимум — при мемоизации надо хранить где-то много значений. Пайп хранит только одно — предыдущее. И, нет, нельзя в самой функции поставить ограничение на одно значение — т.к. пайп может применяться во многих местах, то есть надо мемоизировать по значению на каждый инстанс в шаблоне. По-этому вы мемоизацией то же самое поведение никогда не получите. Теперь представьте, что вам надо мемоизировать большой список. Очень большой. В случае pure-пайпа у вас не будет накладных расходов на хранение списка. А в случае мемоизации — будет. На кучу списков.
Это в maybe. Если в either, то не будут игнорироваться.
Нет, потому что решения тривиальны (например, паттерн «стратегия» — просто ф-я, и паттерн «фабрика» — тоже просто функция, и эти функции ничем друг от друга не отличаются, глядя на них вы даже не сможете сказать, какой там паттерн). Основная причина того, что паттерны в ООП существуют — это низкая гибкость применяемых в ООП методов. Ну трудно выражать какие-то вещи через обвязку из наследования, интерфейсов, вот этого вот всего, потому и появляются всякие хитрые схемы, предназначенные для того, чтобы каким-то единым образом описывать вещи, которые сложно описываются. В ФП же гибкость, наоборот, высокая (возможно даже, что слишком высокая), там нет смысла описывать реализацию паттернов в силу их очевидности. На паттерны могут тянуть монады/стрелки/етц., да рекурсивных схемы и их обвязка — но эти вещи слишком абстрактны и не имеют конкретного назначения (в то время как паттерны, вроде, должны иметь).
Она не содержит скобок из-за того, что скобки там ничего не значат, в силу правоассоциативности "->".
В ФП нет паттернов, так что вопрос смысла не имеет.
В презентации сказано, что АСТ — только промежуточное представление и в итоге из него генерятся строки.
Вы какбы не совсем понимаете, как оно устроено. Что в реакте, что в ангуляре, о разметке как раз вы и не думаете, потому что там разметки нет. Там есть декларативное описание интерфейса (которое выбрали намеренно «под html», так же как это делается и в современных гуитулкитах вроде какого-нибудь javafx), но это не html, он не работает как html и даже генерит оно в результате не html (в реакте — вдом, в ангуляре — вью, в обоих случаях — это js-объекты на js) :)
А выводом всего это на экран (в виде реального дом, в виде хтмл в случае server-side рендеринга, в случае нативных интерфейсов для мобилок/десктопа, или если угодно, для рисования розовых единорогов) — занимается конкретно слой рендера. Поменяли рендер — и никакого хтмл не осталось и в помине, при этом jsx/шаблоны у вас останутся.
Плотность плотности рознь. Если плотность достигается за счет использования всяких cryptic-конструкций, однобуквенных названий и прочего — это ведет к снижению читабельности, при той же сложности программы. Если же она достигается за счет снижения количества синтаксического мусора и семантической нагрузки в коде — это плотность полезная.
Макросы на строках, без гигиены, в негомоиконном языке — это не метапрограммирование, это курам на смех.
Я же говорю, он _вместо_ одного значения (результат ф-и) хранит другое (ее аргумент). Естественно, может быть ситуация, когда аргумент больше результата. Или наоборот. Но это уже вопрос статистику, в среднем будет ± одинаково.
> Так вы же сами захотели одноуровневый.
Я просто описывал работу пайпов, а их можно сравнить именно с одноуровневым кешем per instance пайпа.
Получается, в ваши основные задачи написание кода не входит. Может, в этом причина несогласия?
Оно хранится вместо другого значения. То есть, в итоге оверхеда нет.
> Так и пайп будет каждый раз перезапускаться
Но не будет сохранять предыдущее значение.
> Почему мильон? Мы ж про одноуровневый кэш.
Почему одноуровневый? А если пайп ф-я в нескольких местах применяется?
В любом случае, это бессмысленные рассуждения. Я объяснил, зачем конкретно были введены пайпы — для оптимизации, которую иначе (без изменения алгоритма cd) сделать нельзя. Это единственная причина, а какая-то «теснота» или еще там что не при делах. То, что могут быть какие-то другие варианты оптимизации — факт нерелевантный.
Так вижу я текущий грид, а в кеше мемоизированной функции будет еще мильон старых гридов, которые я уже не вижу :)
Например, я применяю разные фильтры, убираю/добавляю строки, редактирую где-то что-то. В итоге грид меняется, каждый раз вызывается ф-я преобразования (которую мемоизируем), каждый раз она сбрасывает значения в кеш.
> Более того, в пайпах так же должна храниться ссылка на входящий аргумент
В пайпах ничего не хранится — это во View хранятся предыдущие значения биндингов. В случае наличия пайпа, просто в этом месте вместо значения биндинга хранится значение аргумента пайпа, вот все, что делает в этом плане пайп.
Для анмаунта надо на другую страницу перейти. А если у меня большой грид, и я его тыкаю час? Напоминаю, что вобщем-то вопрос «не пересчитывать то, что не надо» как раз и актуален, когда мы говорим о каких-то больших коллекциях (иначе «тяжелые» функции бывают достаточно редко). Так что это не абстрактный пример, а именно дефолтный кейз.
Верно. Из-за этого сборщик мусора не может память из-под этих списков освободить — хотя эти списки уже никому и не нужны (кроме как кешу мемоизирующей функции). В результате — утечка. В случае пайпов никаких лишних ссылок не хранится.
И тогда он будет вызван.
> Если аргумент мемоизированной функции не меняется, возвращается предыдущее значение, а ее тело не запускается заново, такое же ж поведение.
Нет, не такое же. Как минимум — при мемоизации надо хранить где-то много значений. Пайп хранит только одно — предыдущее. И, нет, нельзя в самой функции поставить ограничение на одно значение — т.к. пайп может применяться во многих местах, то есть надо мемоизировать по значению на каждый инстанс в шаблоне. По-этому вы мемоизацией то же самое поведение никогда не получите. Теперь представьте, что вам надо мемоизировать большой список. Очень большой. В случае pure-пайпа у вас не будет накладных расходов на хранение списка. А в случае мемоизации — будет. На кучу списков.