"боль и страдания" - только для тех, кто не может в математику. В общем случае, почти любая логика легко может быть добавлена через ещё один слой в композиции функций - даже не надо читать остальной код, только знать типы данных, ожидаемые на входе/выходе. Но соглашусь, что на хаски / ML языках это все выглядит куда естестеннее, чем на JS

хуки это не чистые ф, тред не имеет смысла

Потому что это не хуки были

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

переиспользовать код с хуками легче

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

покажи пример, не могу в голове пока представить

Был конец 60-х, с выходом Симула-67 мир наконец то увидел что можно не вызывать функцию с переменной структуры, а просто забиндить ссылку на структуру в переменной this и урбать этот нулевой аргумент (так как он всегда одинаковый), прошло... 50 лет, а какие то наркоманы берут концепцию чистых функций из ФП ветки развития и херачат туда состояние и называют это хуками, и только для того что бы... хз...

Вас никто не заставляет, если нет согласия с реакт кор тим, то просто пишите в таком стиле, какой удобен вам.

Пишите очевидные вещи... зачем? Просто поддержать беседу и сразу обрубить её?

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

Обрубать тут нечего в общем. Эта беседа никуда не выльется и все пойдёт также как и всегда

классический тред фп vs ооп. истина где-то посередине, зачем спорить?

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

ну от себя скажу, что на хуках писать код всё-таки легче

Что-то я не особо понял, это конфиг валидатора насколько я вижу, но зачем он в виде хука?

он передаст в объект ещё реактивные errors, я их просто пока не обработал ещё

подождите! в какой это объект!!???

Просто спор реально ни о чем, реакт тим аргументировали появление нового api в виде хуков в документации, так развивается библиотека (мне вектор развития нравится, разумеется кому-то нет), о чем тут спорить вообще, будем честны, мы (большая часть по крайней мере) мало сможем повлиять на развитие реакта

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

не набросок, вполне себе работает. ошибки установятся в стейт и пойдут к компоненту, который использует хук. всё просто

Ну ладно, я просто не знаю механизма по которому вызоветься render в той функции, но в целом я не особо понимаю чем это лучше чистой функции которая берет форму и возвращает тебе массив ошибок?

тем, что errors можно будет отрендерить рядом с инпутом

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

зачем? мне этого не нужно. нужна именно валидация

ну дак ты все эти errors всё равно как пропсы кому то даешь?

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

ну во первых он не делает переменную реактивной, это невозможно в js, он замыкает вызов функции как то на ререндер.

ну во первых он не делает переменную реактивной, это невозможно в js, он замыкает вызов функции как то на ререндер.

https://github.com/streamich/react-use

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

если не соблюдать принцип разделения ответственности, то огород будет везде

Я пока всё еще не понял как валидация на хуках помогают переиспользовать код... Так же я пока не понимаю зачем тебе функциональность хука для валидации

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

Ты не поверишь, но валидация на функциях или классах куда мощнее кастомизируется, короче мне нужно поковырять реакт что бы понять

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

я сделал это так, как мне это было надо. не понимаю, к чему эти утверждения

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

я делал валидацию на хоке и мне это понравилось меньше

Вот вполне прикладной случай из реальной практики let fileServerNames = [], fileServerIds = []; this.model.osImageServeList.forEach((server) => { fileServerIds.push(server.id); fileServerNames.push(server.name); }); vs const [ids, names] = transpose(serverList.map(({id,name}) => [id, name])) 🤔

здесь явное отображение, этот пример не канает для императив против фп

поехали отговорки)) Ладно, я согласен что дискуссия не имеет смысла

какие отговорки если для вас верх ФП это отображение одного массива на два?

это всего лишь простой пример. Но что такое фронтенд, как не отображение стейта приложения на HTML разметку?

Ну вообще-то отобразить стейт на html это задача реакт, а все остальное делаете вы, и очень часто ваш код императивный, даже если вам кажеться что он ФП

вы так рассуждаете, будто видели мой код ¯\_(ツ)_/¯

работать с дом в реакт как в нативном жс плохой тон?

ну вы же не затащили хаскель на фронт? значит и код у вас императивный где-то точно есть

вы так рассуждаете, будто видели мой код ¯\_(ツ)_/¯

сходит на сервер, проверить есть ли текущий заказ, если заказа нет создать новый, далее сходить в другое апи и взять от туда что-то и добавить в заказ, если там этого нету создать там и только потом создать заказ, сохранить заказ, уведомить пользователя что заказ создан, уведомить второе апи что эти штуки забронированы, есть смысл переводить в ФП?

сходит на сервер, проверить есть ли текущий заказ, если заказа нет создать новый, далее сходить в другое апи и взять от туда что-то и добавить в заказ, если там этого нету создать там и только потом создать заказ, сохранить заказ, уведомить пользователя что заказ создан, уведомить второе апи что эти штуки забронированы, есть смысл переводить в ФП?

Дело вкуса) Но на rxjs и ramda для меня это описать было бы естественнее и проще, чем городить мешанину из классов

Паттерн Сага, например. Ну или если прям ФП, то монады в помощь.

вы не знаете что такое монада... а сага это не ФП

Йеп

Паттерн Сага, например. Ну или если прям ФП, то монады в помощь.

Дело вкуса) Но на rxjs и ramda для меня это описать было бы естественнее и проще, чем городить мешанину из классов

Короче ребята, вы похоже кроме реакта ничего не видели, давай закончим, это бессмысленно

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

Всем доброй ночи, у кого есть опыт работа Реакт + Ант? Нужна помощь с таблицей в Анте.

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

вы не знаете что такое монада... а сага это не ФП

коллеги кто хорошо знает jest ?

Паттерн сага был описан чуваками из Принстона в 87 году. Кек. «Сага паттерном уже стала» Да, она не ФП, но позволяет не вызывать сайд-эффекты, а декларативно их описывать. Что немного пахнет ФП.