Изволите объясниться? Где это я "топил" за redux-form

Нет. Люядм просто нужны библиотеки. Люди без библиотек не могут.

не все люди любят библиотеки, просто сроки ставят такие, что самому разобраться и "сделать красиво" просто нет времни

т.е. с либой разобраться быстрее, чем с "как сделать красиво"?

я помню, что с тобой срался на счет форм и их стейта в redux

что проще? почитать доку к готовому решению или пилить такое же решение и не писать еще к нему доку?)

Зависит от документации к "решению") Если люди бегают с вопросами "а как *** в этой библиотеке", вероятно, проблема или в документации или людям другую работу найти следует

Главное что есть. То придешь так на проект. А там костыли и велосипеды без доки для работы с формой. И тебе предлагают разбираться как работает это все по коду

Главное что есть. То придешь так на проект. А там костыли и велосипеды без доки для работы с формой. И тебе предлагают разбираться как работает это все по коду

Заранее извиняюсь за глупый вопрос, но зачем в компонентах нужен конструктор? Я же могу создавать какие-то переменные внутри компонента с помощью this.переменная... В инете очень мало про это написано

ну во-первых, у вас вряд ли наберется, хоть сколько ни будь убедительная, аргументация, особенно если попросить освещаеть ее в свете какой ни будь функциональной альтернативы (именно функциональной - т.е. интеграция в state managment, Formik и Final Form это не функциональная альтернатива а концептуальная ) а во-вторых это просто лишено смысла - так как проект официально «почил в бозе» и использовать его в акктуальной разработке никто в здравом уме не станет именно по этой причине - и других причин не надо 🙂 да и собственно на странице проекта сам автор уже всю аргументацию расписал, чуть ли не петицию

ну во-первых, у вас вряд ли наберется, хоть сколько ни будь убедительная, аргументация, особенно если попросить освещаеть ее в свете какой ни будь функциональной альтернативы (именно функциональной - т.е. интеграция в state managment, Formik и Final Form это не функциональная альтернатива а концептуальная ) а во-вторых это просто лишено смысла - так как проект официально «почил в бозе» и использовать его в акктуальной разработке никто в здравом уме не станет именно по этой причине - и других причин не надо 🙂 да и собственно на странице проекта сам автор уже всю аргументацию расписал, чуть ли не петицию

В реакте нет своих классов. Это все js)

А как же Component и PureComponent

он спросил разницу конструктора в js и react. Только вникни в это)

На самом деле небольшая есть. super(props)

Например меня коробит каждый раз от использования FieldArray, когда нужно внутри него расписывать условия по которым нужно рендерить то или иное, работая с методами fields, наворачиваю тонну императивного говна, коробит так же невозможность прокинуть на его уровне список данных для отображения, это возможно только на уровне initialValues, что почти никогда не удобно если форма представляет из себя множество вложенных компонентов, и эти данные предоставляют какие нибудь м2м модели

так, и что?) super - это из js

Ну в случае с реактом нужно наследоваться и вызывать родительский конструктор

да вообще без разницы реакт это или голый js

FieldArray в Final Form (наследии от автора redux-form) такой же форменный п***дец 🙂 только в связи с тем - что данные еще и во внутренем состоянии лежат (у компонента FinalForm ) а не в вашем сторе - то это вообще становится магией и единорогами, его еще не так просто «извылечь» вообще в контекст - когда оно надо 🙂 ну а в общем никто не спорит, у redux-form (помянем) - было много разных проблем и косяков, но в общем и в целом - под зановес большую часть порешали, а те что нет - юзающие научились обходить не задевая грабли - правильным подходом к проектированию своих форм с учетом особенностей решения. Но это было единственное в своем роде подобное решение - и ИМХО на определенном этапе (когда REDUX был везде и всюду - архитектурной основой приложений на React) это решение больше давало преимуществ и удобств, нежели создавало проблем.

Классовый компонент можно реализовать только через наследование. А классами жонглировать можно и без него. Ну тут уже немного не об этом

Так вопрос не про это был)

Так я не на вопрос отвечал, а на ваше утверждение

"В реакте нет своих классов. Это все js)" на это?

Да

Так ты вопрос перечитай "Конструктор класса в JS и в React одно и то- же?"

Ну так утверждение ваше некорректно построено. Вопрос тут уже не при чем

Ну так утверждение ваше некорректно построено. Вопрос тут уже не при чем

а в чем проблема с FieldArray ?

В смысле некорректно? Мы говорим не о Component и PureComponent как об отдельных сущностях, а о классах в React и Js. Когда мы пишем на React, мы пишем на Js.

Component и PureComponent — это классы. Поэтому да, утверждение некорректно. Вот своей реализации классов в реакте действительно нет

«Вот своей реализации классов в реакте действительно нет» - так я про это и написал, учитывая контекст.

Э-м-м с чего бы начать 🙂 давайте пойдем по пунктам «градуса неадекватности поведения» начнем с такого вот кейса, и для начала давайте условимся - что мы как адекватные люди смотрим на все это хозяйство. У нас есть некая структура формы - поля мы описали - и все круто - форма (пустых полей рендерится) - объект значений формы пустой. По мере внесения данных в поля в объекте заполняются соотв.поля - все идет по плану, и тут тебе вдруг понадобился FieldArray и вот тут оказывается что пустую часть формы ты уже не покажешь - чтобы показать на заполнение сами поля - тебе надо проинстанцировать хотя бы один элемент массива (причем на этапе инициализации самой формы или же для такого тривиала придется использовать всякие тентакли-мутаторы и прочую ересь), т.е. он не создастся когда пользователь данные внесет в форму которую видно (она тутпо не среднерится пока ты туда не инстанцируешь значение) А это сразу дает гемморой с тем что все значения array у тебя блин всегда не пустые 🙂 привет 100500 тыщ проверок и прочего колхоза.

ты понял про что я написал?

Э-м-м с чего бы начать 🙂 давайте пойдем по пунктам «градуса неадекватности поведения» начнем с такого вот кейса, и для начала давайте условимся - что мы как адекватные люди смотрим на все это хозяйство. У нас есть некая структура формы - поля мы описали - и все круто - форма (пустых полей рендерится) - объект значений формы пустой. По мере внесения данных в поля в объекте заполняются соотв.поля - все идет по плану, и тут тебе вдруг понадобился FieldArray и вот тут оказывается что пустую часть формы ты уже не покажешь - чтобы показать на заполнение сами поля - тебе надо проинстанцировать хотя бы один элемент массива (причем на этапе инициализации самой формы или же для такого тривиала придется использовать всякие тентакли-мутаторы и прочую ересь), т.е. он не создастся когда пользователь данные внесет в форму которую видно (она тутпо не среднерится пока ты туда не инстанцируешь значение) А это сразу дает гемморой с тем что все значения array у тебя блин всегда не пустые 🙂 привет 100500 тыщ проверок и прочего колхоза.

чем ему не угадилo это "потенциально не правильное исользование this"?)

Это warning инспектора от IDE. Он не знает, как будет использоваться метод и на всякий случай напоминает про магию контекста. Если покопаться в настройках инспектора, можно включить предупреждения о чём угодно. Если мешает — выключите в настройках IDE

Э-м-м с чего бы начать 🙂 давайте пойдем по пунктам «градуса неадекватности поведения» начнем с такого вот кейса, и для начала давайте условимся - что мы как адекватные люди смотрим на все это хозяйство. У нас есть некая структура формы - поля мы описали - и все круто - форма (пустых полей рендерится) - объект значений формы пустой. По мере внесения данных в поля в объекте заполняются соотв.поля - все идет по плану, и тут тебе вдруг понадобился FieldArray и вот тут оказывается что пустую часть формы ты уже не покажешь - чтобы показать на заполнение сами поля - тебе надо проинстанцировать хотя бы один элемент массива (причем на этапе инициализации самой формы или же для такого тривиала придется использовать всякие тентакли-мутаторы и прочую ересь), т.е. он не создастся когда пользователь данные внесет в форму которую видно (она тутпо не среднерится пока ты туда не инстанцируешь значение) А это сразу дает гемморой с тем что все значения array у тебя блин всегда не пустые 🙂 привет 100500 тыщ проверок и прочего колхоза.

Про обертку - в точку. Я вообще в чистом виде Field из FF никогда не использую.

ты понял про что я написал?

поехали дальше - пробовали ли вы, попробовать создлать поля которые ориентированы на конкретные элементы в FieldArray ну давайте представим что струтктура массива у вас стабильная и предсказуемая - попробуйте-ка прицепить поле по его пути «data.blabla[3].orderNumber» - Не дай бог в этой же форме вот этот blabla будет под контролем FieldArray и вы захотите вот так вот («data.blabla[3].orderNumber») к полю подцепить другой филд для прямого доступа - рай для попрактиковаться в отладке side-effects и прочей «магиии»

поехали дальше - пробовали ли вы, попробовать создлать поля которые ориентированы на конкретные элементы в FieldArray ну давайте представим что струтктура массива у вас стабильная и предсказуемая - попробуйте-ка прицепить поле по его пути «data.blabla[3].orderNumber» - Не дай бог в этой же форме вот этот blabla будет под контролем FieldArray и вы захотите вот так вот («data.blabla[3].orderNumber») к полю подцепить другой филд для прямого доступа - рай для попрактиковаться в отладке side-effects и прочей «магиии»

хм… вообще достаточно страные предьявы. Вроде же все логично. Но в целом если уж так хочется то можно написать свою обертку над FieldArray которая решит эту проблему

Это warning инспектора от IDE. Он не знает, как будет использоваться метод и на всякий случай напоминает про магию контекста. Если покопаться в настройках инспектора, можно включить предупреждения о чём угодно. Если мешает — выключите в настройках IDE

да, спасибо, я действительно плохо знаю работу классов в JS, пошел изучать

Привет. Как добавить в cra optional chaining?

ну написать можно собственно и свой gear 🙂 (что кстати многие и делают - в каждом втором проекте свой велосипед «форм-генератор» ) Ранее сегодня, я говорил что не люблю хейтить вообще какие бы то ни было решения, так как все они имеют право на жизнь и кому-то даже может и нравится - но у меня с Final Form личная вендетта 🙂 ни одна либа мне больше крови не выпила чем она 🙂 одно дело баги, недоработки, недостаточность API - но у этой «шарманки» реальные проблемы с аждекватностью того что она делает, т.е. ИМХО - именно с архитектурой и концепцией

https://medium.com/@adostes/enabling-optional-chaining-in-a-create-react-app-a9f626a515d9 я погуглил за Вас - не благодарите (sarcasm)

https://medium.com/@adostes/enabling-optional-chaining-in-a-create-react-app-a9f626a515d9 я погуглил за Вас - не благодарите (sarcasm)

а вроде ts толжен подъехать с ним

ну написать можно собственно и свой gear 🙂 (что кстати многие и делают - в каждом втором проекте свой велосипед «форм-генератор» ) Ранее сегодня, я говорил что не люблю хейтить вообще какие бы то ни было решения, так как все они имеют право на жизнь и кому-то даже может и нравится - но у меня с Final Form личная вендетта 🙂 ни одна либа мне больше крови не выпила чем она 🙂 одно дело баги, недоработки, недостаточность API - но у этой «шарманки» реальные проблемы с аждекватностью того что она делает, т.е. ИМХО - именно с архитектурой и концепцией

немного страшно, у меня уже стоит craco, ничего не сломается?

Если её юзать в чистом виде - то будет сложно, я пытался. Стоит использовать Final Form как основу для построения своего набора компонентов. В этом ключе она удобна. По крайней мере, я не знаю альтернатив. Formik мне показался очень ограниченным в возможностях.

значит через craco можно добавить

делал?

Здравствуйте, посдкажите как можна сделать такой UI, при переключении на табах Companies Users Projects разные таблицы.

Здравствуйте, посдкажите как можна сделать такой UI, при переключении на табах Companies Users Projects разные таблицы.

я не юзал его, но подозреваю, что с его помощью можно засунуть babel plugin

пока больше похоже что проблемы не в архитекутре ff, а в вашей архитектуре. Но второй пример который был приведен я так и не понял А свои велосипеды это зло. Так как правило не документированы. Разбираться каждый раз как что работает как то не очень. Разве что проект совсем маленький и тащить сторонее решение явно будет лишним

пока больше похоже что проблемы не в архитекутре ff, а в вашей архитектуре. Но второй пример который был приведен я так и не понял А свои велосипеды это зло. Так как правило не документированы. Разбираться каждый раз как что работает как то не очень. Разве что проект совсем маленький и тащить сторонее решение явно будет лишним

слишком общий ворпос. Лучше начать делать самому и задавать вопросы про конкртетные проблемы

ну «велосипеды» иной раз документированы лучше чем сторонние решения 🙂 особенно в более не менее серьезных проектах а в чем проблема моей архитектуры ? - если у меня часть формы демонстрируется пустой даже если объект пуст (обычные поля), а другая часть требует инициализации пустых полей (field-arrays) в объекте чтобы быть показанными (пустыми) - при условии, что это одна форма и я ее в одном месте структурно описываю, используя одно решение Это проблемма архитектуры Final Form - ну это блин очвидно, что если это список однотипных под-форм, то первично надо все равно показывать сами поля даже если список - пуст. тут я упрек в некорректности моих представлений и архитектуры принять никак не могу 🙂 простите

второй пример это вот как раз случай, когда ты хочешь с решением сделать что-то более простое чем формочка «о двух полях» 🙂 и вот тут «ягодки» и показываются

FF это form state manager. Его задача хранить состояние формы. Пустой массив это пустой массив. Его отображение это уже задача не FF а разработчика.

Да ладно :) а кто блин рендером управляет и на кой примитивы выполнены в виде компонентов, что-то вас не туда повело :) FF нифига как раз таки не менеджерит в состоянии оно инкапсулировано, оно как раз таки обеспечивает реакции и пресеты данных для отрисовки