For deno to execute typescript, it must first compile it to JS. A warm startup is when deno has a cached JS output already, so it should be fast because it bypasses the TS compiler. A cold startup is when deno must compile from scratch.
JSX. Это — синтаксическое расширение JavaScript, которое позволяет создавать компоненты, используя возможности HTML и JavaScript.
Полная и несусветная глупость, у хтмл в сравнении с js нет никаких возможностей. JSX это просто попытка создать «нормальные» хтмл-шаблоны. И всё это во имя совместимости.
Если вы интересуетесь веб-разработкой, то, возможно, слышали о том, что React позволяет создавать очень быстрые приложения, производительность которых превышает то, что достижимо с использованием лишь JavaScript.
Выше сказали нелепости этой фразы, ведь каким образом либа на жс может быть быстрее жс. На самом деле всё куда глубже.
Сейчас нам достаточно знать о том, что Virtual DOM помогает веб-приложениям работать гораздо быстрее, чем если бы при их разработки использовался обычный JS.
Неверно, vdom является костылём(оптимизацией) изначально несостоятельной концепции(почему она используется — расскажу ниже), при этом эта оптимизация ничего не меняет.
Есть совсем просто: «быстрый» обновляет значение любой ноды за O1, когда как vdom за O(n * const), где n это кол-во элементов в дереве компонентов/элементов, а const некая сложность обновление одного компонента/элемента. Очевидно, что это никоим образом не быстро и целиком и полностью ущербно. Сам vdom лишь влияет на контексту, т.е. сложность обновления в dom выше, чем в vdom. Именно поэтому он быстрее, но быстрее в сравнении с чем?
Теперь про концепцию. Что из себя представляет реакт? Это некий шаблон, вызов которого генерирует dom, который в свою очередь генерирует картинку. Это некий типичный php-way. При каком-либо изменении данных шаблон перевызывается, генерируя новый dom. Очевидно, что такой путь крайне глупый и то решение, которое дал реакт — это не генерировать каждый раз дом, а генерировать vdom. А сам dom иметь мутабельным, накатывая на него обновления, которые есть разница предыдущего/текущего состояния vdom. Это очень типично для любых иммутабельных подходом — они зачастую оказывают несостоятельными.
Почему выбран был такой подход? Ответ прост. Это привычный всем php-way, т.е. эмуляция обычных текстовых шаблонов. Для большинства людей это подход наиболее удобен и понятен.
Очевидно, что из этого описания крайне просто выводится тот самый O1 подход. У нас есть данные, которые отображаются в каких-то элементах. Нам нужно просто запомнить какие данные с чем связаны. Какие данные обновились мы знаем и далее мы просто обновляем связанные с ними элементы. И нам абсолютно неважно сколько там у нас в дереве элементов, хоть миллион, хоть миллиард. Мы просто выкидываем ненужный vdom и изначально несостоятельный подход самого реакта.
И так действительно делается, даже на уровне реакта с его контекстом. А так же на уровне любой state-библиотеки. Но всё это работает на уровне компонентов(ведь реакт не может отслеживать эти связи). Особенно хорошо это работает с реактивностью с тем же mobx.
И все эти ухищрения нужны не просто так. Они — это прямое следствие того, что vdom целиком и полностью несостоятелен. И все как можно больше пытаются обновлять элементы напрямую, руками. И чем меньше там будет vdom — тем лучше.
по ощущениям проще чем Vue(хотя Vue показался тоже простым)
Их нельзя так просто сравнивать. В vue реактивная магия из коробки, а реакте(по крайне мере в предложенном в статье виде) нет и всю магию(если она нужна, а если нет — заменитель) надо прикручивать сбоку.
Я ответа на свой вопрос так и не услышал и могу констатировать необоснованные попытки критиковать мои выводы? Хорошо.
Ваш последний пример подразумевает явный возврат результата в любом случае
Мой пример, как и пример из статьи подразумевает два выхода из функции. Всё остальное — попытки уйти от ответа.
который так же поддерживает неявный возврат «результата последнего вычисленного выражения»
Меня мало волнует то, что там как и что поддерживает. Я не об этом говорил и не про это спрашивал. Я утверждал, что два выхода быть не может — вы попытались с этим поспорить. Я вам что-то начал объяснять, потом показал пример — вы куда-то поплыли.
К тому же, что за попытки необоснованно опровергать мой тезис рандомной фразой. Что она опровергает? Что из неё следует? К чему это написано? Ответа нет(и не будет).
Если вам непонятно почему такого нет в базовой семантике — это очень странно. Вы либо сами не читаете написанные вами цитаты, либо я даже не знаю.
который так же поддерживает неявный возврат «результата последнего вычисленного выражения
В это фразе определяется то, что в функции нету возврата, нету такого понятия как возврат. У функции есть лишь последнее вычисленное выражение, а уже возврат — это неясная семантика. Да и вообще это совершенно другое понятие, а не возврат. Это некий „подвозврат“ т.к. он не обладает полнотой семантики базового.
Объясню проще. Есть базовая семантика {a; b; c; d;} — в ней нет никакого возврата. То, что такой-то „язык“ взял и впилил какую-то пародию на возврат в d; — это не значит, что эта семантика стала частью базовой.
Т.е. автор кортянки пытается свести логику к одному выходу через ifelse, когда как в js этого делать не нужно, ведь там может быть больше одного выхода. Но он сделал тоже самое в js, хотя подобный код — это лишь следствия слабости его «языка». А почему он так сделал? Он пытался всех обмануть.
Это так же ответ на вопрос выше — почему не может. Именно потому, что не может быть два return и родился такой код.
Там где функция заканчивает свою работу — там и return.
Нету такого понятия «заканчивает работу» в базовой семантике. Заканчивает работу функции ruturn, либо аналогичная конструкция. Т.е. это делается явно.
>> Если это в первом ифе — вернётся выражение из первого ифа.
Каким образом? Я не хочу ещё раз объяснять очевидные вещи. Вот вам функций
function f(x) {
if(x) return 1;
return 2;
}
Напишите её с неявным return. Ба, да я только сейчас поглядел что там за код — манипуляции оказываются ещё масштабней. Там даже пример говорит против вас.
Эмм… Не понял, если честно, ваш вопрос. Вы имеете в виду, почему не так:
Да.
11l позволяет выделять блоки
Это хорошо, но это не распространяется на питон, как и на привычки/видение пользователей питона, в том числе и вас(все ваши примеры без скобочек) и ЦА ваших трудов.
Вот я спрашиваю, чем обусловлен такой стиль? А мой же вопрос обусловлен древними холиварами на тему «в c++ есть скобочки, а у нас нет — наш код компактней». Вот я и думаю — это всё идёт с тех времен, либо что-то ещё.
while (true)
{
switch (instr[i])
{
case '[':
nesting_level++;
break;
case ']':
if (--nesting_level == 0)
goto break_;
break;
}
i++;
...
}
break_:
А вы специально используете эти скобочки, чтобы визуально увеличить кол-во C++-кода? В контексте питона(и 11l) вы не можете сказать «мне удобнее/привычней» выделять блоки «скобкой на новой строке», а не отступом.
Ну какой тут можно сделать вывод — полное игнорирование моих тезисов, моей аргументации. Просто попытка кидаться лозунгами вида «ты просто меня не любишь».
Если ФП само по себе не самостоятельно, то почему Haskell считается чисто функциональным языком,
Как быстро вы забыли про лисп и начала про хаскел. Кстати, вы даже базовой терминологии не знаете. «чистый» — это не значит, что там ТОЛЬКО ФП, а это значит вот это: en.wikipedia.org/wiki/Purely_functional_programming
И тут уже у вас возникают проблемы, т.к. до этого вы утверждали:
Система без сайд-эффектов непригодна к использованию.
А википедия нас сообщает:
Purely functional programming may also be defined by forbidding changing-state and mutable data.
К тому же:
data Foo = Foo {x :: Integer, str :: String}
deriving (Eq, Ord, Show)
Насколько я понимаю, википедия мне врёт? И это на самом деле не хаскель? А это переменные, структуры. Да ещё и операторы вида a op b.
но на нем можно писать программы?
Судя по его положению — не очень получается. К тому же, не стоит путать реальность и маркетинговые заявления. Как только всё это сталкивается с реальность — там начинаются манёвры, и вы их уже демонстрировали.
А это я открыл только один файл, причём абсолютно рандомный.
В лиспах магия — макросы. Позволяет расширять поведение языка на лету.
Вот опять лозунг. Хорошо, магия, позволяет и прочее. Я вас не об этом спрашивал, я спрашивал о конкретных, полезных и применимых примерах использования подобной магии.
Зачем мешать жс и реакт, мы ведь только о реакте говорим?
Наверное потому, что организация api в реакте использует свойства/парадигму жс?
Кстати, почему вы не продолжили говорить про реакт? Продолжайте.
Это явное передергивание.
Действительно, всё что вы обзовёте передёргиванием им становится.
Юзер компоненты можно писать трогая только определенную часть АПИ.
Пошли манёвры, ну предоставьте пример использования api, который бы не противоречил базовым принципам ФП. Это ведь так просто.
Пфф… Вы так говорите, будто ФП и лисп в частности запрещают сайд-эффекты и магию.
Да.
Особенно угарно упоминание лиспа, который позволяет творить супер-магию
Поведайте мне об этом, я очень много подобных заявлений слышал, но ни одного примера(реального) не видел.
которая бедному js и не снилась.
Js'y много снилось, да и js'ом всё не ограничивается.
Система без сайд-эффектов непригодна к использованию.
Правильно, так всегда бывает. Вначале придумывается некая модель, выдаётся за «серебряную пулю», далее обнаруживается, что она недееспособна.
Суть ФП в изоляции сайд-эффектов.
А потом начинаются манёвры, и вот один из них. Да, можно напихать(и пихается) в ФП классы, циклы, переменные, мутабельность и прочее, а после говорить «а лисп может». Только вот мочь он должен в рамках ФП-парадигмы, а не в рамках других. Использование другой парадигмы по умолчанию определяет за ФП несостоятельность. Да, тут можно поспорить на тему «на сколько», но факт остаётся фактом — само по себе ФП несостоятельно.
Ну и да, суть чего угодно в изоляции чего угодно.
Реакт прекрасно с этим справляется.
С чем? Где же эта изоляция, если само api по умолчанию не является ФП?
Я даже зашел сюда: en.wikipedia.org/wiki/Functional_programming и проверил свои познания ФП — действительно, всё в ЖС и в ректе противоречит всем базовым концепциям. Объекты на уровне языка, переменные, состояния, отсутствие чистоты, прозрачность ссылок, отсутствие хоть какой-то системы типов, циклы. Хотя в википедии описываются уже современные реалии, сейчас в ФП записывают(задним числом) что угодно. Там уже и «циклы не только через рекурсию» и тому подобное. И даже этим концепциям оно противоречит.
Сам реакт изобилует всякой херней, но это не важно, потому что реакт позволяет писать юзеркод в функциональном стиле.
Какой такой функциональный стиль? Это про что? Про сеттеры, про jsx, про объекты? Это всё ортогонально ФП.
Подход хуков ближе к ФП, потому что в юзеркоде не требует классов, а требует только функции.
Я уже выше объяснял — почему это манипуляции. Это такие же классы. Вы это благополучно проигнорировали.
И да, что за глупости? С каких пор использование функций стало ФП? Там наверное си, фортран, паскаль, тысячи их — это всё ФП, да?
Я не владею в должной мере этой информацией – но даже если это никак не влияет на производительность (расскажите, кто разбирается) – неужели вот чисто концептуально это хорошо и правильно? Никогда этого не понимал. Я мирюсь с инлайновыми функциями для function-as-children и для map – но вот это:
Т.е. вы используете redux, который по определению не может работать быстро, как и любое ФП в целом? Это вам не мешает? А вот пару вызовов функций вдруг помешает? Очень странно.
это же попросту ужасно выглядит, это очень плохо читается, и это НЕ_НУЖНО™. Очевидно же, что эти коллбеки делают одно и то же. На кой ляд их пересоздавать?
Правильно, только это проблемы не колбеков, не стрелочных функций, а redux. Это абстракция вида логика в данные, данные в логику. Это проблема этой абстракции. Как вы иначе преобразуете onClick в необходимый набор данных для вызова dispatch? А никак.
Именно подобные хуки(и это подход в частности) позволяет выпилить так нелюбимое вами непотребство. Мы описываем логику, а далее напрямую привязываем к евентам.
Зато, безусловно, любая обезьянка, едва усвоившая синтаксис стрелочных функций, но ниасилившая этот чудовищно сложный this и жуткие классы, сможет написать рабочий компонент, это да… А потом Фейсбук сочинит какой-нибудь очередной Fiber 19.0, который в очередной раз позволит всему этому хозяйству не лагать.
Сам реакт является жертвой этого подхода, а fiber не лечит стрелочные функции, а лечит реакт. Который и является(по-сути) тем самым redux внутри, со всеми вытекающими тормозами.
Нет там никакого ФП, никакого лиспа и никакой выразительности(в ФП). ФП — это бренд и не более того и ничего от ФП там не осталось. Там магия, магия на сейдэффектах и с сайдэффектами. Это целиком и полностью противоречит всем базовым концепциям ФП.
Сам подход так же противоречит ФП, а суть его в следующем. Что такое класс? Это некие операции над контекстом, а структура контекста определена статистически.
И тут на сцену выходит жс и возникает вопрос/проблема. Динамический язык позволяет генерировать структуру в момент использования. И вот он вопрос, зачем нам заранее определять структуру, когда намного её генерировать в процессе? Именно поэтому в жс никогда и не нужны были классы, был конструктор, который сам организует начальную структур объекта. А далее уже пользователь/метод сам дополнит эту структуру. По-сути класс это просто некий вид статического описания структуры, который мене выразителен чем динамический.
В react-hooks дошли до того, что просто магией добавили контекст в метод. А то, что там нету this — это не попытка эмулировать ФП, а рядовая жс-банальность.
function Constructor() {
this.property;//это просто возможность вытащить проперть наружу
//это не нужно для организации контекста для методов.
privateProperty;
privateMethod() {privateProperty;}
this.publicMethod = privateMethod;
}
Но т.к. у них нет конструктора, а есть только определение одного метода — им нужно было добавить внешний контекст. Плюс, динамическое его определение позволило навесить на него некую магию.
Что из этого имеет какое-то отношение к ФП — неясно. А вот как оно противоречит базовым концепциям ФП — видно сразу.
Одна сторона у вас и работает плохо, и выглядит ужасно, и вообще непонятная\непривычная\кривая.
Она не работает плохо, она мне не непривычна. Она просто ортогональна базовым концепциям того же реакта, да и много чему ещё. Об этом позже.
Преимущества убоги и нефункциональны.
Преимущества есть, но они не здесь. Что, в контексте того же реакта, мне дают классы? Да ничего. Стейт прикручен сбоку, контекст тоже, пропсы тоже. Методы/поля не являются свойствами ТОЛЬКО класса, как в других языках.
Что я получаю от класса? Да ничего не получаю. Я даже не знаю что могут дать классы и за пределами ректа, ну кроме строгости( что крайне спорно, ведь тут строгостью и не пахнет) и декораторов.
Другая же сторона полна магии, которая в тренде, хоть и сложна для понимания, но выглядит красиво, и, вероятно, работает хорошо.
Почти так, и тому есть причины. Зачем нужны тонны бойлерплейта и прочего ахтугда, если можно использовать красивую магию? Это безопасней, быстрее, удобнее. Да, сложнее.
Так?
На самом деле мне нравится магия на декораторах и я за классы. Но в данном случае всё не сводится к моим хотелкам. Я вижу что было и что стало, и что стало мне нравится больше.
что даже если вы используете процедурный подход
Не использую.
знать как устроен this и prototype-chain в JS вам нужно, ибо это одна из центральных частей языка, от которой никуда не деться, и ни за какими React-ми не спрятаться.
Вот видите, в этом и проблема. Мне нужно понимать не классы, не их логику, а логику левых кишков. К тому же, эта логика куда мощнее классов(в контексте жс и его классов). Вот и получается, что у меня есть классы, которые целиком и полностью неюзабельны, а вся логика у меня находится сбоку. Вот и вопрос — зачем нужны такие классы?
… то наверное знать язык, на котором вы пишете и правда имеет смысл. Нет? Я не прав?
Тут дело не совсем в знать. Это как минимум неудобно и алогично, особенно в контексте других языков. Все эти «знать» находятся под и являются свойствами не классов, а того, что под них мимикрирует. И это «под» ортогонально базовым представления из тех же С++, java.
Вот мы и получаем, что есть какой-то класс, который даже не класс и с которым можно сделать что угодно. Как минимум у нас нет статической типизации, а как максимум мы имеем то, что класс не является типом. Всё это ломает привычную парадигму, а то, что мы получаем в замен убого и не функционально.
И зачем нам нужно то, что работает плохо и выглядит ужасно, если проще воспользоваться плюсами этой парадигмы и получит красивую, практичную и удобную магию. К тому же, этот мир(в том числе и реакт) пропитан тем, что не очень привычно людям из других миров. Кому и зачем в мире привычного ООП нужна чистота, иммутабельность и прочие?
Да и подобные решения не являются чем-то новым — это всё уже есть и используется в том же mobx и иже с ним. Магия является трендом и именно магия куда сложнее для понимания.
Как вы объясните это:
Полная и несусветная глупость, у хтмл в сравнении с js нет никаких возможностей. JSX это просто попытка создать «нормальные» хтмл-шаблоны. И всё это во имя совместимости.
Выше сказали нелепости этой фразы, ведь каким образом либа на жс может быть быстрее жс. На самом деле всё куда глубже.
Неверно, vdom является костылём(оптимизацией) изначально несостоятельной концепции(почему она используется — расскажу ниже), при этом эта оптимизация ничего не меняет.
Есть совсем просто: «быстрый» обновляет значение любой ноды за O1, когда как vdom за O(n * const), где n это кол-во элементов в дереве компонентов/элементов, а const некая сложность обновление одного компонента/элемента. Очевидно, что это никоим образом не быстро и целиком и полностью ущербно. Сам vdom лишь влияет на контексту, т.е. сложность обновления в dom выше, чем в vdom. Именно поэтому он быстрее, но быстрее в сравнении с чем?
Теперь про концепцию. Что из себя представляет реакт? Это некий шаблон, вызов которого генерирует dom, который в свою очередь генерирует картинку. Это некий типичный php-way. При каком-либо изменении данных шаблон перевызывается, генерируя новый dom. Очевидно, что такой путь крайне глупый и то решение, которое дал реакт — это не генерировать каждый раз дом, а генерировать vdom. А сам dom иметь мутабельным, накатывая на него обновления, которые есть разница предыдущего/текущего состояния vdom. Это очень типично для любых иммутабельных подходом — они зачастую оказывают несостоятельными.
Почему выбран был такой подход? Ответ прост. Это привычный всем php-way, т.е. эмуляция обычных текстовых шаблонов. Для большинства людей это подход наиболее удобен и понятен.
Очевидно, что из этого описания крайне просто выводится тот самый O1 подход. У нас есть данные, которые отображаются в каких-то элементах. Нам нужно просто запомнить какие данные с чем связаны. Какие данные обновились мы знаем и далее мы просто обновляем связанные с ними элементы. И нам абсолютно неважно сколько там у нас в дереве элементов, хоть миллион, хоть миллиард. Мы просто выкидываем ненужный vdom и изначально несостоятельный подход самого реакта.
И так действительно делается, даже на уровне реакта с его контекстом. А так же на уровне любой state-библиотеки. Но всё это работает на уровне компонентов(ведь реакт не может отслеживать эти связи). Особенно хорошо это работает с реактивностью с тем же mobx.
И все эти ухищрения нужны не просто так. Они — это прямое следствие того, что vdom целиком и полностью несостоятелен. И все как можно больше пытаются обновлять элементы напрямую, руками. И чем меньше там будет vdom — тем лучше.
Их нельзя так просто сравнивать. В vue реактивная магия из коробки, а реакте(по крайне мере в предложенном в статье виде) нет и всю магию(если она нужна, а если нет — заменитель) надо прикручивать сбоку.
Мой пример, как и пример из статьи подразумевает два выхода из функции. Всё остальное — попытки уйти от ответа.
Меня мало волнует то, что там как и что поддерживает. Я не об этом говорил и не про это спрашивал. Я утверждал, что два выхода быть не может — вы попытались с этим поспорить. Я вам что-то начал объяснять, потом показал пример — вы куда-то поплыли.
К тому же, что за попытки необоснованно опровергать мой тезис рандомной фразой. Что она опровергает? Что из неё следует? К чему это написано? Ответа нет(и не будет).
Если вам непонятно почему такого нет в базовой семантике — это очень странно. Вы либо сами не читаете написанные вами цитаты, либо я даже не знаю.
В это фразе определяется то, что в функции нету возврата, нету такого понятия как возврат. У функции есть лишь последнее вычисленное выражение, а уже возврат — это неясная семантика. Да и вообще это совершенно другое понятие, а не возврат. Это некий „подвозврат“ т.к. он не обладает полнотой семантики базового.
Объясню проще. Есть базовая семантика {a; b; c; d;} — в ней нет никакого возврата. То, что такой-то „язык“ взял и впилил какую-то пародию на возврат в d; — это не значит, что эта семантика стала частью базовой.
Правильно код выше должен выглядеть так. А теперь, я думаю, что вторая манипуляция очевидна.
Т.к. в этом «языке» нет явного return, то там попросту нельзя написать такой код. Именно поэтому родилась подобная портянка:
Т.е. автор кортянки пытается свести логику к одному выходу через ifelse, когда как в js этого делать не нужно, ведь там может быть больше одного выхода. Но он сделал тоже самое в js, хотя подобный код — это лишь следствия слабости его «языка». А почему он так сделал? Он пытался всех обмануть.
Это так же ответ на вопрос выше — почему не может. Именно потому, что не может быть два return и родился такой код.
Из чего это очевидно?
Нету такого понятия «заканчивает работу» в базовой семантике. Заканчивает работу функции ruturn, либо аналогичная конструкция. Т.е. это делается явно.
>> Если это в первом ифе — вернётся выражение из первого ифа.
Каким образом? Я не хочу ещё раз объяснять очевидные вещи. Вот вам функций
Напишите её с неявным return. Ба, да я только сейчас поглядел что там за код — манипуляции оказываются ещё масштабней. Там даже пример говорит против вас.
Буквально недавно спрашивал про почти такое же и вот оно опять тут.
Если уж мы пишем без скобок, то надо и писать без скобок. Что за глупые манипуляции?
И что же это дало? Да ничего, никто не пишет код в блокноте, а значит никакой разницы между function и def нет. К тому же function писать удобнее.
О да, прям отличие из отличий. Как там, num1 = 123 — оно осилит распарсить?
Т.е. без скобок нельзя? Неужели это специально подобранный пример?
Это всяко лучше скобок, особенно с ТЗ компилишена. Зачем нам предсказуемый синтаксис — мы будем страдать.
Как же так?
Я прям поверил.
А, ну т.е. из функции может быть только один return?
Да.
Это хорошо, но это не распространяется на питон, как и на привычки/видение пользователей питона, в том числе и вас(все ваши примеры без скобочек) и ЦА ваших трудов.
Вот я спрашиваю, чем обусловлен такой стиль? А мой же вопрос обусловлен древними холиварами на тему «в c++ есть скобочки, а у нас нет — наш код компактней». Вот я и думаю — это всё идёт с тех времен, либо что-то ещё.
А вы специально используете эти скобочки, чтобы визуально увеличить кол-во C++-кода? В контексте питона(и 11l) вы не можете сказать «мне удобнее/привычней» выделять блоки «скобкой на новой строке», а не отступом.
Как быстро вы забыли про лисп и начала про хаскел. Кстати, вы даже базовой терминологии не знаете. «чистый» — это не значит, что там ТОЛЬКО ФП, а это значит вот это: en.wikipedia.org/wiki/Purely_functional_programming
И тут уже у вас возникают проблемы, т.к. до этого вы утверждали:
А википедия нас сообщает:
К тому же:
data Foo = Foo {x :: Integer, str :: String}deriving (Eq, Ord, Show)
Насколько я понимаю, википедия мне врёт? И это на самом деле не хаскель? А это переменные, структуры. Да ещё и операторы вида a op b.
Судя по его положению — не очень получается. К тому же, не стоит путать реальность и маркетинговые заявления. Как только всё это сталкивается с реальность — там начинаются манёвры, и вы их уже демонстрировали.
такое, такое, такое, такое и такое.
А это я открыл только один файл, причём абсолютно рандомный.
Вот опять лозунг. Хорошо, магия, позволяет и прочее. Я вас не об этом спрашивал, я спрашивал о конкретных, полезных и применимых примерах использования подобной магии.
Наверное потому, что организация api в реакте использует свойства/парадигму жс?
Кстати, почему вы не продолжили говорить про реакт? Продолжайте.
Действительно, всё что вы обзовёте передёргиванием им становится.
Пошли манёвры, ну предоставьте пример использования api, который бы не противоречил базовым принципам ФП. Это ведь так просто.
Да.
Поведайте мне об этом, я очень много подобных заявлений слышал, но ни одного примера(реального) не видел.
Js'y много снилось, да и js'ом всё не ограничивается.
Правильно, так всегда бывает. Вначале придумывается некая модель, выдаётся за «серебряную пулю», далее обнаруживается, что она недееспособна.
А потом начинаются манёвры, и вот один из них. Да, можно напихать(и пихается) в ФП классы, циклы, переменные, мутабельность и прочее, а после говорить «а лисп может». Только вот мочь он должен в рамках ФП-парадигмы, а не в рамках других. Использование другой парадигмы по умолчанию определяет за ФП несостоятельность. Да, тут можно поспорить на тему «на сколько», но факт остаётся фактом — само по себе ФП несостоятельно.
Ну и да, суть чего угодно в изоляции чего угодно.
С чем? Где же эта изоляция, если само api по умолчанию не является ФП?
Я даже зашел сюда: en.wikipedia.org/wiki/Functional_programming и проверил свои познания ФП — действительно, всё в ЖС и в ректе противоречит всем базовым концепциям. Объекты на уровне языка, переменные, состояния, отсутствие чистоты, прозрачность ссылок, отсутствие хоть какой-то системы типов, циклы. Хотя в википедии описываются уже современные реалии, сейчас в ФП записывают(задним числом) что угодно. Там уже и «циклы не только через рекурсию» и тому подобное. И даже этим концепциям оно противоречит.
Какой такой функциональный стиль? Это про что? Про сеттеры, про jsx, про объекты? Это всё ортогонально ФП.
Я уже выше объяснял — почему это манипуляции. Это такие же классы. Вы это благополучно проигнорировали.
И да, что за глупости? С каких пор использование функций стало ФП? Там наверное си, фортран, паскаль, тысячи их — это всё ФП, да?
Т.е. вы используете redux, который по определению не может работать быстро, как и любое ФП в целом? Это вам не мешает? А вот пару вызовов функций вдруг помешает? Очень странно.
Правильно, только это проблемы не колбеков, не стрелочных функций, а redux. Это абстракция вида логика в данные, данные в логику. Это проблема этой абстракции. Как вы иначе преобразуете onClick в необходимый набор данных для вызова dispatch? А никак.
Именно подобные хуки(и это подход в частности) позволяет выпилить так нелюбимое вами непотребство. Мы описываем логику, а далее напрямую привязываем к евентам.
Сам реакт является жертвой этого подхода, а fiber не лечит стрелочные функции, а лечит реакт. Который и является(по-сути) тем самым redux внутри, со всеми вытекающими тормозами.
Сам подход так же противоречит ФП, а суть его в следующем. Что такое класс? Это некие операции над контекстом, а структура контекста определена статистически.
И тут на сцену выходит жс и возникает вопрос/проблема. Динамический язык позволяет генерировать структуру в момент использования. И вот он вопрос, зачем нам заранее определять структуру, когда намного её генерировать в процессе? Именно поэтому в жс никогда и не нужны были классы, был конструктор, который сам организует начальную структур объекта. А далее уже пользователь/метод сам дополнит эту структуру. По-сути класс это просто некий вид статического описания структуры, который мене выразителен чем динамический.
В react-hooks дошли до того, что просто магией добавили контекст в метод. А то, что там нету this — это не попытка эмулировать ФП, а рядовая жс-банальность.
function Constructor() {
this.property;//это просто возможность вытащить проперть наружу
//это не нужно для организации контекста для методов.
privateProperty;
privateMethod() {privateProperty;}
this.publicMethod = privateMethod;
}
Но т.к. у них нет конструктора, а есть только определение одного метода — им нужно было добавить внешний контекст. Плюс, динамическое его определение позволило навесить на него некую магию.
Что из этого имеет какое-то отношение к ФП — неясно. А вот как оно противоречит базовым концепциям ФП — видно сразу.
Она не работает плохо, она мне не непривычна. Она просто ортогональна базовым концепциям того же реакта, да и много чему ещё. Об этом позже.
Преимущества есть, но они не здесь. Что, в контексте того же реакта, мне дают классы? Да ничего. Стейт прикручен сбоку, контекст тоже, пропсы тоже. Методы/поля не являются свойствами ТОЛЬКО класса, как в других языках.
Что я получаю от класса? Да ничего не получаю. Я даже не знаю что могут дать классы и за пределами ректа, ну кроме строгости( что крайне спорно, ведь тут строгостью и не пахнет) и декораторов.
Почти так, и тому есть причины. Зачем нужны тонны бойлерплейта и прочего ахтугда, если можно использовать красивую магию? Это безопасней, быстрее, удобнее. Да, сложнее.
На самом деле мне нравится магия на декораторах и я за классы. Но в данном случае всё не сводится к моим хотелкам. Я вижу что было и что стало, и что стало мне нравится больше.
Не использую.
Вот видите, в этом и проблема. Мне нужно понимать не классы, не их логику, а логику левых кишков. К тому же, эта логика куда мощнее классов(в контексте жс и его классов). Вот и получается, что у меня есть классы, которые целиком и полностью неюзабельны, а вся логика у меня находится сбоку. Вот и вопрос — зачем нужны такие классы?
Тут дело не совсем в знать. Это как минимум неудобно и алогично, особенно в контексте других языков. Все эти «знать» находятся под и являются свойствами не классов, а того, что под них мимикрирует. И это «под» ортогонально базовым представления из тех же С++, java.
Вот мы и получаем, что есть какой-то класс, который даже не класс и с которым можно сделать что угодно. Как минимум у нас нет статической типизации, а как максимум мы имеем то, что класс не является типом. Всё это ломает привычную парадигму, а то, что мы получаем в замен убого и не функционально.
И зачем нам нужно то, что работает плохо и выглядит ужасно, если проще воспользоваться плюсами этой парадигмы и получит красивую, практичную и удобную магию. К тому же, этот мир(в том числе и реакт) пропитан тем, что не очень привычно людям из других миров. Кому и зачем в мире привычного ООП нужна чистота, иммутабельность и прочие?
Да и подобные решения не являются чем-то новым — это всё уже есть и используется в том же mobx и иже с ним. Магия является трендом и именно магия куда сложнее для понимания.