Это обман чтобы набрать классы

:)))

Я сам от классов стараюсь уходить... Поэтому в родительском контейнере стейты и подключение к стору. Все остальное через пропсы и максимально плоско

Чот мир реакта в ближайшие полгода ебанётся, чуствую.

если честно, не знаю, правильно это, или нет, но мне вообще не очень нравится укоренение приложения в UI библиотеку

Я в рекомпозе сижу и не хотел вылазить

стейтом можно управлять как угодно и без react'а, подключая его через коннектор (я говорю о стейте уровня бизнес-логики) презентационный стейт (всякие переключатели, открыватели/скрыватели) - ради бога

Я в рекомпозе сижу и не хотел вылазить

Та же фигня

Чот мир реакта в ближайшие полгода ебанётся, чуствую.

Главное чтобы не наебнулся

Главное чтобы не наебнулся

Я боюсь, что однажды проснусь и увижу, что уже наебнулось.

Коннектор — это просто model-view в m mv v

стейтом можно управлять как угодно и без react'а, подключая его через коннектор (я говорю о стейте уровня бизнес-логики) презентационный стейт (всякие переключатели, открыватели/скрыватели) - ради бога

Мне ооп непонятен в кое каких местах

Коннектор — это просто model-view в m mv v

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

А реакт тима разрабатывает view, их задача — предоставить возможность, а все просто идут у них на поводу

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

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

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

А реакт тима разрабатывает view, их задача — предоставить возможность, а все просто идут у них на поводу

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

Функции функциям потакают

А реакт тима разрабатывает view, их задача — предоставить возможность, а все просто идут у них на поводу

Да, только они ещё не поняли, что им надо разрабатывать только V.

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

Главное что никто не виноват, всё на благих намерениях

И лезут всё время в другую область.

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

да, невозможно все предвидеть

Вот как это с recompose на хуки переделать? Точнее зачем?)

Это равносильно длинной цепи class extends class extsnds class

Ага

Вот как это с recompose на хуки переделать? Точнее зачем?)

Нехуй было городить )

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

Да, более чем

Нехуй было городить )

Чего бы, все окей с этим сейчас

Да, только они ещё не поняли, что им надо разрабатывать только V.

взять тот же API от react-redux. На мой взгляд, он очень нагроможденный, да и там вообще много лазеек для того, чтобы "по-быстрому" решить задачу, пробросив пропсы, чтобы просто работало

взять тот же API от react-redux. На мой взгляд, он очень нагроможденный, да и там вообще много лазеек для того, чтобы "по-быстрому" решить задачу, пробросив пропсы, чтобы просто работало

Ну да, я забыл сказать, что редакс говно ещё то.

У react-redux проблема в гипер-оверлоаде функции и незавершенности общей идеи

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

Но тогда время было такое, все угорали по атомарным решениям

Используйте пока что эффектор.

?

У react-redux проблема в гипер-оверлоаде функции и незавершенности общей идеи

полностью согласен

Используйте пока что эффектор.

а это что?)

а это что?)

google "effector react js"

?

используйте пока что эффектор.

спасибо

вопрос

У react-redux проблема в гипер-оверлоаде функции и незавершенности общей идеи

общая идея ведь неплоха?

сейчас поясню

чет не очень

технически, через тонкий коннектор можно ведь ловко орудовать стейтом и интерфейсом

технически, через тонкий коннектор можно ведь ловко орудовать стейтом и интерфейсом

Ок. А твой коннектор может обеспечивать локальность?

Ок. А твой коннектор может обеспечивать локальность?

можно пояснить, пожалуйста

что кроется под локальностью

можно пояснить, пожалуйста

Введи список своих компонентов.

И будет ли у каждого компонента свой стейт?

вопрос

столбиками сообщения не надо писать

Руководство: как нарисовать сову)

столбиками сообщения не надо писать

иначе получишь с вертухи, тут такие правила, сорян

Руководство: как нарисовать сову)

анус себе нарисуй

используйте пока что эффектор.

В фронтенде не бывает вечных решений

В фронтенде не бывает вечных решений

+

Поэтому мне норм и так)

Поэтому мне норм и так)

Ок)

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

@ZeroBias димон, вот ты всегда видишь проблемы на корню. скажи что с хуками не так

И будет ли у каждого компонента свой стейт?

ты можешь локализовать стейт, инициализировав его вместе с connect'ом компонента внутри функции Component = createComponet() // внутри создаем local state и connect'им если у тебя rxjs - можно инициализировать поток без лишних функций и законнектить его тут же "холодный" поток будет саморазрушаться при отписке

@ZeroBias димон, вот ты всегда видишь проблемы на корню. скажи что с хуками не так

Порядок завязан жёстко.

Порядок завязан жёстко.

не понял немного, ты о чем?

В ифах не можешь использовать.

С ними всё ок)

Они решают лишь проблемы, которые в react как в ведущем view подходе должны были быть решены сто лет назад

Они решают лишь проблемы, которые в react как в ведущем view подходе должны были быть решены сто лет назад

+

В ифах не можешь использовать.

так это не проблема, это ее решение.

В ифах не можешь использовать.

почему?

бля, ну да. потом найдуться, конечно, кенты, который такие - бля, мы эти хуки по вебсокетам передаем, а потом им делаем ивал - хули не работает?

ну так-то да ?

почему?

Потому что их работа завязана порядок инициализации и вызова.

Они решают лишь проблемы, которые в react как в ведущем view подходе должны были быть решены сто лет назад

То есть это не революция, это наконец-то +- адекватный view. Дело теперь за model и model view

То что их нельзя юзать в условиях и циклах это как бы вообще не фича, наконец-то какие-то ограничения для раздувающегося view)

ну я про тоже, были же поделки которые малька похоже себя вели (я рили не помню что за они, но оборачивали fn компонент и добавляли стэйт), но это не о том совершенно. я клоню к тому что теперь твой эффектор тоже можно отбрасывать ?

@XaveScor я там немного уточнил свой ответ

ну я про тоже, были же поделки которые малька похоже себя вели (я рили не помню что за они, но оборачивали fn компонент и добавляли стэйт), но это не о том совершенно. я клоню к тому что теперь твой эффектор тоже можно отбрасывать ?

Свежо предание

Это равносильно длинной цепи class extends class extsnds class

семантически да, а фактически с цепочкой наследования не будет той огромной матрешки врапперов компонентов отсуствие которой кстати обозначили на докладе как киллер-фича хуков. Получается что и с обычными хокками (только не через композицию как обычно делают а через наследование) можно избавиться от этого https://t.me/react_js/508579

Ты не понимаешь предназначения библиотеки, это не хелпер для реакта

ну я про тоже, были же поделки которые малька похоже себя вели (я рили не помню что за они, но оборачивали fn компонент и добавляли стэйт), но это не о том совершенно. я клоню к тому что теперь твой эффектор тоже можно отбрасывать ?

ты не про nothis, я надеюсь?

семантически да, а фактически с цепочкой наследования не будет той огромной матрешки врапперов компонентов отсуствие которой кстати обозначили на докладе как киллер-фича хуков. Получается что и с обычными хокками (только не через композицию как обычно делают а через наследование) можно избавиться от этого https://t.me/react_js/508579

Это без но, это равносильно

разница лишь синтаксическая, нет new, всё остальное без изменений

Это классическое наследование во всех проявлениях

@XaveScor я там немного уточнил свой ответ

куда отбрасывать

а в вуе что юзать?

Ты не понимаешь предназначения библиотеки, это не хелпер для реакта

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

столбиками сообщения не надо писать

хорошо

то есть я про то что редакс я как-то и в бэк проектах юзал (тогда еще эффектора не было ?

ну я про тоже, были же поделки которые малька похоже себя вели (я рили не помню что за они, но оборачивали fn компонент и добавляли стэйт), но это не о том совершенно. я клоню к тому что теперь твой эффектор тоже можно отбрасывать ?

Бери vue. Ззачем это всё разделение model view model-view, к чему все эти сложности, нужно же просто грести и не сбиваться с ритма барабана; зачем себя мучать

вот сейчас обидно было

Ну мне то конечно приятно было, довести бизнес-логику до статуса санков

И типа такой "я всё понял, всё хуйня"

Это без но, это равносильно

есть два вида хокков - которые через композицию const withProps = (newProps)=>Component=> (..props)=> ( <Component {...newProps} {...props}/> ) и которые через наследование const withProps = (newProps) => Component => class extends Component { static defaultProps = { ...Component.defaultProps, ...newProps } } первый подход приводит к огромной матрешке врапперов а второй подход нет и как раз фактически является вот тем что ты написал - class extends class extends class ...

есть два вида хокков - которые через композицию const withProps = (newProps)=>Component=> (..props)=> ( <Component {...newProps} {...props}/> ) и которые через наследование const withProps = (newProps) => Component => class extends Component { static defaultProps = { ...Component.defaultProps, ...newProps } } первый подход приводит к огромной матрешке врапперов а второй подход нет и как раз фактически является вот тем что ты написал - class extends class extends class ...

за второй подход надо в гроб укладывать

есть два вида хокков - которые через композицию const withProps = (newProps)=>Component=> (..props)=> ( <Component {...newProps} {...props}/> ) и которые через наследование const withProps = (newProps) => Component => class extends Component { static defaultProps = { ...Component.defaultProps, ...newProps } } первый подход приводит к огромной матрешке врапперов а второй подход нет и как раз фактически является вот тем что ты написал - class extends class extends class ...

Это наследование и композиция, ортогональные подходы