Адекватно саги использовать?

ещё хуже

ещё хуже

+

а что же адекватно?

а что же адекватно?

rxjs

ахах

а что же адекватно?

effector

или что-то, что имеет разделение на обновление стора и эффекты

effector

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

а что же адекватно?

props & setState

props & setState

вот да

? троллируете тут меня

а что же адекватно?

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

? троллируете тут меня

не, поупарываться по эффектору тоже норм путь))

узнал для себя новое, всем благодарен ?

@itsjohncena @sergeysova

Всем привет. Коллеги, кто использует flow и библиотеку formik? Интересует, как правильно описывать типы в обернутом компоненте формы с помощью хока withFormik? Сейчас у меня что-то типа того: type TProps = { values: { msisdn: string, amount: number, ... }, onSubmit: (payment: TPayment) => void, onCardBound: (isCardBound: boolean) => void, }; type TValues = $PropertyType<TProps, 'values'>; class Form extends React.Component<FormikProps<TValues> & TProps, *> { ... } ... export default withFormik({ ... })(Form); Но при таком подходе, если я использую его в других компонентах, flow показывает, что этот компонент не требует никаких props на вход, хотя у меня по описанию - требует. Подсказка flow, если навести на компонент Form [Flow] Form: ComponentType < {} > Чую, что тут либо проблема в дефенишенах самого formik, либо я чего-то не так делаю )

Как сделать так, чтобы flow требовал на вход как минимум мои values и колбэки onSubmit и onCardBound, которые я требую от компонента выше?

Как сделать так, чтобы flow требовал на вход как минимум мои values и колбэки onSubmit и onCardBound, которые я требую от компонента выше?

Опиши интерфейс пропов

И скорми их как дженерик или как параметр, зависит от того, как объявляешь компонент

И скорми их как дженерик или как параметр, зависит от того, как объявляешь компонент

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

Всем привет! Чем #import отличается от import?

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

Скорее при экспорте

Всем привет! Чем #import отличается от import?

первый - это хештег, а второй - это импорт))

#мудрыесоветы

Всем привет! Чем #import отличается от import?

первый это в c++ а второй это в js

первый это в c++ а второй это в js

Да, этот импорт в документе c++

Да, этот импорт в документе c++

так в чем вопрос?

так в чем вопрос?

Вопрос уже решился, спасибо, не заметил что это файл c++

Вопрос уже решился, спасибо, не заметил что это файл c++

омагад

Скорее при экспорте

Видимо тогда я не понимаю о чем речь ( Я привел пример выше, в каком именно месте необходимо передавать интерфейсов пропсов? Просто в моем мире понимания типов, ХОК должен принимать пропы, добавлять свои и прокидывать их в оборачиваемый компонент, а наверх отдавать дифф между принятыми пропами и теми, что он добавил.

Слушайте, а вот если приложение маунтится в динамически определяемую дом-ноду Казалось бы проблем нет, ReactDOM.render(<App />, document.querySelector(elFromConfiguration)) Но приложение рендерит модалочки/тулптипчики и прочее, что обычно рендерится в document.body, по-хорошему-то в body лезть не надо. Для приложения самый верхний корень, о котором оно должно знать, это вот эта самая дом-нода из конфигурации Вопрос... как правильно мне моим тултипчикам и т.п. прокинуть эту самую дом ноду? Хранить в стейте что ли дом-элемент? Как будто не очень идея Хранить селектор? А потом его query-ить каждый раз? Да и даже если селектор хранить, то прокидывать его очень далеко возможно придётся. Тут контекст подойдёт?

модалочки тултипчики можно вынести в портал, разве нет?

Слушайте, а вот если приложение маунтится в динамически определяемую дом-ноду Казалось бы проблем нет, ReactDOM.render(<App />, document.querySelector(elFromConfiguration)) Но приложение рендерит модалочки/тулптипчики и прочее, что обычно рендерится в document.body, по-хорошему-то в body лезть не надо. Для приложения самый верхний корень, о котором оно должно знать, это вот эта самая дом-нода из конфигурации Вопрос... как правильно мне моим тултипчикам и т.п. прокинуть эту самую дом ноду? Хранить в стейте что ли дом-элемент? Как будто не очень идея Хранить селектор? А потом его query-ить каждый раз? Да и даже если селектор хранить, то прокидывать его очень далеко возможно придётся. Тут контекст подойдёт?

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

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

и какое отношение это к моему вопросу вообще имеет

модалочки тултипчики можно вынести в портал, разве нет?

естессн

и какое отношение это к моему вопросу вообще имеет

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

чтобы их отрендерить в ней?

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

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

Почему нельзя сделать функцию в utils, которая будет определять ноду, в которую нужно все рендерить и просто импортировать оттуда полученную ноду во все нужные места

Почему нельзя сделать функцию в utils, которая будет определять ноду, в которую нужно все рендерить и просто импортировать оттуда полученную ноду во все нужные места

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

Чем тебе не нравится такая формулировка?)

Слушайте, а вот если приложение маунтится в динамически определяемую дом-ноду Казалось бы проблем нет, ReactDOM.render(<App />, document.querySelector(elFromConfiguration)) Но приложение рендерит модалочки/тулптипчики и прочее, что обычно рендерится в document.body, по-хорошему-то в body лезть не надо. Для приложения самый верхний корень, о котором оно должно знать, это вот эта самая дом-нода из конфигурации Вопрос... как правильно мне моим тултипчикам и т.п. прокинуть эту самую дом ноду? Хранить в стейте что ли дом-элемент? Как будто не очень идея Хранить селектор? А потом его query-ить каждый раз? Да и даже если селектор хранить, то прокидывать его очень далеко возможно придётся. Тут контекст подойдёт?

Все да

Чем тебе не нравится такая формулировка?)

Они намекают автору, что он тупой, а ты нет. Пассивная агрессия такая получается.

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

Чем тебе не нравится такая формулировка?)

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

Слушайте, а вот если приложение маунтится в динамически определяемую дом-ноду Казалось бы проблем нет, ReactDOM.render(<App />, document.querySelector(elFromConfiguration)) Но приложение рендерит модалочки/тулптипчики и прочее, что обычно рендерится в document.body, по-хорошему-то в body лезть не надо. Для приложения самый верхний корень, о котором оно должно знать, это вот эта самая дом-нода из конфигурации Вопрос... как правильно мне моим тултипчикам и т.п. прокинуть эту самую дом ноду? Хранить в стейте что ли дом-элемент? Как будто не очень идея Хранить селектор? А потом его query-ить каждый раз? Да и даже если селектор хранить, то прокидывать его очень далеко возможно придётся. Тут контекст подойдёт?

А нода меняется после инициализации когда-нибудь? Если нет, то можно ссылку сохранить в замыкании, и импортировать модуль с функцией, которая ссылку из замыкания возвращает

Почему нельзя сделать функцию в utils, которая будет определять ноду, в которую нужно все рендерить и просто импортировать оттуда полученную ноду во все нужные места

всё где есть utils, helpers, … должно быть мгновенно удалено или переписано

А нода меняется после инициализации когда-нибудь? Если нет, то можно ссылку сохранить в замыкании, и импортировать модуль с функцией, которая ссылку из замыкания возвращает

вот я тоже про что-то такое подумал

всё где есть utils, helpers, … должно быть мгновенно удалено или переписано

почему?

всё где есть utils, helpers, … должно быть мгновенно удалено или переписано

Почему?

Почему?

потому что это пиздец

всё где есть utils, helpers, … должно быть мгновенно удалено или переписано

ramda

это вспомогательные функции типа moment, lodash

ramda

это библиотека

это библиотека

Такая же фигня.

потому что это пиздец

А = Аргументация

utils/helper всегда превращается в помойку из функций

ВСЕГДА

и там чаще всего можно найти дублирование функций

utils/helper всегда превращается в помойку из функций

предлагай альтернативу :0

неоттестированный код

и т.д.

неоттестированный код

ну это зависит от лида

и там чаще всего можно найти дублирование функций

всё так и есть :))

ERROR: S client not available

если он говорит на утилы тесты, то будет оттестированный

предлагай альтернативу :0

1. создавать директорию lib и к каждому файлу/директории внутри относиться как к библиотеке чтобы можно было спокойно выпилить файл в package и всё работало соблюдать именование и прочее 2. ебашить библиотеку функций с тестами и нормальной документацией

Дублирование функции проблема не папки utils, а команды

всё где есть utils, helpers, … должно быть мгновенно удалено или переписано

Ты свои lib оформляешь как отдельные пакеты?

utils/helper всегда превращается в помойку из функций

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

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

да

ок

Ты свои lib оформляешь как отдельные пакеты?

когда в lib появляются несколько файлов общей тематики но с разным набором функционала, то я ебашу библиотеку функций

Переименовываем папку utils в lib и проблема решена?) Потому что остальное возможно и по отношению к папке utils

Дублирование функции проблема не папки utils, а команды

utils/helpers это идеология

когда в lib появляются несколько файлов общей тематики но с разным набором функционала, то я ебашу библиотеку функций

Локальную?

utils/helpers это идеология

const deepClone = (obj) => JSON.parse(JSON.stringify(obj))

уоу

Локальную?

когда как сначала локальную dependencies: { ‘my-lib’: ‘./my-lib’ } потом дописываю тесты и выношу во внутренний npm

когда как сначала локальную dependencies: { ‘my-lib’: ‘./my-lib’ } потом дописываю тесты и выношу во внутренний npm

Гуд

const deepClone = (obj) => JSON.parse(JSON.stringify(obj))

Чёт как-то костыльно ?

Чёт как-то костыльно ?

Это типа иронично рядом с utils сечешь

лол, раздвоение личности

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

такой код не отрабатывает, выдает ошибку typeError

где ты там destination выдрал?

а бля

пиздец

АААААААААААААААААААААААААА

где ты там destination выдрал?

тег IMG с айдишником

тег IMG с айдишником

так блядь не делают

тег IMG с айдишником

ты чьто байльной а?

так блядь не делают

Как делают?

$("#image") так

ну например фетчить картинки не надо так